DMARC quarantine et reject : passer de p=none sans perdre d’e-mails légitimes

1. Ce que p=none, quarantine et reject demandent aux destinataires

La balise p de l’enregistrement DMARC publié sur _dmarc.example.com indique ce que vous souhaitez que les destinataires fassent du courrier dont le domaine From échoue à DMARC, c’est-à-dire quand ni SPF ni DKIM n’ont réussi pour un domaine aligné sur lui. C’est une demande, pas un ordre. La RFC 9989, norme DMARC publiée en mai 2026 qui remplace la RFC 7489, laisse la décision finale à la politique locale de chaque destinataire.

Deux points guident le déploiement. D’abord, p=none ne protège rien à lui seul : il produit des rapports, et seulement si l’enregistrement contient une adresse rua. Ensuite, les destinataires n’appliquent pas tous la politique de la même manière. La RFC 9989 leur demande de ne pas rejeter un message au seul motif que la politique dit reject, et certains le placent alors en quarantaine ; un même changement peut donc produire des effets différents selon le fournisseur de messagerie. Prévoyez le passage comme une suite de petites étapes réversibles plutôt que comme un interrupteur.

Les grands fournisseurs de messagerie exigent déjà un enregistrement DMARC des expéditeurs en masse, mais acceptent p=none. Le guide pour vérifier SPF et DMARC récapitule leurs exigences et explique chaque balise de l’enregistrement.

2. Lire les rapports agrégés DMARC (rua)

Ce sont les rapports agrégés qui rendent le passage sûr. Ajoutez une adresse de rapport à l’enregistrement, par exemple rua=mailto:dmarc-reports@example.com : les destinataires qui envoient des rapports vous adresseront un fichier XML compressé, couvrant le plus souvent une journée UTC, qui liste chaque adresse IP ayant envoyé du courrier avec votre domaine dans le From et le sort de ces messages. Le format est défini par la RFC 9990. Un nom de fichier comme receiver.example!example.com!1791590400!1791676800.xml.gz indique le destinataire qui rend compte, votre domaine, puis le début et la fin de la période en horodatages Unix.

Chaque <record> du fichier regroupe les messages par source et par résultat. Voici les champs qui comptent le plus :

La différence entre la dernière ligne et policy_evaluated est la leçon la plus utile. Une plateforme de newsletters peut afficher un DKIM pass dans auth_results pour mailer.example.net et échouer quand même à DMARC, parce que ce domaine n’est pas aligné sur example.com. Seul policy_evaluated reflète la conclusion de DMARC.

Lisez les rapports sur plusieurs semaines, pas sur une journée : factures mensuelles, newsletters trimestrielles et avis de renouvellement annuels arrivent à leur propre rythme. Dès que le volume augmente, le XML brut devient fastidieux ; un analyseur ou un outil de rapports qui regroupe les lignes par source, alignement et disposition chaque jour rend l’examen praticable. Tous les destinataires n’envoient pas de rapports agrégés : une semaine calme ne signifie pas un domaine calme. Si l’adresse rua se trouve dans un autre domaine organisationnel, celui-ci doit publier un enregistrement d’autorisation comme example.com._report._dmarc.reports.example.net commençant par v=DMARC1, faute de quoi les destinataires ignorent l’adresse (RFC 9990, section 4).

3. Recenser tous les expéditeurs légitimes avant d’appliquer la politique

Appliquer la politique n’est sûr que si vous connaissez chaque système qui place votre domaine dans le From. Construisez la liste par les deux bouts : ce qu’utilise l’organisation, et ce que montrent les rapports. Sources habituelles :

• La messagerie utilisée chaque jour par les équipes.
• Marketing et newsletters, y compris ce vieil outil de campagnes sur lequel quelqu’un se connecte encore.
• Courriels transactionnels de votre application : confirmations d’inscription, réinitialisations de mot de passe, reçus.
• Outils métier : CRM, facturation et paiements, support, RH et recrutement, agenda et signature électronique.
• Formulaires et extensions du site qui envoient en tant que noreply@example.com.
• Appareils et scripts : scanners, alertes de supervision, tâches planifiées et relais internes.

Associez ensuite chaque source des rapports à une ligne de la liste. Une résolution inverse de l’adresse IP (dig +short -x 192.0.2.10) révèle souvent le prestataire, dont la documentation précise l’include SPF et la configuration DKIM à utiliser. Consignez le résultat dans un tableau comme celui-ci :

La dernière ligne est tout l’enjeu de l’exercice. Une fois toutes les sources connues en réussite, ce qui échoue encore est surtout du courrier usurpé ou mal configuré, et c’est précisément ce que la politique doit arrêter. Les sources qui envoient rarement sont les plus souvent oubliées : demandez à la comptabilité, aux RH et au support quels outils ils utilisent avant de vous fier à un mois calme.

