DMARC : définir une politique et recevoir des rapports sur son domaine

DMARC (Domain-based Message Authentication, Reporting and Conformance) complète SPF et DKIM sur deux points : il exige que l'identité authentifiée soit alignée avec le domaine visible dans le champ From:, et il permet au propriétaire du domaine de dire aux routeurs quoi faire des messages qui échouent, tout en recevant des rapports. DMARC est décrit dans la RFC 7489 ; une révision, DMARCbis, est en cours au sein du groupe de travail DMARC de l'IETF.

Alignement : le cœur du mécanisme#

Un message est conforme DMARC si au moins une des deux conditions est remplie :

• SPF passe et le domaine du MAIL FROM est aligné avec le domaine du From: ;
• DKIM passe et le domaine d= de la signature est aligné avec le domaine du From:.

L'alignement est dit relaxed (par défaut) quand les deux domaines partagent le même domaine organisationnel (news.example.com et example.com), et strict quand ils doivent être identiques. Les étiquettes aspf= et adkim= règlent ce comportement séparément pour SPF et DKIM. En pratique, DKIM aligné est la condition la plus robuste, car SPF casse lors des transferts.

L'enregistrement DNS#

La politique se publie dans un TXT sous le label _dmarc du domaine :

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; pct=100"

Étiquettes principales :

• p= : politique demandée pour le domaine, none (observer), quarantine (classer en indésirable) ou reject (refuser) ;
• sp= : politique pour les sous-domaines, par défaut identique à p= ;
• rua= : adresse de réception des rapports agrégés, envoyés en XML par les routeurs, en général une fois par jour ;
• ruf= : adresse pour les rapports d'échec détaillés, que peu de routeurs envoient encore ;
• pct= : pourcentage de messages auxquels appliquer la politique, utile pour une montée progressive ;
• fo= : conditions de génération des rapports d'échec (0, 1, d, s).

Si l'adresse rua est sur un autre domaine que celui qui publie la politique, le domaine destinataire doit publier un enregistrement d'autorisation example.com._report._dmarc.destinataire.tld contenant v=DMARC1, faute de quoi les routeurs n'envoient pas les rapports.

Les routeurs cherchent d'abord _dmarc.<domaine du From> ; s'il n'existe pas, ils remontent au domaine organisationnel. DMARCbis remplace la liste des suffixes publics par un parcours de l'arbre DNS (tree walk) et introduit l'étiquette np= pour les sous-domaines inexistants.

Déployer DMARC#

1. S'assurer que SPF et DKIM sont en place et, surtout, alignés pour chaque flux légitime : serveurs internes, prestataires marketing, outils transactionnels, applications tierces envoyant au nom du domaine.
2. Publier p=none avec une adresse rua. Aucun effet sur la livraison, mais les rapports commencent à arriver.
3. Analyser les rapports agrégés pendant plusieurs semaines : identifier chaque source, corriger les alignements manquants, faire signer en DKIM les prestataires avec d= sur votre domaine. La page lire un rapport détaille cette étape.
4. Passer à p=quarantine, éventuellement avec pct= croissant, puis à p=reject quand plus aucune source légitime n'échoue.
5. Traiter les sous-domaines explicitement avec sp=, et publier des politiques dédiées sur ceux qui ont un usage distinct (voir sous-domaines et wildcard).
6. Continuer à lire les rapports : l'apparition d'une nouvelle source en échec signale soit un nouveau prestataire mal configuré, soit une usurpation.

Exigences des routeurs depuis 2024#

En février 2024, Google et Yahoo ont appliqué des exigences communes aux expéditeurs, renforcées pour ceux qui envoient plus de 5 000 messages par jour vers leurs boîtes : SPF et DKIM en place, enregistrement DMARC publié (au minimum p=none), alignement du domaine From: avec SPF ou DKIM, enregistrement PTR valide, désabonnement en un clic conforme à la RFC 8058 pour les messages marketing, et taux de plainte maintenu sous 0,3 %. Microsoft a annoncé en 2025 des règles comparables pour les boîtes grand public Outlook. Ces règles sont imposées par les routeurs, pas par un standard : elles conditionnent la livraison vers leurs boîtes et sont devenues de fait le socle minimal pour tout domaine qui envoie du courrier.

Erreurs fréquentes#

• Rester en p=none indéfiniment : les rapports sont utiles mais le domaine n'est pas protégé, et p=none ne suffit pas pour BIMI.
• Passer à reject sans avoir lu les rapports : les flux légitimes non alignés (prestataire de support, outil de facturation, applications internes) sont rejetés.
• Oublier sp= sur un domaine dont les sous-domaines sont utilisés par des tiers.
• rua vers une boîte jamais lue ou vers un domaine tiers sans enregistrement d'autorisation.
• Confondre pct=0 avec p=none : pct=0 applique la politique à aucun message mais reste considéré comme une politique « active » par certains contrôles, dont BIMI.
• Compter sur SPF seul : les transferts, listes de diffusion et redirections cassent SPF ; sans DKIM aligné, ces messages échouent.
• Plusieurs enregistrements _dmarc : le résultat est indéfini et la plupart des routeurs ignorent la politique.

Ce que SenderRadar en montre#

SenderRadar présente la politique DMARC publiée pour le domaine, la politique effective pour les sous-domaines, les modes d'alignement, les destinations de rapports et leur autorisation éventuelle, ainsi que les incohérences entre cette politique et l'état de SPF et DKIM. SenderRadar s'appuie sur sa propre base d'analyse pour situer le niveau de politique du domaine par rapport aux domaines comparables.

Références#

• RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Groupe de travail DMARC de l'IETF (DMARCbis)
• RFC 8058 – One-Click List Unsubscribe
• dmarc.org