C'est quoi DMARC ? Alignement, politiques et les RFC 2026

C'est quoi DMARC ? C'est un enregistrement DNS qui indique aux serveurs de réception de mail ce qu'il faut faire quand un message prétend venir de votre domaine mais échoue l'authentification, et où envoyer les rapports à ce sujet. DMARC n'authentifie rien par lui-même. Il vérifie que SPF ou DKIM a réussi ET que le domaine validé correspond au domaine visible dans l'en-tête From.

Cette correspondance s'appelle l'alignement, et c'est là que la plupart des équipes se plantent. Un message peut passer SPF, passer DKIM, et échouer DMARC.

DMARC est une couche de politique au-dessus de SPF et DKIM

SPF énumère les adresses IP autorisées à envoyer pour un domaine. DKIM signe le message pour que le destinataire vérifie qu'il n'a pas été altéré et que le domaine signataire l'a autorisé. Aucun des deux ne regarde l'adresse From visible par l'utilisateur.

DMARC comble cette lacune. Il pose une seule question : le domaine en en-tête From visible s'aligne-t-il avec le domaine passé par SPF ou DKIM ? Si oui, le message passe. Si non, le destinataire applique votre politique.

L'enregistrement se place sur _dmarc.votredomaine.com en tant qu'enregistrement TXT. Un enregistrement minimal et valide ressemble à ceci :

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rapports@example.com"

Trois tags font le vrai travail. p est la politique, rua est l'adresse pour les rapports cumulatifs, et adkim / aspf définissent le niveau de strictesse de l'alignement. Tout le reste est optionnel.

L'alignement, c'est là que les bonnes mises en place échouent

SPF authentifie le domaine d'enveloppe, le domaine Return-Path. DKIM authentifie le domaine dans le tag d= de la signature. DMARC a besoin qu'au moins l'un des deux correspond au domaine From : soit exactement (strict), soit au niveau du domaine organisationnel (relaxed, le défaut).

Voici l'échec qu'on observe le plus souvent dans les traces. Une équipe envoie par un tiers, le tiers signe avec son propre domaine (d=provider-mail.net) et utilise son propre domaine de retour. SPF passe, DKIM passe, et DMARC échoue parce qu'aucun des deux domaines ne correspond à example.com.

La solution est un domaine d'envoi custom : une clé DKIM publiée sous votre domaine, et idéalement un return-path custom sur un sous-domaine. Tous les fournisseurs sérieux le supportent. Peu l'activent par défaut.

Les trois politiques : none, quarantine, reject

Le tag p a trois valeurs, et ce ne sont pas des échelons qu'on monte sur calendrier.

• p=none : le destinataire livre normalement et vous envoie des rapports. À utiliser les 2-4 premières semaines, pendant que vous inventoriez les expéditeurs.

• p=quarantine : le destinataire route les échecs vers le spam ou la corbeille. À utiliser une fois que les rapports montrent tous les sources légitimes alignées.

• p=reject : le destinataire refuse les échecs au stade SMTP. À utiliser une fois que quarantine a tourné propre pendant un cycle d'envoi complet.

p=none est de la surveillance, pas de la protection. Un domaine en none depuis deux ans a une case cochée et aucune défense contre l'usurpation. Échappez à la tentation de le laisser là parce que rien n'a cassé.

p=reject est la destination de tout domaine qui envoie uniquement du mail que vous contrôlez. Les domaines avec beaucoup de trafic de listes de diffusion ou de redirecteurs legacy ont besoin de plus d'attention, parce que les redirections cassent souvent SPF et peuvent casser DKIM si l'intermédiaire édite le corps du message.

Pourquoi les règles de Gmail et Yahoo ont rendu cela urgent

Depuis février 2024, les directives d'expéditeur de Google exigent que quiconque envoie plus de 5 000 messages par jour aux comptes Gmail publie un enregistrement DMARC, avec SPF et DKIM en place. La politique peut être none. Google demande aussi aux expéditeurs en masse de garder le taux de spam signalé par l'utilisateur dans Postmaster Tools en dessous de 0,30 %, et recommande de rester sous 0,10 %.

