Exemples d'enregistrement DMARC à copier (et à comprendre)

v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr

Modèle 2 — Quarantine (première application)

Une fois les sources alignées, la politique monte d'un cran. Le courrier en échec part en indésirable au lieu de la boîte. On ajoute ici sp et np pour couvrir les sous-domaines, et t=y pour signaler une phase de test.

v=DMARC1; p=quarantine; sp=quarantine; np=reject; t=y; rua=mailto:dmarc@exemple.fr

À noter, np=reject d'emblée : les sous-domaines inexistants ne portent aucun courrier légitime, autant les verrouiller tout de suite (voir la politique de sous-domaine). Une fois les rapports propres et le mode test rassurant, t=y se retire.

Modèle 3 — Reject (la cible)

L'application maximale. Le courrier falsifié au nom du domaine est refusé avant d'arriver. C'est l'objectif de la plupart des déploiements, à atteindre une fois les rapports démontrés propres depuis plusieurs semaines.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@exemple.fr

Symétrique et net : racine, sous-domaines existants et inexistants, tous en reject. Si un sous-domaine légitime a besoin d'une marge, inutile de baisser sp pour tout le monde — mieux vaut lui donner son propre enregistrement dédié. La séquence complète pour arriver ici sans casse est décrite dans atteindre p=reject sans casser ses emails ; pour jauger la préparation d'un domaine, la checklist d'éligibilité répond à la question.

Modèle 4 — Domaine parqué ou sans email

Un domaine détenu d'où aucun courrier ne part (marque défensive, ancien nom, réservation) ne doit pas rester sans DMARC — ce serait une cible d'usurpation gratuite. La politique la plus stricte s'y applique d'emblée, sans phase d'observation : par définition, aucun email légitime ne peut être bloqué.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@exemple.fr

C'est le même que le modèle reject, mais il se pose immédiatement, sans passer par none ni quarantine, puisqu'il n'y a rien à observer. Un domaine parqué protégé est une porte de moins pour les fraudeurs.

Où publier l'enregistrement