4. Alignement SPF et DKIM : relâché ou strict

DMARC réussit quand SPF ou DKIM réussit et que le domaine concerné est aligné sur le domaine From. Un seul résultat aligné suffit. Pour SPF, le domaine vérifié est celui de l’expéditeur d’enveloppe (RFC 7208) ; pour DKIM, c’est la valeur d= d’une signature valide (RFC 6376). Les balises aspf et adkim fixent le degré de correspondance exigé :

• Relâché (r, valeur par défaut) : les deux domaines partagent le même domaine organisationnel, donc bounce.example.com et news.example.com sont alignés sur example.com.
• Strict (s) : les domaines doivent être identiques.

La RFC 9989 détermine le domaine organisationnel par un parcours de l’arborescence DNS (DNS Tree Walk), en interrogeant les enregistrements _dmarc du nom complet vers le haut, au lieu de la liste des suffixes publics sur laquelle s’appuyait la RFC 7489.

La RFC 9989 constate que presque tous les titulaires de domaine trouvent l’alignement relâché suffisant. Le mode strict casse le schéma courant d’un sous-domaine de rebond par prestataire ; gardez donc la valeur par défaut, sauf raison précise, par exemple des sous-domaines délégués à des prestataires, où l’alignement relâché laisserait du courrier authentifié pour vendor.example.com passer pour example.com. Quel que soit votre choix, faites de DKIM la méthode alignée de chaque source. SPF casse lors d’un transfert, car le serveur qui transfère ne figure pas dans votre enregistrement ; une signature DKIM survit en général au transfert tant que le message n’est pas modifié.

5. Déploiement progressif : pct a disparu, utilisez t=y

Les anciens guides procèdent par paliers avec pct : p=quarantine; pct=10, puis 25, 50 et 100, pour que la politique couvre une part croissante du courrier en échec. Selon la RFC 7489, le courrier hors de l’échantillon recevait la politique immédiatement inférieure. La RFC 9989 a supprimé la balise ; son annexe A.6 explique que les valeurs autres que 0 et 100 étaient rarement appliquées avec précision et que l’écart variait fortement d’une implémentation à l’autre.

Cette suppression cache un piège. La RFC 9989 demande aux destinataires d’ignorer les balises qu’ils ne connaissent pas : un destinataire qui suit la nouvelle norme lit p=quarantine; pct=25 comme un simple p=quarantine et l’applique à tout le courrier en échec. Un pct partiel ne permet plus de limiter l’impact de façon fiable.

Le remplaçant est l’indicateur de test t. Avec t=y, on demande aux destinataires d’appliquer le niveau situé juste sous la politique publiée : p=quarantine; t=y est traité comme none, et p=reject; t=y comme quarantine. Les rapports continuent normalement, et un destinataire peut noter l’écart avec le motif policy_test_mode. La RFC 9989 présente t=y et t=n comme les équivalents de pct=0 et pct=100.

Pendant la transition, certains destinataires n’implémentent que la RFC 7489 et ignorent t, tandis que les plus récents ignorent pct. Comme pct=0 selon les anciennes règles et t=y selon les nouvelles demandent le même traitement, vous pouvez publier les deux pendant la phase de test :

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

Surveillez les rapports pendant quelques semaines, puis retirez les deux balises pour que p=quarantine s’applique pleinement. Répétez le même schéma avant reject : p=reject; t=y; pct=0 demande une mise en quarantaine, et le retrait des deux balises active le rejet.

Vous pouvez aussi avancer par flux de courrier plutôt que par pourcentage. Un sous-domaine comme news.example.com peut porter son propre enregistrement DMARC et passer à l’application avant ou après le domaine principal ; l’exemple de déploiement de la RFC 9989 elle-même teste p=quarantine avec t=y sur un sous-domaine avant de durcir la politique.

6. Politique des sous-domaines : sp et np

Un enregistrement DMARC sur example.com couvre aussi les sous-domaines qui n’ont pas leur propre enregistrement _dmarc. Deux balises permettent une politique de sous-domaine différente de p :

Quelques règles rendent le comportement prévisible. sp n’a d’effet que dans l’enregistrement du domaine organisationnel ; un sous-domaine qui publie son propre enregistrement suit la p de cet enregistrement. Fixer np=reject alors que p est encore à none est une première étape peu risquée : le courrier usurpé depuis des noms inventés comme billing-support.example.com est refusé, et les destinataires qui ne gèrent pas np se replient simplement sur sp ou p. Avant de vous y fier, vérifiez que chaque sous-domaine depuis lequel vous envoyez réellement possède au moins un enregistrement DNS, afin qu’il compte comme existant. Et n’oubliez pas que SPF ne s’hérite pas : chaque nom utilisé comme expéditeur d’enveloppe a besoin de son propre enregistrement SPF, quelle que soit la politique DMARC.