Yahoo Sender Hub énonce la même exigence fondamentale : un enregistrement DMARC valide d'au moins p=none, avec le domaine From aligné au domaine SPF ou DKIM. L'alignement relaxed est acceptable.

Notez ce qui est et n'est pas dans ces règles. L'exigence est un enregistrement publié et un alignement passant, pas de l'application. C'est un plancher. Ce n'est pas une ligne d'arrivée.

Les rapports cumulatifs sont le produit, la politique est l'interrupteur

L'adresse rua reçoit des rapports XML quotidiens de chaque destinataire qui honore DMARC. Chaque rapport énumère les adresses IP sources, les compteurs de messages, les résultats SPF et DKIM, et si l'alignement tenait. C'est ainsi que vous trouvez l'expéditeur oublié : l'ancienne export CRM, l'outil de facturation qu'un contractant a câblé en 2022, le formulaire marketing sur un sous-domaine que personne ne possède.

Le XML brut est illisible à volume. Routez rua vers une boîte aux lettres qu'un parseur peut ingérer, ou vers un service de rapportage DMARC hébergé, et regardez les données groupées par source. Ce que vous voulez voir est chaque source légitime montrant 100 % alignée, et tout le reste clairement inconnu.

Un déploiement pratique suit cet ordre :

1. Publiez p=none avec une adresse rua.

2. Collectez deux à quatre semaines de rapports. Construisez l'inventaire des expéditeurs.

3. Corrigez chaque source non alignée légitime avec un domaine DKIM custom ou un return-path custom.

4. Passez à p=quarantine. Surveillez les tickets d'assistance concernant les messages manquants.

5. Passez à p=reject quand quarantine n'affiche aucun échec légitime.

Livrez chaque étape séparément. Changer la politique et ajouter un nouveau fournisseur d'envoi la même semaine rend tout régression impossible à attribuer.

DMARCbis change les tags, pas votre enregistrement

En 2026, l'IETF a publié RFC 9989, RFC 9990, et RFC 9991, qui obsolescent RFC 7489. RFC 9989 est la spec DMARC centrale. Le rapportage d'agrégation et le rapportage d'échec sont passés dans leurs propres documents.

Les changements pratiques pour un propriétaire d'enregistrement sont mineurs :

• pct, rf, et ri sont supprimés.

• t (mode test) remplace pct comme interrupteur tout ou rien : t=y rapporte sans appliquer.

• np définit une politique pour les sous-domaines inexistants, ce qui bloque l'usurpation d'adresses comme abc123.example.com.

• psd marque les domaines de suffixe public, et une marche en arbre DNS remplace l'ancienne recherche de liste de suffixes publics.

Les enregistrements v=DMARC1 existants restent valides. Rien ne casse si vous ne changez rien aujourd'hui. Le support des nouveaux tags par les fournisseurs se fera de manière inégale, donc un tag qui semble ne rien faire signifie généralement que le destinataire ne l'a pas encore implémenté.

Le tag np est celui qui vaut la peine d'être adopté tôt. Mettre np=reject pendant que p est toujours none ferme le chemin d'abus de faux sous-domaines sans engager le reste de votre mail à l'application.

Les sous-domaines, et pourquoi le défaut hérite

Un enregistrement DMARC sur le domaine organisationnel s'applique aussi aux sous-domaines, à moins que vous ne le remplaciez avec sp. Cet héritage est utile et aussi un piège.

Si le marketing envoie depuis news.example.com par un fournisseur séparé, il hérite de la politique parentale. Déplacez le parent à p=reject avant que ce fournisseur ait DKIM alignée et la newsletter se retrouve au sol. Publiez un enregistrement _dmarc.news.example.com séparé quand un sous-domaine a sa propre flotte d'expéditeurs et son propre rythme de déploiement.

Une architecture plus propre sépare les flux par sous-domaine dès le départ. Le mail transactionnel sur l'un, le mail de cycle de vie sur un autre, le mail humain sur la racine. Chacun reçoit ses propres clés DKIM, sa propre réputation, et son propre enregistrement DMARC.

