Vérifiez un enregistrement DMARC et lisez sa politique, son alignement et ses adresses de rapport en clair
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.Un vérificateur DMARC lit l'enregistrement TXT situé à _dmarc suivi d'un domaine et indique ce que les destinataires font du courrier qui échoue à SPF et DKIM. Les 3 politiques sont none, quarantine et reject ; seules les 2 dernières arrêtent le courrier falsifié. Les adresses de rapport sur un autre domaine y exigent un enregistrement d'autorisation.
Cette page a été traduite automatiquement à partir de l'original anglais. Aucune personne n’a encore relu la traduction : c’est la version anglaise qui fait foi. Lire l'original en anglais
Saisissez le domaine dans le champ Domaine et appuyez sur Vérifier DMARC.
Lisez le titre : il indique la politique qui s'applique au courrier en échec pour ce domaine.
Lisez Ce que dit cet enregistrement pour voir la politique, l'alignement et les adresses de rapport en clair.
Vérifiez dans les constats les adresses de rapport d'un autre domaine qui n'ont pas accepté de recevoir des rapports.
Appuyez sur Copier à côté de l'enregistrement pour le copier.
Saisissez un domaine et la page demande à un résolveur public DNS-over-HTTPS l'enregistrement TXT situé à _dmarc. suivi de ce nom. L'enregistrement est lu balise par balise puis expliqué en phrases : ce qui arrive au courrier en échec, ce qui s'applique aux sous-domaines, avec quelle rigueur SPF et DKIM doivent correspondre à l'adresse From, et où partent les rapports.
Les règles viennent de la RFC 9989, publiée en mai 2026, qui a remplacé la RFC 7489 comme norme DMARC. Deux changements comptent pour lire des enregistrements anciens. La balise pct a été supprimée : les anciens destinataires l'utilisent encore pour n'agir que sur une partie du courrier en échec, les nouveaux l'ignorent. Une balise t=y signifie désormais le mode test, où les destinataires appliquent un cran de moins que la politique. Les deux sont signalées en clair.
Quand un sous-domaine n'a pas d'enregistrement propre, les destinataires cherchent à la place celui du domaine organisationnel. Cette page le fait avec le parcours de l'arbre DNS défini par la section 4.10 de la RFC 9989, en interrogeant _dmarc à chaque nom plus court, 8 au plus, et affiche chaque nom interrogé. Aucune liste de suffixes publics n'est utilisée, donc rien ne dépend de la fraîcheur d'une copie de cette liste.
Les adresses de rapport sur un autre domaine sont vérifiées quant à leur autorisation. La section 4 de la RFC 9990 demande aux destinataires de n'envoyer des rapports à un autre domaine que si ce domaine publie un enregistrement TXT au domaine de la politique suivi de ._report._dmarc. et de l'hôte qui reçoit les rapports. Son absence est la raison habituelle pour laquelle un service DMARC ne reçoit rien.
L'onglet générateur écrit un enregistrement à partir de vos choix et nomme l'hôte sous lequel le publier. Il omet les balises égales à leurs valeurs par défaut et n'écrit pas pct.
Ce qu'il ne fait pas : il lit l'enregistrement, pas votre courrier, il ne peut donc pas dire si vos messages passent. Les rapports quotidiens vous le diront.
Le domaine que vous saisissez est envoyé au résolveur que vous choisissez, car une requête en a besoin. Rien d'autre ne quitte votre appareil.
Une politique p=none demande aux destinataires de livrer normalement le courrier qui échoue à DMARC et de seulement envoyer des rapports. Le courrier falsifié utilisant le domaine arrive toujours en boîte de réception. Les propriétaires l'utilisent quelques semaines pour repérer dans les rapports chaque expéditeur légitime, puis passent à quarantine et enfin à reject.
Pas forcément. Quand un sous-domaine comme mail.example.com n'a pas d'enregistrement, les destinataires utilisent celui du domaine organisationnel, example.com, en appliquant sa politique sp= s'il en a une et p= sinon. Un sous-domaine peut publier son propre enregistrement pour passer outre.
Trois causes habituelles : l'enregistrement n'a pas d'adresse rua= ; l'adresse est sur un autre domaine qui n'a pas publié l'enregistrement d'autorisation à votredomaine._report._dmarc.leurdomaine ; ou l'enregistrement lui-même est invalide, par exemple deux enregistrements DMARC sous un même nom, que les destinataires ignorent. Ce vérificateur teste les trois.
La RFC 9989, qui a remplacé la RFC 7489 en mai 2026, a supprimé la balise pct. Les destinataires qui suivent la nouvelle norme l'ignorent et appliquent la politique à tout le courrier en échec ; les anciens la respectent encore. La nouvelle balise t=y la remplace pour tester en douceur une politique plus stricte.
Quarantine demande au destinataire de traiter le courrier en échec comme suspect, ce qui signifie en pratique le dossier spam ou courrier indésirable. Reject demande au destinataire de refuser le message pendant la livraison, si bien qu'il n'atteint jamais le destinataire. Les deux comptent comme application de la politique ; reject protège le mieux contre le courrier falsifié.
Seulement au résolveur DNS public que vous choisissez, Cloudflare ou Google, car interroger un enregistrement DNS nécessite le nom. Le résolveur voit les noms demandés et votre adresse IP. Rien d'autre ne quitte votre appareil, et l'onglet générateur n'envoie rien du tout.
Toujours bloqué ? Poser une question sur Vérificateur DMARC et toute personne qui connaît la réponse peut répondre. Aucun compte nécessaire.