7. Un calendrier réaliste de p=none à p=reject

Aucun calendrier ne convient à tous les domaines, et la RFC 9989 prévient qu’il peut falloir de nombreux mois de rapports avant d’être prêt à appliquer la politique. Pour les domaines dont les utilisateurs écrivent sur des listes de diffusion, elle suggère au moins un mois en p=none puis autant en p=quarantine, en comparant les résultats, et recommande malgré tout à ces domaines de ne pas publier reject. Une organisation qui compte une poignée de services d’envoi pourrait planifier ainsi :

Avant chaque changement, abaissez le TTL de l’enregistrement TXT _dmarc, par exemple à 300 secondes, au moins une période de l’ancien TTL à l’avance, pour qu’un retour en arrière atteigne vite les résolveurs. Modifiez l’enregistrement en début de semaine, dites au support ce qu’il doit surveiller et tenez un journal daté de chaque valeur publiée. La RFC 9989 impose à tout domaine qui publie p=reject de signer son courrier avec des signatures DKIM valides au lieu de compter sur SPF seul. Reject n’est pas la seule bonne destination : pour un domaine que vos équipes utilisent sur des listes de diffusion, une quarantaine bien surveillée peut être le meilleur choix, alors qu’un domaine réservé aux factures et aux notifications est un candidat évident pour reject.

8. Quand du courrier légitime échoue : diagnostiquer, corriger, revenir en arrière

Tôt ou tard, un rapport ou un collègue vous montrera du courrier légitime en échec. Retrouvez les lignes correspondantes dans les rapports agrégés, ou demandez les en-têtes complets d’un message concerné et lisez son en-tête Authentication-Results, puis comparez avec ces cas :

Si l’échec est massif, ou s’il touche du courrier lié au chiffre d’affaires comme les reçus et les réinitialisations de mot de passe, revenez d’abord en arrière et enquêtez ensuite : ajoutez t=y et pct=0, ou revenez à la politique précédente. Avec un TTL court, le changement atteint la plupart des résolveurs en quelques minutes. Un rejet 5xx est définitif : le courrier déjà rejeté ne sera pas distribué plus tard, alors indiquez à l’équipe concernée quels messages renvoyer. Corrigez ensuite la source, vérifiez sur quelques jours de rapports qu’elle réussit, puis avancez de nouveau. Les services de transfert et les listes qui conservent les résultats d’authentification avec ARC (RFC 8617) aident, mais la RFC 9989 note qu’aucun mécanisme de ce type n’est encore largement utilisé ; DKIM sur chaque source reste donc la solution fiable.

9. Vérifier l’enregistrement DMARC publié

Vérifiez ce qui est réellement publié, et non ce qu’affiche l’interface de votre DNS :

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

Les deux premières lignes montrent ce que renvoient les résolveurs ; la dernière interroge directement un serveur faisant autorité et montre un changement avant l’expiration des réponses en cache. Vérifiez que :

• un seul enregistrement TXT sur _dmarc commence par v=DMARC1 ; s’il y en a deux, les destinataires les écartent tous les deux et le domaine se comporte comme s’il n’avait pas de DMARC ;
• v=DMARC1 est la première balise et p vaut none, quarantine ou reject ;
• la boîte rua existe et, si elle se trouve dans un autre domaine, est autorisée par un enregistrement _report._dmarc ;
• les balises sont séparées par des points-virgules, sans guillemets typographiques ni caractères parasites copiés depuis un document.

Envoyez ensuite un message depuis chaque service vers une boîte que vous contrôlez et lisez l’en-tête Authentication-Results : dmarc=pass accompagné de votre domaine From est le verdict du destinataire, et c’est lui qui compte.

Pour un coup d’œil rapide depuis l’extérieur, le vérificateur gratuit d’enregistrements SPF et DMARC lit l’enregistrement _dmarc du nom d’hôte exact saisi, sans repli sur le domaine parent. Il signale un enregistrement absent (moyen, si l’hôte a des enregistrements MX) et p=none (faible, comme mode d’observation) ; quarantine et reject ne déclenchent aucun signal. Il ne lit pas vos rapports et n’évalue ni sp, ni np, ni t, ni pct, ni rua, ni l’alignement. Le même contrôle du DNS de messagerie lit aussi SPF, MTA-STS et CAA, et c’est l’un des huit contrôles passifs du snapshot gratuit de préparation au lancement, qui ne demande aucune inscription et renvoie un score avec un résultat pour chaque contrôle. Pour un suivi régulier, consultez le guide sur la sécurité des e-mails et du DNS.