Lisez l'en-tête Authentication-Results avant de deviner

Quand un message échoue, le serveur destinataire enregistre pourquoi. Dans Gmail, « Afficher l'original » expose l'en-tête Authentication-Results, et il vous dit plus qu'importe quel tableau de bord.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provider-mail.net;
  dkim=pass header.d=provider-mail.net;
  dmarc=fail (p=NONE) header.from=example.com

Lisez-le de gauche à droite. SPF a réussi pour bounce.provider-mail.net. DKIM a réussi pour provider-mail.net. DMARC a échoué parce que l'en-tête From dit example.com et aucun des deux domaines passants n'y correspond.

La note (p=NONE) affiche la politique que le destinataire a vue. À none, ce message a été livré quand même. À reject, il aurait rebondi avec une erreur 5.7.x, et l'expéditeur l'aurait sù d'un client.

Deux vérifications attrapent la plupart de ces cas. Confirmez que la valeur header.d dans le résultat DKIM est votre domaine. Puis confirmez que le domaine smtp.mailfrom est votre domaine ou un sous-domaine de celui-ci.

SPF a une limite de recherches que DMARC expose

SPF autorise dix recherches DNS par évaluation. Chaque include: pour un fournisseur en dépense quelques-unes, et les includes imbriquées en dépensent plus. Franchissez dix et SPF retourne une erreur permanente, qui compte comme un échec.

Les équipes avec cinq ou six outils d'envoi frappent cela sans le remarquer, parce que les échecs SPF étaient invisibles avant le rapportage DMARC. Une fois que les rapports rua arrivent, le motif est évident : une source échoue soudainement SPF partout sur tous les destinataires le jour où quelqu'un a ajouté un autre include:.

C'est une autre raison de compter sur l'alignement DKIM comme chemin primaire. DKIM survit à la plupart des redirections, n'a pas de budget de recherches, et est lié au message plutôt qu'à l'adresse IP de connexion. Gardez SPF valide, mais ne construisez pas votre passage DMARC sur lui seul.

Ce que DMARC ne fera pas

DMARC prévient l'usurpation de domaine exact. Il n'arrête pas les domaines similaires (examp1e.com), il ne juge pas le contenu, et il n'arrange pas une mauvaise réputation d'expéditeur. Un domaine parfaitement aligné qui envoie à des listes achetées atterrit toujours dans le spam.

Il ne remplace pas non plus la surveillance. L'alignement peut se casser en silence : une modification DNS supprime un sélecteur DKIM, un fournisseur réitère les clés, un nouvel outil commence à envoyer sans votre connaissance. Les rapports c'est comment vous le découvrez avant que vos utilisateurs le fassent.

Traitez l'enregistrement DMARC comme n'importe quelle autre pièce de config de production. Il appartient au contrôle de version, les changements passent par la revue, et la boîte aux lettres rua a besoin d'un propriétaire.

Avant de publier l'enregistrement

Passez par ceci une fois. Ça prend moins d'une heure pour un seul domaine.

• Énumérez chaque système qui envoie du mail en tant que votre domaine : produit, facturation, support, CRM, marketing, invitations de calendrier.

• Confirmez que chacun signe DKIM avec votre domaine, pas celui du fournisseur.

• Définissez un return-path custom où le fournisseur le permet.

• Choisissez une destination rua que quelqu'un lira.

• Commencez par p=none, et mettez la date à laquelle vous prévoyez de le revoir sur le calendrier.

• Vérifiez le taux de spam dans Google Postmaster Tools chaque semaine pendant le déploiement.

Par où continuer

Si vous n'avez jamais regardé vos rapports, publiez p=none avec une adresse rua aujourd'hui et lisez ce qui arrive dans deux semaines. Le premier rapport nomme presque toujours au moins un expéditeur que personne ne se souvenait. L'étape concrète suivante est de décider lequel de ceux-ci vous gardez.