Passer en rejet sans bloquer ses propres emails

Tout le monde vous dit qu’il faut passer en p=reject. Personne ne vous dit comment y arriver sans casser vos propres flux, et c’est pour cette raison que tant de domaines restent bloqués en surveillance pendant des années.

Cet article traite de ce passage. Il intègre la révision du standard publiée en mai 2026, qui change une partie des conseils que vous trouverez ailleurs.

Ce que vous risquez concrètement

Commençons par le risque, parce qu’il est mal compris. Durcir trop vite ne provoque pas de panne visible. C’est bien le problème.

Vos serveurs continuent d’envoyer, vos outils ne signalent aucune erreur, votre équipe ne remarque rien. Simplement, une partie de vos messages n’arrive plus. Les factures que votre logiciel comptable expédie sont refusées à la porte. Les confirmations de commande de votre site disparaissent. Les demandes de signature électronique n’atteignent plus personne.

Le délai moyen avant que quelqu’un fasse le lien se compte en semaines. Le déclencheur est presque toujours un client qui appelle pour dire qu’il n’a jamais reçu sa facture, et l’enquête remonte rarement jusqu’au DNS du premier coup.

Voilà pourquoi la prudence n’est pas de la timidité sur ce sujet.

Les trois politiques, et ce qu’elles font réellement

Le tag p de votre enregistrement DMARC accepte trois valeurs.

p=none, la surveillance. Vous demandez aux receveurs de ne rien changer à leur traitement et de vous envoyer des rapports. Aucun effet sur vos messages. C’est le point de départ obligatoire, et son seul but est de produire de la donnée.

p=quarantine, la mise en quarantaine. Vous demandez de traiter les messages non conformes comme suspects. En pratique, la plupart des receveurs les placent en indésirables. Le message n’est pas perdu, il est déclassé. C’est une étape intermédiaire réelle, moins brutale que le rejet.

p=reject, le rejet. Vous demandez de refuser les messages non conformes pendant la transaction SMTP. L’expéditeur reçoit une erreur, le destinataire ne voit rien. C’est l’objectif, parce que c’est la seule politique qui protège réellement vos clients contre une usurpation.

Un point à connaître : les receveurs ne sont jamais obligés de vous obéir. Certains appliquent leurs propres règles, notamment sur les messages transférés. Vous verrez donc parfois, dans vos rapports, des messages non conformes qui n’ont pas été rejetés malgré votre politique.

Le tag pct a été supprimé, et c’est important

Si vous avez lu des guides sur le déploiement progressif de DMARC, vous connaissez le tag pct. Il permettait d’appliquer la politique à un pourcentage seulement des messages : pct=10 avec p=reject signifiait « rejette 10 % des messages non conformes, laisse passer le reste ». L’idée était de durcir par paliers.

Ce tag n’existe plus. La révision du standard, publiée en mai 2026 sous la forme de trois documents, les RFC 9989 pour le protocole, 9990 pour les rapports agrégés et 9991 pour les rapports d’échec, l’a placé en statut historique. Ces textes remplacent la RFC 7489 qui régissait DMARC depuis 2015.

La raison de cette suppression est simple : le mécanisme ne fonctionnait pas. Les receveurs l’appliquaient de manière incohérente, et un même pct=50 produisait des comportements différents selon les opérateurs. Le déploiement progressif qu’il promettait était une illusion de contrôle.

À la place, le standard introduit un tag t de mode test. Il est binaire : t=y demande au receveur d’abaisser l’application de votre politique d’un cran. Un p=reject accompagné de t=y sera traité comme une quarantaine, un p=quarantine comme une surveillance.

La correspondance avec l’ancien usage est directe. Un pct=0 devient t=y. Un pct=100 s’écrit en omettant simplement le tag. Et les valeurs intermédiaires, entre 1 et 99, n’ont plus d’équivalent.

Il faut le dire clairement : le nouveau standard supprime un mécanisme défaillant sans le remplacer par un mécanisme fonctionnel. Le mode test abaisse d’un cran, il n’échantillonne pas. Il n’existe plus aujourd’hui de moyen normalisé de durcir progressivement une politique DMARC. La progression se fait donc par paliers entiers, et c’est précisément ce qui rend la préparation en amont plus importante qu’avant.

Que faire si votre enregistrement contient encore un pct ? Rien d’urgent : sa présence ne provoque pas d’erreur et votre enregistrement reste valide. Mais il sera de plus en plus ignoré à mesure que les receveurs appliquent le nouveau texte. Cessez donc de compter dessus, et retirez-le à votre prochaine modification.

Deux autres nouveautés utiles

Le standard ajoute au passage un tag np, qui définit la politique applicable aux sous-domaines inexistants. C’est une protection réelle : les fraudeurs utilisent volontiers des sous-domaines qui n’ont jamais existé, comme facturation.votreentreprise.fr, parce qu’ils échappaient aux politiques mal configurées. Un np=reject ferme cette porte, et il est sans risque puisque, par définition, aucun flux légitime ne part d’un sous-domaine qui n’existe pas.

Le calcul du domaine organisationnel change également de méthode, ce qui affecte l’alignement de vos sous-domaines. Le sujet est traité dans notre article sur l’alignement.

Les quatre conditions à réunir avant de bouger

Ne durcissez pas tant que ces quatre conditions ne sont pas réunies simultanément.