Le point qui bloque le plus de débutants n'est pas la valeur, mais l'endroit. L'enregistrement se publie chez l'hébergeur DNS (celui qui gère la zone), en tant qu'enregistrement TXT, sur le nom _dmarc. Selon l'interface, la saisie porte soit sur le nom complet _dmarc.exemple.fr, soit simplement sur _dmarc (l'interface ajoute le domaine automatiquement). La valeur est la chaîne v=DMARC1; …, sans guillemets à ajouter à la main dans la plupart des interfaces.

Attention à une erreur classique : l'enregistrement ne se publie pas sur exemple.fr directement, mais bien sur le sous-nom _dmarc. Un enregistrement DMARC posé à la racine ne sera jamais trouvé par les destinataires. Autre point : la propagation DNS n'est pas instantanée — après publication, il faut compter de quelques minutes à quelques heures avant que le nouvel enregistrement soit visible partout, selon le TTL de la zone. Conclure qu'il « ne marche pas » cinq minutes après l'avoir posé est prématuré ; le bon réflexe est de vérifier qu'il est bien lu une fois la propagation faite.

Réglages par fournisseur

L'enregistrement DMARC lui-même est identique quel que soit le fournisseur de messagerie — c'est une propriété du domaine, pas de la plateforme mail. Ce qui change d'un fournisseur à l'autre, c'est l'alignement (SPF/DKIM) que DMARC vient vérifier. Quelques repères :

• Google Workspace : la signature DKIM s'active depuis la console d'administration (Apps → Google Workspace → Gmail → Authentifier l'e-mail), qui fournit un enregistrement DKIM à publier. Une fois DKIM aligné sur le domaine, les modèles ci-dessus fonctionnent tels quels.
• Microsoft 365 : DKIM s'active dans le centre de sécurité (ou via PowerShell) et signe avec le domaine. SPF pour Microsoft passe par l'include:spf.protection.outlook.com. Le détail SPF est dans SPF pour Microsoft 365 et Google Workspace.
• OVH, Scaleway et hébergeurs FR : la mécanique est la même — publier le TXT _dmarc dans la zone DNS, et s'assurer que la plateforme d'envoi signe en DKIM avec d=exemple.fr.
• Plateformes tierces (marketing, facturation, transactionnel) : chacune fournit sa propre procédure DKIM à la marque de l'expéditeur. C'est là que se joue l'alignement réel, source par source.

Autrement dit, il n'existe pas d'« enregistrement DMARC spécial Gmail » ou « spécial Microsoft » : il existe un enregistrement DMARC pour un domaine donné, et un travail d'alignement à faire chez chaque expéditeur.

Alignement relâché ou strict (adkim / aspf)

Deux balises optionnelles méritent un mot, car elles reviennent souvent dans les modèles trouvés en ligne : adkim et aspf, qui contrôlent la rigueur de l'alignement. En mode relâché (r, la valeur par défaut), un sous-domaine compte comme aligné avec le domaine organisationnel : un DKIM signé d=mail.exemple.fr aligne un From: en exemple.fr. En mode strict (s), les deux doivent correspondre exactement.

Le conseil pratique : rester en relâché sauf raison précise. Le mode strict casse des configurations parfaitement légitimes (plateformes qui signent avec un sous-domaine technique) et n'apporte un gain que dans des scénarios de sécurité très pointus. Une bascule en strict sans raison identifiée est une bascule inutile — c'est pourquoi aucun des modèles ci-dessus ne mentionne ces balises : leur absence est le bon réglage pour la quasi-totalité des domaines.

Faut-il ajouter ruf (rapports forensiques) ?

Beaucoup d'exemples anciens incluent une balise ruf= à côté de rua=. En 2026, c'est rarement utile : la plupart des grands fournisseurs (Google, Microsoft, Yahoo) n'envoient plus de rapports forensiques, et ceux-ci soulèvent des questions de vie privée, car ils peuvent contenir des en-têtes voire des extraits de messages réels. Sauf besoin diagnostic précis et cadre RGPD maîtrisé, ruf se laisse de côté au démarrage. La différence entre les deux types de rapports est détaillée dans RUA vs RUF, et l'angle vie privée dans rapports forensiques et RGPD. C'est pour cette raison qu'aucun modèle ci-dessus ne contient ruf : commencer simple évite de collecter des données sensibles dont personne n'a l'usage.

Erreurs de syntaxe fréquentes

• Oublier rua. Un DMARC sans adresse de rapport « fonctionne », mais prive de toute visibilité : impossible de savoir qui envoie au nom du domaine, ni si le durcissement est envisageable.
• Se tromper de nom d'hôte. L'enregistrement va sur _dmarc, pas sur la racine du domaine.
• Mélanger plusieurs enregistrements DMARC. Il ne doit y avoir qu'un seul enregistrement TXT commençant par v=DMARC1 sur _dmarc. Deux enregistrements = comportement indéfini, souvent ignoré.
• Copier une adresse rua d'un autre domaine. Envoyer les rapports à dmarc@autre-domaine.fr exige une autorisation côté domaine récepteur (voir configurer l'adresse rua). Pour commencer, une adresse du domaine lui-même évite la question.
• Laisser t=y en place. Le mode test est une phase de la montée, pas un réglage permanent.

Traiter l'enregistrement comme de la configuration

Une dernière habitude sépare les équipes sereines de celles qui paniquent des mois plus tard : garder une trace écrite de chaque modification de l'enregistrement DMARC. Les interfaces DNS offrent rarement un historique — une valeur écrasée disparaît, et le raisonnement qui l'accompagnait avec elle. La date de chaque changement, ce qui a été modifié et pourquoi, se consigne à l'endroit où l'équipe documente déjà son infrastructure. Reste à désigner un responsable de l'entrée _dmarc, pour qu'un collègue bien intentionné ne « nettoie » pas une balise qu'il ne reconnaît pas. Les modifications DMARC sont rares par nature — c'est justement pour cela que la mémoire flanche : le jour d'un incident de délivrabilité, savoir répondre à « que disait l'enregistrement avant, et qui l'a changé ? » transforme une après-midi d'archéologie en une vérification de cinq minutes.

Et ensuite ?

Un modèle collé n'est qu'un début. Le vrai travail — aligner chaque source pour que le durcissement ne bloque personne — commence après. Une fois l'enregistrement publié, il se vérifie du point de vue d'un destinataire avec l'analyseur DMARC gratuit : il confirme que la syntaxe est valide, que la politique est bien lue, et surtout que les sources s'alignent comme prévu. C'est le moyen le plus rapide de transformer un modèle générique en une protection réellement adaptée à un domaine — et d'attraper la faute de frappe ou l'enregistrement en double qui, sinon, passerait inaperçue pendant des mois.