Aller au contenu

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"
  1. _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.

  2. v=DMARC1La version

    Obligatoire et première. Un enregistrement dont ce n'est pas la première balise est ignoré en entier.

  3. p=quarantineLa politique

    Obligatoire et deuxième. Ce que vous demandez aux destinataires de faire d'un message qui échoue : rien, quarantaine, ou rejet.

  4. sp=rejectLa politique des sous-domaines

    Facultative. 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.

  5. rua=mailto:...Où envoyer les rapports

    L'adresse qui recevra les bilans quotidiens. C'est la balise qui a le plus de valeur pratique : sans elle, on pilote à l'aveugle.

  6. adkim=sL'alignement DKIM

    Strict ici : le domaine signataire doit être exactement le domaine affiché. En souple, un sous-domaine suffirait.

  7. pct=25La part concernée

    La 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à.

BaliseValeurs admisesPar défaut et effet
vDMARC1Obligatoire, en première position.
pnone, quarantine, rejectObligatoire, en deuxième position. none n'agit pas et se contente d'observer.
spnone, quarantine, rejectLa valeur de p. À poser explicitement quand les sous-domaines doivent être traités autrement.
ruaune ou plusieurs adresses mailto:Aucune. Sans rua, aucun rapport n'est envoyé et la politique se règle à l'aveugle.
rufune ou plusieurs adresses mailto:Aucune. Rapports d'échec message par message, que la plupart des grands destinataires n'envoient pas.
pctde 0 à 100100. La politique s'applique à cette part des messages en échec.
adkimr (souple) ou s (strict)r. En souple, un sous-domaine signataire suffit ; en strict, il faut le domaine exact.
aspfr (souple) ou s (strict)r. Même logique pour le domaine validé par SPF.
fo0, 1, d, s0. Décide dans quels cas un rapport d'échec est demandé : ici, seulement si les deux contrôles échouent.
rfafrfafrf. Le format des rapports d'échec.
riun nombre de secondes86400, 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.

Sans inscription, sans e-mail à laisser. Vous pouvez coller une adresse complète : nous en extrayons le domaine.

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. 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. 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 SPF ou DKIM avec le bon domaine ? Tout se règle ici, pendant quelques semaines.

  3. 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. 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. 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 DMARC sur 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 SPF qui 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.