Construisez un enregistrement DMARC conforme à la RFC 9989, chaque balise expliquée, avec un plan daté de p=none à p=reject et l’enregistrement supplémentaire dont a besoin une boîte de rapport sur un autre domaine. Chargez et vérifiez l’enregistrement publié. Gratuit, sans inscription.
Un enregistrement DMARC est un enregistrement TXT placé sur _dmarc. devant votre domaine. Il indique aux serveurs destinataires quoi faire d’un message dont le domaine « De » n’est confirmé ni par SPF ni par DKIM : le distribuer, le placer dans les spams ou le refuser. Il donne aussi une adresse qui reçoit chaque jour des rapports sur qui envoie du courrier avec votre domaine. DMARC commence par v=DMARC1 et est défini par la RFC 9989, qui a remplacé la RFC 7489 en mai 2026.
DMARC est le seul des trois enregistrements de messagerie qui protège l’adresse que le lecteur voit réellement. SPF et DKIM vérifient chacun quelque chose, DMARC décide.
1. Commencez par p=none et une adresse de rapport. Rien ne change encore pour vos destinataires. Les serveurs de réception vous envoient des rapports agrégés : quels serveurs ont envoyé du courrier avec votre domaine, et si SPF et DKIM ont réussi pour eux. Sans adresse rua, cette étape ne sert à rien, car personne ne voit le résultat.
2. Corrigez chaque expéditeur légitime, puis resserrez. Les rapports révèlent l’outil de newsletter absent de SPF et le service d’assistance qui ne signe pas avec DKIM. Quand deux semaines de rapports ne montrent plus aucun courrier légitime en échec, passez à quarantine, d’abord avec t=y, puis sans.
3. Terminez à reject. Avec p=reject, un message falsifié portant votre domaine dans « De » est refusé avant d’atteindre qui que ce soit. C’est l’objectif ; p=none seul ne fait que documenter le problème.
Le générateur transforme la date de départ que vous saisissez en calendrier, avec un enregistrement prêt pour chaque étape : quatre semaines d’observation, deux semaines de quarantine en mode test, quatre semaines de quarantine, puis reject. Raccourcissez les étapes si les rapports sont propres plus tôt, allongez-les dans le cas contraire.
| Champ | Valeur |
|---|---|
| Type | TXT |
| Nom / Hôte | _dmarc (l’interface ajoute le domaine), ou _dmarc.example.com. lorsque le nom complet est exigé |
| Valeur | l’enregistrement du générateur, sans guillemets |
| TTL | la valeur par défaut ; 3600 secondes conviennent |
L’erreur la plus fréquente concerne le nom : un enregistrement DMARC placé sur le domaine lui-même au lieu de _dmarc n’est jamais trouvé. La deuxième est le doublon. Sur _dmarc, il ne doit exister qu’un seul enregistrement TXT commençant par v=DMARC1 ; avec deux, les destinataires ignorent complètement DMARC. « Charger l’enregistrement publié » affiche chaque enregistrement trouvé sous ce nom.
Si l’adresse de rapport se trouve sur un autre domaine, par exemple chez un service de rapports, ce domaine doit publier un enregistrement qui accepte de recevoir vos rapports. Le générateur l’écrit pour vous : un enregistrement TXT sur example.com._report._dmarc.reports-provider.net avec la valeur v=DMARC1. Sans lui, la plupart des destinataires abandonnent les rapports sans rien dire.
| Balise | Signification | Valeur par défaut du générateur |
|---|---|---|
p |
Politique du domaine : none, quarantine ou reject. Obligatoire. | none |
rua |
Destination des rapports agrégés, en adresses mailto:, séparées par des virgules. | votre saisie |
sp |
Politique des sous-domaines existants. Sans elle, les sous-domaines suivent p. | omise |
np |
Politique des sous-domaines qui n’existent pas du tout. Nouveau dans la RFC 9989. | reject |
adkim |
Alignement DKIM : r (relaxed, les sous-domaines comptent) ou s (strict, correspondance exacte). | r |
aspf |
Alignement SPF, mêmes valeurs. | r |
t |
Mode test : t=y applique la politique un cran plus faible. Nouveau dans la RFC 9989. | désactivé |
ruf |
Destination des rapports d’échec. Facultatif, voir plus bas. | omise |
fo |
Quand générer des rapports d’échec : 0, 1, d ou s. | seulement avec ruf |
np comble une faille appréciée des attaquants : le courrier provenant de sous-domaines inventés comme billing.example.com, qui n’ont jamais existé et n’avaient donc pas de politique propre. Personne n’envoie de courrier légitime depuis un nom qui n’existe pas, donc np=reject est sans risque dès le premier jour, même si p est encore à none. t=y est le nouvel interrupteur de test. psd fait aussi son apparition, mais il s’adresse aux opérateurs de suffixes publics, pas aux domaines ordinaires.
pct disparaît. Il devait appliquer la politique à une partie du courrier et a été mis en œuvre de façon si différente selon les destinataires que personne ne pouvait prévoir le résultat ; t=y le remplace. rf et ri ont aussi été supprimés. Les enregistrements qui les contiennent encore continuent de fonctionner, car les destinataires ignorent les balises qu’ils ne connaissent pas, mais elles n’ont plus d’effet. Quand vous importez un tel enregistrement, le générateur indique quelles balises il a retirées et pourquoi.
Les rapports envoyés à l’adresse ruf peuvent contenir des adresses, des objets et des extraits de vrais messages. Ce sont donc des données personnelles au sens du RGPD, et la plupart des grands fournisseurs de messagerie ne les envoient pas du tout. Le générateur laisse ruf vide par défaut et le contrôle de ce site ne le recommande plus. Les rapports agrégés sous rua ne contiennent que des comptages par serveur expéditeur, et c’est ce dont vous avez besoin.
Le 19 octobre 2026, nous avons lu les enregistrements DMARC des 1 000 domaines .de les mieux classés de la liste Tranco (liste 467YX).
| Constat | Domaines |
|---|---|
| Aucun enregistrement DMARC | 214 |
p=none, donc aucune protection |
333 |
p=quarantine |
214 |
p=reject |
238 |
| DMARC sans adresse de rapport | 148 sur 786 |
Encore avec la balise supprimée pct |
250 sur 786 |
Avec la nouvelle balise np |
4 sur 786 |
| Deux enregistrements DMARC à la fois | 1 |
547 domaines sur 1 000 n’ont pas de DMARC du tout ou s’arrêtent à p=none, ce qui laisse leur adresse « De » ouverte à tous. 148 publient une politique mais aucune adresse de rapport, et ne peuvent donc pas savoir quand il serait sûr de la resserrer. Et seuls quatre utilisent np, la protection la moins coûteuse qu’offre la RFC 9989.
quarantine demande au destinataire de traiter le courrier en échec comme suspect, ce qui revient en pratique au dossier spam. Un message légitime en échec à cause d’un expéditeur oublié peut encore y être retrouvé. reject demande au destinataire de refuser le message dès la remise ; l’expéditeur reçoit un retour, le destinataire ne le voit jamais.
quarantine est l’étape intermédiaire sûre, reject l’état final. Les grands fournisseurs de messagerie exigent DMARC des expéditeurs en masse depuis 2024, et une politique reject est pour eux le signal le plus clair que le courrier envoyé en votre nom est authentifié. Restez à quarantine seulement tant que les rapports montrent encore des sources légitimes que vous n’avez pas corrigées.
DMARC réussit quand SPF ou DKIM réussit pour un domaine qui correspond au domaine « De ». Il ne peut donc pas valoir mieux que ces deux-là. Avant de quitter p=none, chaque service qui envoie avec votre domaine doit soit figurer dans l’enregistrement SPF avec un domaine d’enveloppe correspondant, soit signer avec une clé DKIM de votre domaine. DKIM est le plus robuste des deux, car une signature survit au transfert, SPF non.
Une fois DMARC en quarantine ou reject, le domaine remplit aussi la condition pour BIMI, l’enregistrement qui affiche votre logo à côté de vos messages.
Les rapports agrégés arrivent sous forme de fichiers XML compressés, en général une fois par jour de chaque grand fournisseur qui a reçu du courrier avec votre domaine. Chaque fichier indique, par adresse IP expéditrice, combien de messages en sont venus, si SPF et DKIM ont réussi, et si les domaines pour lesquels ils ont réussi étaient alignés sur votre domaine « De ».
Trois questions règlent presque tout :
Le XML n’est pas fait pour être lu à la main. Une boîte de rapport chez un service DMARC ou un analyseur auto-hébergé comme parsedmarc le transforme en tableau. Si la boîte est sur un autre domaine que le vôtre, publiez l’enregistrement d’autorisation que le générateur écrit, sinon les rapports n’arrivent jamais.
Sans sp, chaque sous-domaine hérite de la politique du domaine principal. C’est ce que veulent la plupart des domaines. Ne définissez sp que si un sous-domaine a besoin d’une autre politique, en général plus faible pour un sous-domaine dont vous n’avez pas encore corrigé les expéditeurs : p=reject; sp=quarantine.
np est différent : il s’applique aux sous-domaines qui n’existent pas du tout dans le DNS. Un service.example.com falsifié, jamais créé, reçoit la politique np ; un vrai newsletter.example.com reçoit p ou sp. Comme un nom inexistant ne peut pas envoyer de courrier légitime, le générateur fixe np=reject dès le départ, même si la politique principale est encore à none.
Un sous-domaine peut aussi publier son propre enregistrement _dmarc, qui prime alors sur le sp du domaine parent.
v=DMARC1; p=none; np=reject; rua=mailto: suivi d’une adresse que vous lisez vraiment. Cela collecte des rapports sans modifier la distribution et bloque le courrier des sous-domaines inexistants. Passez à quarantine dès que les rapports montrent que vos propres services réussissent SPF ou DKIM.
En enregistrement TXT sur le nom _dmarc devant votre domaine, donc _dmarc.example.com. Dans la plupart des interfaces DNS, vous saisissez _dmarc comme nom et l’interface ajoute le domaine. Un enregistrement DMARC placé sur le domaine lui-même n’est lu par aucun destinataire.
Non. L’enregistrement est construit dans le navigateur. « Charger l’enregistrement publié » lit l’enregistrement public sur _dmarc du domaine via notre résolveur, et « Vérifier avec le DNS en temps réel » envoie l’enregistrement construit au même validateur que l’Email Security Check. Aucun des deux ne le conserve.
Avec quarantine, les destinataires placent le courrier en échec dans le dossier spam ; avec reject, ils le refusent dès la remise et l’expéditeur reçoit un retour. quarantine est l’étape la plus sûre en chemin, reject la protection que vous visez à la fin.
Vous pouvez publier DMARC à p=none tout de suite : ses rapports sont le moyen le plus rapide de savoir qui envoie pour vous. Avant quarantine ou reject, en revanche, chaque expéditeur légitime doit avoir SPF ou DKIM aligné sur votre domaine, sinon votre propre courrier finit en spam ou est refusé.
La RFC 9989 l’a supprimé. Les destinataires appliquaient le pourcentage de façon si différente que le résultat était imprévisible. Utilisez t=y pendant que vous testez une politique plus stricte et retirez-le quand les rapports sont propres. Les anciens enregistrements avec pct fonctionnent toujours ; les destinataires qui suivent la nouvelle norme ignorent simplement la balise.
En général pour l’une de trois raisons : l’enregistrement n’a pas de balise rua, l’adresse est sur un autre domaine qui n’a pas publié l’enregistrement d’autorisation, ou l’enregistrement est sous le mauvais nom. Le générateur écrit l’enregistrement d’autorisation pour les adresses externes, et « Charger l’enregistrement publié » montre où se trouve réellement le vôtre.
L’enregistrement est assemblé dans le navigateur selon la RFC 9989 : les balises que la norme a supprimées ne sont jamais écrites, np et t sont proposées, et les rapports d’échec sont facultatifs. Le plan de déploiement n’est qu’un calcul de dates à partir de la date de départ saisie ; il ne voit pas vos rapports, les dates sont donc une proposition, pas une promesse.
« Charger l’enregistrement publié » interroge chaque enregistrement TXT sur _dmarc du domaine et applique le validateur de l’Email Security Check, qui évalue la politique, l’adresse de rapport et les réglages d’alignement. « Vérifier avec le DNS en temps réel » applique le même validateur à l’enregistrement construit, sans aucune requête DNS. Les adresses de rapport sont vérifiées sur leur forme, jamais contactées, et l’enregistrement d’autorisation d’une adresse externe est généré mais pas interrogé.
DMARC lui-même ne peut pas vous dire lesquels de vos expéditeurs échouent. Seuls les rapports agrégés le peuvent, et les lire constitue le vrai travail d’un déploiement DMARC.