Un historique suffisant. Deux semaines de données au minimum, quatre à huit de préférence. La durée compte moins que la couverture : il faut avoir vu passer vos expéditeurs occasionnels.

Un taux de conformité élevé et stable. Au-dessus de 95 % pour passer en quarantaine, au-dessus de 99 % pour passer en rejet. Le mot important est stable : un taux qui oscille signale un expéditeur intermittent que vous n’avez pas encore identifié.

Aucun expéditeur non reconnu au-dessus du bruit de fond. Tant qu’une source de volume significatif reste sans nom, vous ne pouvez pas savoir si la bloquer est souhaitable ou catastrophique.

Tous vos expéditeurs approuvés sont alignés. Pas seulement authentifiés : alignés. C’est la distinction qui fait toute la différence, et elle se lit dans le bon champ de vos rapports.

Les cas qui cassent en pratique

Six situations reviennent systématiquement. Vérifiez-les nommément avant de bouger.

Les factures et documents automatiques. Votre logiciel comptable envoie souvent depuis son propre serveur avec votre adresse. C’est le flux qui casse le plus souvent, et le plus coûteux.

Les formulaires du site web. Beaucoup de sites envoient les confirmations depuis le serveur d’hébergement, avec une adresse en votre domaine et aucune authentification.

Les transferts automatiques. Un salarié qui fait suivre sa messagerie vers une adresse personnelle casse SPF à tous les coups. Seul DKIM survit.

Les listes de diffusion. Elles modifient souvent le message, ce qui invalide la signature DKIM. Les listes bien tenues réécrivent l’expéditeur, les autres non.

Les prestataires invisibles. Signature électronique, prise de rendez-vous, recrutement, enquêtes de satisfaction. Ils écrivent en votre nom et n’apparaissent dans aucun inventaire.

Le matériel. Copieurs qui envoient des documents numérisés, systèmes d’alarme, supervision. Ils utilisent une adresse de votre domaine et n’ont aucune authentification.

Un plan de bascule sur quatre-vingt-dix jours

Jours 1 à 14, observer. Publiez p=none avec une adresse de rapport. Ne touchez à rien d’autre. Collectez.

Jours 15 à 30, nommer. Traduisez chaque source en nom de prestataire. Classez en légitime approuvé, légitime à corriger, ou à éliminer. C’est l’étape la plus longue, et celle qui détermine tout le reste.

Jours 31 à 60, corriger. Faites signer chaque expéditeur légitime en DKIM avec votre domaine. Comptez une à trois semaines par prestataire, le délai venant de leur support, pas de la technique. Coupez les outils abandonnés.

Jours 61 à 75, la quarantaine. Quand le taux dépasse 95 % de façon stable, passez en p=quarantine. Surveillez le volume quotidien : une baisse marquée signale un flux cassé. Restez deux semaines.

Jours 76 à 90, le rejet. Au-dessus de 99 % et sans expéditeur inconnu, passez en p=reject. Ajoutez np=reject dans la foulée. Continuez à lire vos rapports : un nouvel outil branché par un service dans six mois repartira non aligné.

Ce calendrier suppose que vous avancez régulièrement. Dans la vraie vie, l’étape des jours 31 à 60 déborde presque toujours, à cause du support d’un prestataire qui met trois semaines à répondre. Ce n’est pas grave. Ce qui compte est de ne pas durcir tant que les quatre conditions ne sont pas remplies.

Les signaux qui doivent vous faire reculer

Trois signaux imposent le retour à l’étape précédente, sans hésiter.

Une baisse du volume total rapportée d’un jour sur l’autre. Ce ne sont pas vos envois qui diminuent, c’est un flux qui a cessé d’arriver.

L'apparition d’un expéditeur non reconnu avec du volume, juste après un durcissement. Vous venez probablement de bloquer un outil légitime.

Un appel client signalant un message jamais reçu. Revenez en surveillance le temps de comprendre. Un enregistrement DNS se modifie en cinq minutes.

Reculer n’est pas un échec. Durcir puis revenir est infiniment moins coûteux que rester trois semaines à bloquer ses propres factures.

Questions fréquentes

Le tag pct existe-t-il encore en DMARC ? Non. La révision publiée en mai 2026 sous les RFC 9989, 9990 et 9991 lui a donné un statut historique. Il est remplacé par un tag t de mode test, qui abaisse la politique d’un cran au lieu d’échantillonner.

Combien de temps faut-il rester en surveillance avant de durcir ? Deux semaines de données exploitables au minimum, quatre à huit le plus souvent. La stabilité compte davantage que la durée.

Que se passe-t-il si je passe en rejet trop tôt ? Vos messages non alignés sont refusés. Vos factures et confirmations cessent d’arriver, généralement sans que personne fasse le lien pendant plusieurs semaines.

Faut-il passer par la quarantaine ou aller directement au rejet ? Passez par la quarantaine. C’est la seule étape intermédiaire qui reste depuis la suppression de pct, et elle vous laisse voir les effets d’un durcissement sans perdre définitivement les messages.

Mon enregistrement contient encore pct, dois-je le retirer d’urgence ? Non. Il ne provoque pas d’erreur, mais il sera de plus en plus ignoré. Retirez-le à votre prochaine modification et cessez de compter dessus.

---

Alignmarc calcule les quatre conditions en continu et vous dit ce qui vous empêche encore de durcir, en nommant chaque bloquant. Le premier domaine est gratuit.