Guide de référence
Qu'est-ce que DMARC ?
SPF et DKIM produisent des verdicts. DMARC est ce qui les relie à votre nom, exige qu'ils désignent le domaine affiché, et dit aux destinataires quoi faire quand ils échouent.
8 min de lectureMis à jour le 12 septembre 2026
En bref
DMARC est un enregistrement TXT publié sous le nom _dmarc.votredomaine. Il demande que le domaine validé par SPF ou par DKIM soit bien celui qui s'affiche dans la messagerie du destinataire, il indique quoi faire quand ce n'est pas le cas — ne rien faire, mettre en quarantaine ou rejeter — et il demande des rapports quotidiens sur ce qui part en votre nom.
À quoi sert DMARC
Un message peut parfaitement passer SPF et DKIM tout en affichant votre nom sans votre accord. Il suffit que l'expéditeur valide un domaine à lui, qu'il contrôle, et qu'il écrive le vôtre dans le champ que l'humain voit. Les deux contrôles réussissent, et l'usurpation passe. DMARC ferme exactement cette porte : il exige que le domaine validé et le domaine affiché soient le même.
Il ajoute une seconde chose qu'aucun des deux autres ne fournit : le retour. Les grands hébergeurs de messagerie envoient chaque jour un rapport listant ce qui a été reçu en votre nom, depuis quelles adresses, et avec quel résultat. C'est la seule manière de savoir ce qui écrit vraiment sous votre domaine — y compris l'outil de facturation que personne n'avait signalé.
Enfin, DMARC porte une décision. C'est le propriétaire du domaine qui dit aux destinataires du monde entier ce qu'il souhaite voir faire d'un message qui échoue. Cette décision se prend en dernier, après avoir regardé les rapports — jamais le premier jour.
Un enregistrement DMARC, terme par terme
Il vit toujours sous le même nom, quelle que soit l'extension du domaine, et se lit comme une suite de balises séparées par des points-virgules.
_dmarc.example.com. 3600 IN TXT
"v=DMARC1; p=quarantine; sp=reject; rua=mailto:rapports@example.com; adkim=s; aspf=r; pct=25"_dmarcLe nom réservéToujours ce préfixe, souligné compris, devant le domaine. Publier l'enregistrement à la racine du domaine au lieu de ce nom est l'erreur la plus fréquente, et elle est silencieuse.
v=DMARC1La versionObligatoire et première. Un enregistrement dont ce n'est pas la première balise est ignoré en entier.
p=quarantineLa politiqueObligatoire et deuxième. Ce que vous demandez aux destinataires de faire d'un message qui échoue : rien, quarantaine, ou rejet.
sp=rejectLa politique des sous-domainesFacultative. Sans elle, les sous-domaines héritent de la politique du domaine. Avec elle, on peut être plus sévère sur ce qui n'envoie rien que sur ce qui envoie.
rua=mailto:...Où envoyer les rapportsL'adresse qui recevra les bilans quotidiens. C'est la balise qui a le plus de valeur pratique : sans elle, on pilote à l'aveugle.
adkim=sL'alignement DKIMStrict ici : le domaine signataire doit être exactement le domaine affiché. En souple, un sous-domaine suffirait.
pct=25La part concernéeLa politique ne s'applique qu'à une fraction des messages en échec. Sert à monter en charge progressivement, pas à rester là.
Les balises DMARC et leurs valeurs
Deux balises sont obligatoires, dans cet ordre. Toutes les autres ont une valeur par défaut, et connaître ces valeurs évite d'écrire ce qui s'applique déjà.
| Balise | Valeurs admises | Par défaut et effet |
|---|---|---|
| v | DMARC1 | Obligatoire, en première position. |
| p | none, quarantine, reject | Obligatoire, en deuxième position. none n'agit pas et se contente d'observer. |
| sp | none, quarantine, reject | La valeur de p. À poser explicitement quand les sous-domaines doivent être traités autrement. |
| rua | une ou plusieurs adresses mailto: | Aucune. Sans rua, aucun rapport n'est envoyé et la politique se règle à l'aveugle. |
| ruf | une ou plusieurs adresses mailto: | Aucune. Rapports d'échec message par message, que la plupart des grands destinataires n'envoient pas. |
| pct | de 0 à 100 | 100. La politique s'applique à cette part des messages en échec. |
| adkim | r (souple) ou s (strict) | r. En souple, un sous-domaine signataire suffit ; en strict, il faut le domaine exact. |
| aspf | r (souple) ou s (strict) | r. Même logique pour le domaine validé par SPF. |
| fo | 0, 1, d, s | 0. Décide dans quels cas un rapport d'échec est demandé : ici, seulement si les deux contrôles échouent. |
| rf | afrf | afrf. Le format des rapports d'échec. |
| ri | un nombre de secondes | 86400, soit un rapport par jour. La valeur est une demande, pas une garantie. |
Vérifiez sur votre domaine, tout de suite
Entrez un nom de domaine : l'outil lit son DMARC, sa politique, l'adresse de ses rapports, et vérifie que SPF et DKIM suivent.
L'escalier, de l'observation au rejet
Passer directement au rejet est la façon la plus rapide de couper du courrier légitime dont personne ne vous avait parlé. Les cinq marches se montent dans cet ordre, et on ne saute pas la première.
- 1
Observer
Publier la politique la plus douce avec une adresse de rapports. Rien ne change pour personne, et les bilans quotidiens commencent à arriver.
v=DMARC1; p=none; rua=mailto:rapports@example.com
- 2
Lire et réparer
Les rapports listent chaque source qui écrit en votre nom. Pour chacune, deux questions : est-elle légitime, et si oui passe-t-elle
SPFouDKIMavec le bon domaine ? Tout se règle ici, pendant quelques semaines. - 3
Mettre en quarantaine une part
Quand plus rien de légitime n'échoue, on commence à agir sur une fraction seulement. Si un envoi avait été oublié, il ne disparaît pas d'un coup.
v=DMARC1; p=quarantine; pct=25; rua=mailto:rapports@example.com
- 4
Étendre à tout
La même politique, sans fraction. Les messages qui échouent partent en indésirable chez les destinataires qui appliquent la demande.
v=DMARC1; p=quarantine; rua=mailto:rapports@example.com
- 5
Rejeter
La dernière marche : les messages en échec sont refusés avant d'atteindre une boîte. C'est la seule politique qui protège réellement votre nom, et elle ne se pose qu'après les quatre autres.
v=DMARC1; p=reject; rua=mailto:rapports@example.com
Alignement souple ou strict
C'est le cœur de DMARC, et le point qu'on comprend en une fois quand on voit les deux côte à côte. La question posée est toujours la même : le domaine validé est-il le domaine affiché ?
Souple (r)
Strict (s)
- Ce qui est comparé
- Le domaine racine, sous-domaines confondus.Le nom exact, caractère pour caractère.
- Affiché : contact@example.com, validé : mail.example.com
- Aligné. Les deux relèvent du même domaine racine.Non aligné. Le contrôle échoue.
- Affiché : contact@example.com, validé : example.net
- Non aligné.Non aligné.
- Quand le choisir
- Par défaut, et dans presque tous les cas. Les prestataires signent souvent depuis un sous-domaine.Quand on maîtrise chaque envoi et qu'on veut fermer jusqu'aux sous-domaines.
DMARC réussit dès qu'UN des deux contrôles est à la fois valide et aligné. Il n'exige pas les deux : c'est ce qui permet à un message réexpédié, où SPF a forcément échoué, de passer grâce à sa signature.
Les erreurs qui rendent DMARC inopérant
L'enregistrement est publié à la racine du domaine
Ce qui le provoque : L'interface DNS propose un champ « nom » qu'on laisse vide par habitude, et l'enregistrement atterrit sur le domaine au lieu de _dmarc.
Le geste qui corrige : Republier sous le nom _dmarc. Aucun message d'erreur ne signale la confusion : l'enregistrement existe, simplement personne ne le trouve.
Le rejet est posé dès le premier jour
Ce qui le provoque : On applique une recommandation lue quelque part sans passer par l'étape d'observation, et sans savoir ce qui envoie du courrier au nom du domaine.
Le geste qui corrige : Revenir à la politique la plus douce, lire les rapports pendant quelques semaines, puis remonter l'escalier marche par marche.
Les rapports n'arrivent jamais
Ce qui le provoque : L'adresse de rapports appartient à un autre domaine que celui surveillé. Ce cas exige une autorisation publiée côté domaine destinataire, que personne n'a posée.
Le geste qui corrige : Soit recevoir les rapports sur une adresse du domaine lui-même, soit publier l'enregistrement d'autorisation croisée chez le domaine qui reçoit.
Les domaines de réservation ne sont pas protégés
Ce qui le provoque : On publie
DMARCsur le domaine du site et on oublie les variantes déposées autour, qui n'envoient rien — et sont donc les cibles les plus commodes.Le geste qui corrige : Sur chaque domaine qui n'envoie pas de courrier, publier une politique de rejet et un
SPFqui n'autorise personne. Deux enregistrements, aucune maintenance.
Les questions qu'on se pose ensuite
DMARC protège-t-il les messages que je reçois ?
Non. DMARC protège votre domaine chez les autres : il dit aux serveurs du monde entier quoi faire d'un message qui prétend venir de chez vous. Ce que vous recevez dépend des politiques publiées par les domaines expéditeurs et de votre propre filtrage.
Faut-il activer les rapports d'échec ?
Rarement. Ils contiennent des extraits de messages réels, donc des données personnelles, et la plupart des grands destinataires ne les envoient pas. Les rapports agrégés quotidiens suffisent à piloter la montée en charge.
À quoi sert vraiment la fraction ?
À rendre une erreur réversible. Si un service légitime avait été oublié, appliquer la politique à un quart des messages laisse passer les trois autres quarts, et le problème se voit avant d'être total.
Un sous-domaine sans DMARC est-il couvert ?
Oui, par la politique du domaine parent, ou par la balise de politique des sous-domaines si elle est présente. C'est la différence avec SPF, où chaque nom doit publier le sien.
Une politique posée en juin peut avoir disparu en septembre
Un changement d'hébergeur DNS, une zone réimportée depuis une sauvegarde, un enregistrement écrasé : la politique s'évapore sans que rien ne casse visiblement. DomainVigil relit le DMARC de chacun de vos domaines tous les jours et vous écrit s'il change ou s'il disparaît.
Cinq domaines gratuits, pour toujours. Sans carte bancaire.
Les autres guides de référence
- SPF : la liste des serveurs autorisés à écrire en votre nom
- DKIM : la signature qui voyage avec le message
- DNSSEC : la signature des réponses DNS, et ce qu'elle coûte quand elle casse
- CAA : la liste des autorités autorisées à émettre vos certificats
- TTL : combien de temps une réponse DNS reste en cache
- A et AAAA : les deux façons de dire où se trouve un nom
- CNAME : l'alias DNS, et les quatre choses qu'il ne sait pas faire
- MX : où va le courrier d'un domaine, et dans quel ordre
- WHOIS et RDAP : lire la fiche d'état civil d'un domaine
- La chaîne de certificats : trois maillons, et celui qu'on oublie
- HSTS : forcer le HTTPS, et le piège de la marche arrière