Redirection
- SPF192.0.2.80 n'est pas dans le SPF d'example.com
- DKIMsignature intacte
Le rapport montrespf=fail dkim=pass → pass
Signez tout en DKIM ; DKIM survit à la redirection. ARC (RFC 8617) aide les redirecteurs à se porter garants.
Vérification DMARC
Cette vérification DMARC lit l'enregistrement DMARC de n'importe quel domaine comme le lit un serveur de messagerie destinataire : où se trouve la politique, ce qui arrive aux e-mails qui échouent, si les rapports parviennent à quelqu'un et ce que SPF et DKIM doivent avoir avant d'appliquer la politique.
Sources : les enregistrements TXT _dmarc du domaine et de ses parents, via Google Public DNS (Cloudflare 1.1.1.1 derrière) · parcours de l'arbre de la RFC 9989 · autorisation des rapports selon la RFC 9990 · SPF et DKIM issus de nos propres vérificateurs · rien sur vous n'est enregistré
Comment vérifier un enregistrement DMARC ?
Saisissez un domaine ci-dessus : le vérificateur demande au DNS l'enregistrement TXT à _dmarc. plus le domaine, remonte au domaine organisationnel s'il n'y en a pas (RFC 9989 §4.10) et montre ce que fait un serveur destinataire des e-mails qui échouent.
À la main, interrogez le même nom : dig +short TXT _dmarc.paypal.com, ou nslookup -type=TXT _dmarc.paypal.com sous Windows. Une réponse qui commence par v=DMARC1 est l'enregistrement ; avec deux réponses, les destinataires n'en utilisent aucune (RFC 9989 §4.10).
dig s'arrête là. Il ne remonte pas depuis un sous-domaine, ne vérifie pas si les adresses de rapport acceptent les rapports et ne dit pas quelle RFC suit un destinataire. C'est ce qu'ajoute le vérificateur.
dig +short TXT _dmarc.example.comToutes les réponses à ce nom. Celle qui commence par v=DMARC1 est l'enregistrement.
Ce que dig montre, et ce qu'il ne montre pas
$ dig +short TXT _dmarc.paypal.com 1
"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"
$ dig TXT _dmarc.mail.google.com | grep status 4
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
- 1Le nom est _dmarc. plus le domainePas le domaine lui-même : un TXT à paypal.com est la place de SPF.
- 2Un seul enregistrement, v=DMARC1 d'abordDeux enregistrements sous un même nom : les destinataires écartent les deux (RFC 9989 §4.10).
- 3Des tags, séparés par ;p est la politique ; rua et ruf disent où vont les rapports.
- 4Rien ici ? Remontez_dmarc.mail.google.com est NXDOMAIN : l'enregistrement de google.com s'applique.
Lire le résultat : le point de vue du destinataire
La réponse vient d'abord, sous forme de phrase. En dessous, les preuves : l'enregistrement tel que les destinataires l'analysent, chaque tag coloré sur ses caractères exacts, et sur fond marine le chemin que suit un serveur destinataire pour ce domaine, jusqu'à ce qu'il fait des e-mails qui échouent.
Pas de score : une politique à none est une phase, pas un échec, et l'échelle sous le chemin dit ce que l'étape suivante demande.
Le verdictUne phrase sur ce que font les destinataires des e-mails qui échouent, avec la politique, SPF et DKIM d'un coup d'œil.L'enregistrementChaque tag coloré sur ses caractères : survolez-en un ou touchez-le pour voir son effet. Les valeurs par défaut en dessous.Le point de vue du destinataireChaque question DNS qu'un serveur destinataire pose pour le domaine, dans l'ordre, avec sa réponse.E-mails qui échouent à DMARCCe que font les destinataires pour le domaine, ses sous-domaines existants et les noms qui n'existent pas.L'échelle d'applicationOù en est le domaine entre none et reject, et ce que demande l'étape suivante.À quoi sert DMARC ?
DMARC dit aux serveurs de messagerie destinataires quoi faire des e-mails qui utilisent votre domaine dans la ligne From: mais ne peuvent pas prouver qu'ils viennent de vous, et où envoyer les rapports à ce sujet (RFC 9989 §4.7).
La preuve, c'est SPF ou DKIM, aligné avec le domaine du From: : SPF réussit pour un domaine de retour de la même organisation, ou une signature DKIM porte d= votre domaine. Un seul succès aligné suffit (RFC 9989 §5.3.5) ; tout le reste échoue à DMARC, et la politique de l'enregistrement décide : livrer, dossier spam ou rejet.
Les rapports sont l'autre moitié. Les destinataires qui respectent rua envoient chaque jour un résumé de tous les serveurs qui ont envoyé au nom de votre domaine : c'est ainsi que vous retrouvez les expéditeurs légitimes oubliés avant d'appliquer la politique.
Deux messages, une seule ligne From:
From: billing@example.comp=reject · rua=mailto:dmarc@example.com
Votre facture, envoyée via un service d'e-mailingvia un service configuré avec un DKIM personnalisé, il signe donc avec d=example.com
- SPFpass · bounces.esp.example (non aligné)
- DKIMpass · d=example.com (aligné)
- DMARCpass : un seul résultat aligné suffit
Livré
Une fausse facture de 203.0.113.9un serveur qu'example.com n'a jamais autorisé
- SPFfail · 203.0.113.9 n'est pas listée
- DKIMnone · pas de signature
- DMARCfail → p=reject
Rejeté
550 5.7.1 Email rejected per DMARC policy for example.com
Le rapport agrégé de demain à dmarc@example.com : 1 message de 203.0.113.9, SPF fail, DKIM none, disposition reject.
Politique DMARC : p=none, quarantine ou reject
p=none demande aux destinataires de livrer comme d'habitude les e-mails qui échouent et de seulement les signaler ; quarantine leur demande de les traiter comme suspects, en général dans le dossier spam ; reject leur demande de les refuser pendant la conversation SMTP.
None est une phase, pas un échec : la RFC 9989 §7.4 suggère d'y rester au moins un mois avec les rapports en cours, et encore autant à quarantine, avant reject. Les domaines dont les utilisateurs écrivent à des listes de diffusion devraient s'arrêter à quarantine.
Les grands fournisseurs de messagerie font aussi la différence : gmail.com et outlook.com publient p=none pour le domaine lui-même et sp=quarantine pour les sous-domaines, tandis que google.com, yahoo.com et microsoft.com publient reject.
Où atterrit un faux message
Livrép=none
apache.orggmail.comsamsung.com
23 sur 192
Dossier spamp=quarantine
github.comapple.comamazon.com
30 sur 192
Rejetép=reject
google.compaypal.commicrosoft.com
139 sur 192
DMARC est-il vraiment nécessaire ?
Oui, si vous envoyez en masse vers Gmail, Yahoo ou Outlook.com : les trois exigent un enregistrement DMARC, et p=none suffit pour respecter la règle. L'application (quarantine ou reject) est ce qui empêche d'autres d'envoyer au nom de votre domaine, et les logos BIMI l'exigent.
Gmail l'exige depuis le 1 février 2024 des expéditeurs de plus de 5 000 messages par jour vers des comptes Gmail ; Yahoo depuis février 2024, sans indiquer de volume ; Outlook.com depuis le 5 mai 2025, au-delà de 5 000 par jour. Sans enregistrement, Gmail répond 4.7.31 (et 4.7.32 quand From: n'est pas aligné), et Outlook.com rejette avec 550 5.7.515.
Pour un domaine qui n'envoie rien, DMARC est la protection la moins chère qui soit : p=reject, un MX nul et v=spf1 -all, comme le publie example.com (M3AAWG).
Ce que chaque fournisseur de messagerie demande aux expéditeurs en masse
Gmail1 févr. 20245 000+ par jour vers des comptes Gmail
4.7.31 · 4.7.32Yahoofévr. 2024aucun seuil publié
DMARC doit réussirOutlook.com5 mai 20255 000+ par jour
550 5.7.515Livrép=nonerespecte la règle des trois fournisseurs
Dossier spamquarantinearrête l'essentiel de l'usurpation · logos BIMI possibles
Rejetérejectarrête l'usurpation à la porte · BIMI
✓Obligatoire : un enregistrement, p=none ou plus strictiProtection : quarantine ou reject
Corriger les échecs DMARC : redirection, listes de diffusion, domaine propre d'un prestataire
Repérez la source en échec dans vos rapports agrégés, puis corrigez-la chez l'expéditeur : faites-la signer en DKIM pour votre propre domaine, ou déplacez-la vers un domaine de retour de votre organisation. Trois causes couvrent la plupart des échecs.
La redirection conserve la signature DKIM mais casse SPF : c'est DKIM qui porte le succès. Les listes de diffusion qui modifient le message cassent les deux. Et un service d'e-mailing qui signe avec son propre domaine réussit DKIM pour lui-même, pas pour vous : activez son DKIM personnalisé (en général des CNAME comme s1._domainkey) et un Return-Path personnalisé.
Trois échecs, ce que montre le rapport, et le correctif
Liste de diffusion
- SPFc'est le serveur de la liste qui envoie
- DKIMcorps modifié : le hachage échoue
Le rapport montrespf=fail dkim=fail → fail
Les listes qui réécrivent From: règlent le problème ; les domaines dont les utilisateurs écrivent à des listes restent à quarantine (RFC 9989 §7.4).
Le domaine propre d'un prestataire
- SPFpass pour bounces.esp.example : non aligné
- DKIMpass pour esp.example : non aligné
Le rapport montredkim=pass(esp.example) → fail
Activez le DKIM personnalisé du prestataire : s1 et s2 de paypal.com sont des CNAME vers SendGrid, qui signe au nom de paypal.com.
DMARC pour les sous-domaines : sp et np
Un sous-domaine sans enregistrement propre reçoit la politique de son domaine organisationnel : sp pour les sous-domaines qui existent, np pour les noms qui n'existent pas, chacun retombant sur p (RFC 9989 §4.7).
Un sous-domaine qui publie son propre enregistrement l'utilise pour lui-même. Mais un enregistrement situé entre un nom et son domaine organisationnel n'est jamais utilisé pour ce nom : l'arbre de berkeley.edu le montre, où le sp=none d'eecs.berkeley.edu n'atteint pas www.eecs.berkeley.edu (RFC 9989 §4.10.1).
np est le gain facile : les noms qui n'existent pas n'envoient aucun vrai courrier, si bien que np=reject bloque les usurpations depuis ces noms même quand p est encore à none. Les destinataires de la RFC 7489 ne connaissent pas np et utilisent sp.
L'arbre de berkeley.edu, comme le lit un destinataire
berkeley.edup=reject; np=reject; psd=n; rua=…son propre enregistrement · psd=n : le domaine organisationnelRejeté
www.berkeley.edupas d'enregistrementexiste → sp, absent → pRejeté
eecs.berkeley.edup=reject; sp=none; rua=…son propre enregistrement → pRejeté
www.eecs.berkeley.edupas d'enregistrementparcours : l'enregistrement d'eecs.berkeley.edu est sauté (ce n'est pas le domaine organisationnel) → le p de berkeley.eduRejeté
nosuch-x7.berkeley.eduNXDOMAINn'existe pas → npRejeté
Le sp=none d'eecs.berkeley.edu n'est jamais appliqué : un enregistrement situé entre un nom et son domaine organisationnel n'est pas utilisé pour lui (RFC 9989 §4.10.1). Le vérificateur le signale comme un enregistrement inutilisé.
Lire les rapports DMARC (rua)
Un rapport agrégé est un fichier XML quotidien de chaque destinataire qui liste tous les serveurs ayant envoyé au nom de votre domaine, combien de messages, et si SPF, DKIM et DMARC ont réussi (RFC 9990).
Lisez-le par source : vos propres serveurs et services doivent montrer un succès aligné ; un service connu qui échoue a besoin de son DKIM personnalisé ; une adresse inconnue qui échoue à p=reject est une usurpation, arrêtée. Un service de rapports (dmarcian, Valimail, EasyDMARC, Postmark et d'autres) transforme des milliers de fichiers en cette liste.
Les rapports vers une adresse d'un autre domaine n'arrivent que si ce domaine est d'accord : il publie yourdomain._report._dmarc.its-host avec v=DMARC1 (RFC 9990 §4). Le vérificateur interroge pour vous, et donne l'enregistrement exact quand il manque.
Un rapport, lu ligne par ligne
<org_name>google.com</org_name>1
<date_range>23 oct., 00:00 UTC – 24 oct., 00:00 UTC</date_range>
<policy_published>example.com · p=reject</policy_published>2
<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3
<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4
- 1Qui a fait le rapportUn fichier par destinataire et par jour (RFC 9990 : au moins toutes les 24 heures).
- 2La politique trouvéeCe qu'il a lu à _dmarc.example.com.
- 3Courrier redirigé, sauvé par DKIMSPF a échoué chez le redirecteur ; la signature alignée a réussi DMARC.
- 4Usurpation, arrêtéeUn serveur inconnu, rien d'aligné, refusé.
paypal.comrua=mailto:d@rua.agari.comrua.agari.com
paypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ autorisée : les rapports arriventServices de rapports que le vérificateur reconnaîtdmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 autres
Vérification DMARC : questions fréquentes
Qu'est-ce que DMARC ?
DMARC est un enregistrement DNS qui indique aux serveurs de messagerie destinataires quoi faire des e-mails qui utilisent votre domaine dans la ligne From: mais échouent à l'alignement SPF et DKIM : les livrer, les mettre en quarantaine ou les rejeter. Il précise aussi où les destinataires envoient les rapports sur ces e-mails. Il est publié comme enregistrement TXT à _dmarc plus votre domaine et défini par la RFC 9989, qui a remplacé la RFC 7489 en mai 2026.
Que montre un vérificateur d'enregistrement DMARC ?
Il lit l'enregistrement TXT à _dmarc plus le domaine, et celui de ses parents s'il n'y en a pas, comme le fait un destinataire. Celui-ci montre l'enregistrement tag par tag avec ses valeurs par défaut, la politique du domaine, de ses sous-domaines et des noms qui n'existent pas, si les adresses de rapport acceptent les rapports, ainsi que l'enregistrement SPF et les clés DKIM du domaine, sans score.
Comment tester DMARC ?
Vérifiez le domaine ci-dessus pour connaître la politique publiée : c'est le test DMARC auquel le DNS peut répondre. Pour voir si un vrai message réussit, envoyez-en un vers une boîte que vous contrôlez et lisez son en-tête Authentication-Results, ou collez les en-têtes dans l'analyseur d'en-têtes e-mail. Un validateur de syntaxe DMARC contrôle l'écriture de l'enregistrement ; seul un message montre si SPF ou DKIM se sont alignés.
Par quelle politique DMARC commencer ?
Commencez par p=none et une adresse rua : les destinataires vous envoient des rapports quotidiens sans changer la livraison. Corrigez chaque expéditeur légitime qui échoue, en général en activant son DKIM personnalisé, puis passez à quarantine et enfin à reject. La RFC 9989 suggère au moins un mois à p=none et encore autant à quarantine. Un domaine qui n'envoie aucun e-mail peut passer directement à p=reject.
p=none protège-t-il mon domaine ?
Non. p=none demande aux destinataires de traiter comme d'habitude les e-mails qui échouent : un faux message n'est donc jugé que par leurs propres filtres antispam. En revanche, il vous donne des rapports et respecte la règle de Gmail, Yahoo et Outlook.com pour les expéditeurs en masse. Voyez-le comme une phase de surveillance : la protection commence à quarantine, et reject arrête les faux e-mails avant qu'ils n'arrivent à quiconque.
Que signifie t=y dans un enregistrement DMARC ?
t=y est le mode test de la RFC 9989 : les destinataires appliquent un cran sous la politique publiée, donc p=reject agit comme quarantine et p=quarantine comme none. Il n'a aucun effet sur p=none et ne change pas les rapports. Les destinataires encore sous la RFC 7489 ne connaissent pas ce tag et appliquent la politique telle qu'écrite. Retirez t=y quand vos rapports montrent que chaque expéditeur légitime est aligné.
Le tag pct est-il encore utilisé ?
La RFC 9989 a supprimé pct, ainsi que rf et ri, parce que les valeurs autres que 0 et 100 étaient appliquées de façon incohérente. Les destinataires actuels l'ignorent et appliquent la politique à tous les e-mails qui échouent. Ceux qui suivent encore la RFC 7489 échantillonnent : pct=25 à quarantine envoie un quart des e-mails en échec en spam et livre le reste. pct=100 est inoffensif ; pour une phase de test, utilisez t=y.
Pourquoi mon adresse rua est-elle « non autorisée » ?
Quand les rapports vont vers une boîte d'un autre domaine organisationnel, ce domaine doit donner son accord en publiant un enregistrement TXT nommé yourdomain._report._dmarc.its-host avec la valeur v=DMARC1 (RFC 9990 §4). Sans lui, les destinataires qui contrôlent ignorent l'adresse. L'enregistrement se place dans le DNS de la destination, pas dans le vôtre : les services de rapports publient un joker pour chaque client, il s'agit donc en général d'une faute de frappe ou de la boîte d'un partenaire.
Les sous-domaines ont-ils besoin de leur propre enregistrement DMARC ?
En général non. Un sous-domaine sans enregistrement reçoit la politique de son domaine organisationnel : sp pour les sous-domaines qui existent, np pour les noms qui n'existent pas, tous deux retombant sur p. Ne publiez un enregistrement sur un sous-domaine que s'il lui faut une autre politique. Un enregistrement sur un nom intermédiaire, comme team.example.com pour www.team.example.com, n'est pas utilisé pour le nom plus profond.
Que se passe-t-il si un domaine publie deux enregistrements DMARC ?
Les destinataires écartent les deux : aucune politique DMARC ne s'applique et aucun rapport n'est envoyé, même si l'un des deux dit reject (RFC 9989 §4.10). Cela arrive en général quand on ajoute un nouvel enregistrement sans supprimer l'ancien, ou quand un hébergeur DNS en ajoute un par défaut. Gardez un seul enregistrement à _dmarc et supprimez l'autre ; le vérificateur montre lequel semble voulu.
Pourquoi DMARC échoue-t-il alors que SPF réussit ?
DMARC exige un succès SPF pour un domaine qui s'aligne sur l'adresse From:. La plupart des services d'e-mailing envoient avec leur propre domaine de retour : SPF réussit pour eux, pas pour vous, et ne compte pas. Il en va de même pour DKIM signé avec le domaine du service. Configurez le DKIM personnalisé ou le Return-Path personnalisé du service pour que le domaine qui réussit soit le vôtre.
Le vérificateur ne montre aucun enregistrement, mais je viens d'en ajouter un. Pourquoi ?
Vérifiez d'abord le champ hôte : la plupart des interfaces DNS veulent seulement _dmarc, et y saisir _dmarc.example.com crée _dmarc.example.com.example.com. Attendez ensuite que l'ancienne réponse expire : si le nom a déjà été interrogé, les résolveurs gardent son NXDOMAIN pendant le TTL négatif de la zone, souvent de 5 minutes à une heure. Un SERVFAIL ou un délai dépassé s'affiche comme « non vérifiable », jamais comme aucun enregistrement.
Outils e-mail et DNS associés
Vérificateur d'Enregistrement SPF
Validez les enregistrements SPF et vérifiez le nombre de requêtes DNS selon RFC 7208
Vérifier DKIM
Vérifiez les enregistrements DKIM avec détection automatique de sélecteur
Vérificateur d'enregistrement BIMI
Enregistrements BIMI, logos SVG Tiny PS, certificats VMC et messageries qui les affichent
Générateur d'enregistrement DMARC
Créez votre enregistrement DMARC pour la RFC 9989, en partant de celui que vous publiez aujourd'hui, et voyez ce que les destinataires feront des e-mails qui échouent.
Analyseur d'En-têtes E-mail
Analysez les en-têtes bruts d'e-mail et tracez le parcours de l'e-mail
Recherche MX
Trouvez les enregistrements MX et les détails du serveur de messagerie