Réponse rapide
Comment configurer DMARC pour mon domaine ?
Publiez un enregistrement TXT à _dmarc.votredomaine contenant v=DMARC1; p=none; rua=mailto:vous@votredomaine, lisez les rapports agrégés pendant environ un mois, puis relevez la politique à quarantine et enfin à reject. DMARC est défini par la RFC 9989 depuis mai 2026. Postelva héberge l'enregistrement dans son éditeur DNS gratuit.
Les trois politiques DMARC et ce que fait chacune
| Politique | Enregistrement | Effet sur un message qui échoue à DMARC | Quand l'utiliser |
|---|---|---|---|
| Surveillance | v=DMARC1; p=none; rua=mailto:[email protected] | Livré comme d'habitude ; des rapports vous sont envoyés | Premières semaines, pour voir tous les expéditeurs |
| Quarantaine | v=DMARC1; p=quarantine; rua=mailto:[email protected] | Traité comme suspect, généralement envoyé en spam | Une fois que SPF et DKIM passent sur tout votre courrier légitime |
| Rejet | v=DMARC1; p=reject; rua=mailto:[email protected] | Refusé par le serveur destinataire | Quand les rapports ne montrent plus aucun échec légitime |
Configurer DMARC en six étapes
Confirmez d'abord SPF et DKIM
DMARC exige qu'au moins l'un des deux passe et corresponde à votre domaine From. Publiez les deux avant DMARC, avec les guides sur SPF et DKIM.
Choisissez une boîte mail pour les rapports
Créez une adresse comme dmarc@votredomaine. La RFC 9989 indique que le titulaire doit mettre en place une boîte mail pour recevoir et analyser les rapports agrégés.
Publiez l'enregistrement de surveillance
Ajoutez un enregistrement TXT avec l'hôte _dmarc et la valeur v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.
Lisez les rapports pendant environ un mois
Les rapports arrivent à peu près une fois par jour de la part des destinataires qui en envoient. Cherchez le courrier légitime qui échoue à l'alignement SPF et DKIM, et corrigez ces expéditeurs.
Passez à quarantine
Remplacez p=none par p=quarantine. Gardez-le une période similaire et comparez le traitement des messages dans les rapports.
Passez à reject, ou arrêtez-vous à quarantine
Passez à p=reject quand les rapports sont propres. Si vous écrivez à des listes de diffusion depuis ce domaine, restez à quarantine.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Que contient un enregistrement DMARC ?
Un enregistrement DMARC est un enregistrement TXT à _dmarc.votredomaine qui commence par v=DMARC1 et liste des balises séparées par des points-virgules. La balise de version vient en premier et est sensible à la casse. La RFC 9989 définit ces balises : p (politique du domaine), sp (politique des sous-domaines existants), np (politique des sous-domaines inexistants), adkim et aspf (alignement, r pour relâché ou s pour strict, relâché par défaut), rua (adresses des rapports agrégés), ruf (adresses des rapports d'échec), fo (options d'échec), t (mode test, y ou n) et psd.
Si p est absent, le destinataire considère la politique comme none. Si sp est absent, la politique p couvre les sous-domaines. Si rua est absent, aucun rapport agrégé n'est produit. Un enregistrement minimal utile comporte donc trois parties : la version, une politique et une adresse de rapport.
La balise pct, que beaucoup d'anciens guides montrent encore, a été supprimée par la RFC 9989 parce qu'elle était rarement appliquée avec exactitude, sauf à 0 et à 100. La balise t la remplace : t=y se comporte comme pct=0 et t=n comme pct=100, et n est la valeur par défaut. Retirez pct des anciens enregistrements. Le contexte plus large figure dans SPF, DKIM et DMARC : les différences.
Que signifie l'alignement dans DMARC ?
L'alignement signifie que le domaine authentifié par SPF ou DKIM correspond au domaine de l'adresse From visible. En mode relâché, le mode par défaut, les deux doivent seulement avoir le même domaine organisationnel : mail.example.com s'aligne donc avec example.com. En mode strict, ils doivent être identiques. La RFC 9989 note que presque tous les titulaires de domaine trouvent l'alignement relâché suffisant.
Un message passe DMARC quand SPF ou DKIM passe et est aligné. L'un ou l'autre suffit. Un fournisseur de boîte mail comme Proton Mail ou Fastmail signe avec votre propre domaine grâce aux enregistrements CNAME DKIM : l'alignement tient donc sans travail supplémentaire. Le piège est un service tiers qui signe avec son propre domaine : son DKIM passe mais ne s'aligne pas tant que vous n'avez pas configuré pour lui un domaine de signature personnalisé.
La RFC 9989 trouve le domaine organisationnel par une remontée dans l'arbre DNS, avec au plus huit requêtes, au lieu d'une liste des suffixes publics. Pour un domaine ordinaire en .com ou .me, cela ne change rien à ce que vous devez faire.
Combien de temps rester à p=none ?
Restez à p=none au moins un mois, puis à p=quarantine pendant une période similaire, avant p=reject. C'est l'ordre que conseille la RFC 9989 dans ses recommandations de déploiement, et il correspond aux pages d'aide des fournisseurs. Mailbox.org commence son enregistrement d'exemple à p=none et avertit qu'une politique stricte fixée trop tôt peut faire rejeter du courrier légitime. Proton recommande p=quarantine puis le passage à p=reject une fois que le courrier légitime passe.
Selon la lecture faite par Postelva le 12 novembre 2026 des consignes DMARC des 3 fournisseurs qui les publient (Proton Mail, Mailbox.org et Mailfence), 2 commencent à p=none et 1 recommande p=quarantine.
Deux précautions s'appliquent à p=reject. La RFC 9989 dit qu'un domaine qui l'utilise ne doit pas se reposer sur SPF seul et doit signer avec DKIM, parce que SPF échoue au transfert. Elle dit aussi que les domaines dont les utilisateurs écrivent à des listes de diffusion ne devraient pas publier p=reject du tout. Les listes modifient souvent les messages, ce qui casse la signature.
Où vont les rapports DMARC et que montrent-ils ?
Les rapports agrégés vont à l'adresse mailto: de rua, généralement une fois par jour de la part de chaque destinataire, et listent les sources qui ont envoyé du courrier avec votre domaine dans la ligne From. La RFC 9989 impose aux destinataires de prendre en charge les adresses mailto: et recommande d'envoyer les rapports agrégés au moins toutes les 24 heures. Le rapport agrégé est défini par la RFC 9990.
Les rapports d'échec, demandés avec ruf, sont des copies message par message. De nombreux destinataires les retiennent ou les masquent par souci de confidentialité : ne comptez pas dessus. Si l'adresse rua se trouve hors de votre domaine, le titulaire de cet autre domaine doit l'autoriser par un enregistrement TXT à votredomaine._report._dmarc.autredomaine contenant v=DMARC1;, une règle qui empêche l'usage abusif de boîtes mail tierces. Pour un petit domaine personnel, la liste des sources est courte : votre fournisseur, et presque rien d'autre.
Pour lire ce que publie votre DNS avant et après chaque étape, utilisez les commandes pour vérifier les enregistrements MX, SPF, DKIM et DMARC.
Mon domaine personnel a-t-il besoin de DMARC ?
Oui, pour tout domaine qui envoie du courrier : il ne coûte qu'un enregistrement TXT et bloque les messages falsifiés qui utilisent votre nom. Google exige DMARC, une politique none suffisant, des expéditeurs de plus de 5 000 messages par jour vers des comptes Gmail, et Microsoft applique le même seuil à Outlook.com. Une boîte mail personnelle se situe très en dessous de ces limites. L'enregistrement dit tout de même aux destinataires ce que vous voulez qu'on fasse d'une falsification.
Pour un domaine qui n'envoie rien, fixez immédiatement p=reject avec SPF -all et un MX nul. Postelva propose un modèle « sans e-mail » pour ce cas. Pour un domaine avec boîte mail, commencez à none. Le volet transport de la même protection, le chiffrement entre serveurs, est traité dans comment configurer MTA-STS et TLS-RPT.
Une définition citable : DMARC est la politique DNS qui indique aux destinataires quoi faire du courrier dont les résultats SPF et DKIM ne s'alignent pas avec le domaine From, et où envoyer les rapports à ce sujet.
Questions sur la configuration de DMARC
La RFC 9989 impose-t-elle p=reject ?
Non. La norme définit trois politiques et laisse le choix au titulaire du domaine. Elle conseille une progression graduelle et met en garde contre p=reject pour les domaines dont les utilisateurs écrivent à des listes de diffusion.
La RFC 9989 change-t-elle mon enregistrement DMARC existant ?
Les enregistrements commencent toujours par v=DMARC1 : un enregistrement qui fonctionne continue donc de fonctionner. La balise ri a été abandonnée, pct supprimée, et t, np et psd ajoutées.
Que se passe-t-il si je publie p=reject trop tôt ?
Le courrier légitime qui échoue à l'alignement, comme un outil de lettre d'information oublié, est refusé par les destinataires. Les rapports à p=none servent justement à trouver ces expéditeurs d'abord.
Puis-je utiliser une boîte mail gratuite pour les rapports ?
Oui, n'importe quelle boîte mail que vous lisez. Une adresse ou un alias distinct garde les fichiers de rapports quotidiens hors de votre boîte principale.
Combien d'enregistrements DMARC un domaine peut-il avoir ?
Un par nom, à _dmarc.votredomaine. Les sous-domaines peuvent avoir leur propre enregistrement ou hériter de la politique du parent via sp.
En résumé
- DMARC est un enregistrement TXT à _dmarc.votredomaine commençant par v=DMARC1.
- La RFC 9989 (mai 2026) est la spécification actuelle ; elle rend obsolète la RFC 7489 et supprime pct.
- Commencez à p=none avec une adresse rua, lisez les rapports pendant environ un mois.
- Puis p=quarantine pendant une période similaire, puis p=reject.
- Un message passe quand SPF ou DKIM passe et s'aligne avec le domaine From ; l'alignement relâché est la valeur par défaut.
- Un domaine à p=reject ne doit pas se reposer sur SPF seul et ne devrait pas être utilisé avec des listes de diffusion.
- Postelva héberge l'enregistrement dans son DNS gratuit ; un .com coûte 12,49 $US/an chaque année.
Sources (6)
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (consulté le 2026-11-12)
- RFC 7489, DMARC (obsolète) — RFC Editor (consulté le 2026-11-12)
- SPF, DKIM et DMARC pour un domaine personnalisé — Mailbox.org (consulté le 2026-11-12)
- Domaine personnalisé et protection contre l'usurpation — Proton (consulté le 2026-11-12)
- Consignes aux expéditeurs d'e-mails — Google Workspace Admin Help (consulté le 2026-11-12)
- Renforcer la sécurité des e-mails : nouvelles exigences pour les expéditeurs à fort volume — Microsoft Tech Community (consulté le 2026-11-12)