DMARC est un enregistrement TXT publié sur _dmarc.<your domain>. Il indique aux serveurs de réception que faire des e-mails qui utilisent votre domaine dans l’en-tête From mais échouent à la fois à SPF et à DKIM alignés, et où envoyer les rapports. p=none demande seulement des rapports, p=quarantine demande aux serveurs de réception de traiter les e-mails en échec comme suspects, et p=reject leur demande de les refuser.

Gmail, Yahoo et Microsoft acceptent p=none de la part des expéditeurs en masse : beaucoup de domaines publient donc cette politique et s’arrêtent là, avec des rapports sur les usurpateurs mais sans les bloquer. L’analyse de 73,3 millions de domaines par Red Sift, citée en avril 2026, montre que 14,9 % avaient une politique DMARC, quelle qu’elle soit, et que 2,5 % appliquaient p=reject. EasyDMARC, un autre éditeur de solutions DMARC, indiquait en 2025 que 62,7 % des entreprises du Fortune 500 dotées de DMARC utilisaient p=reject, contre 15,2 % des entreprises de l’Inc. 5000.

Voici un plan de 30 jours pour atteindre p=reject, enregistrement par enregistrement, pour un domaine qui envoie depuis une messagerie professionnelle, un ou deux ESP, un outil de support et un outil de facturation. Trente jours conviennent à un sous-domaine d’envoi. Un domaine que vos équipes utilisent pour leurs e-mails du quotidien demande plus de temps.

À retenir

• Publiez v=DMARC1; p=none; rua=mailto:... le jour 1. Sans rua, les serveurs de réception ne doivent pas envoyer de rapports agrégés.
• Chaque expéditeur légitime doit réussir SPF ou DKIM avec un alignement sur votre domaine From. Pour la plupart des outils, cela veut dire signer en DKIM avec votre domaine.
• Ne dépassez pas 10 termes SPF générant une requête DNS, include imbriqués compris, sinon tous vos e-mails obtiennent permerror.
• Passez à p=quarantine le jour 15 et à p=reject le jour 22, à chaque fois après une semaine de rapports sans anomalie. Pour un domaine que vos équipes utilisent au quotidien, la RFC 9989 demande un mois pour chacune des deux premières étapes.
• La RFC 9989 (mai 2026) classe pct comme historique. Oubliez la montée progressive pct=10, pct=50.
• BIMI exige p=quarantine ou p=reject sur le domaine organisationnel, pas de sp=none, un logo SVG Tiny PS et, pour Gmail, un VMC ou un CMC.

Ce qui a changé dans DMARC en 2026

En mai 2026, l’IETF a remplacé la RFC 7489, un document informatif (Informational) de 2015, par DMARCbis : la RFC 9989, une proposition de norme (Proposed Standard) qui rend aussi obsolète la RFC 9091, complétée par la RFC 9990 pour les rapports agrégés. Trois changements comptent ici :

• pct devient historique. L’annexe A.6 indique qu’il « n’était généralement pas appliqué avec précision, sauf si la valeur indiquée était 0 ou 100 ».
• t=y remplace pct=0. Les serveurs de réception appliquent le niveau inférieur à votre politique : p=reject; t=y équivaut donc à quarantine. C’est un indicateur de test.
• np fait son apparition. Il couvre les sous-domaines qui n’existent pas dans le DNS, et les anciens serveurs de réception doivent l’ignorer.

Pour trouver le domaine organisationnel, un parcours de l’arborescence DNS (DNS tree walk) remplace par ailleurs la liste des suffixes publics (Public Suffix List).

Les trois enregistrements dont dépend DMARC

DMARC réussit quand SPF ou DKIM réussit et que le domaine validé est aligné sur le domaine From. Une seule réussite alignée suffit.

SPF et la limite de 10 requêtes DNS

SPF autorise des serveurs pour le domaine d’enveloppe (MAIL FROM ou Return-Path), la seule identité que DMARC prend en compte pour SPF, à l’exclusion de HELO. La RFC 7208, section 4.6.4 plafonne à 10 les termes générant une requête DNS : include, a, mx, ptr, exists et redirect, comptés à travers chaque include imbriqué. ip4, ip6 et all ne comptent pas. Au-delà, le résultat est permerror. La même section autorise aussi au maximum deux « void lookups » (requêtes sans résultat), le plus souvent un include qui vise un nom d’hôte qui n’existe plus.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

Cet enregistrement consomme déjà 4 requêtes avant même de compter ce que chaque éditeur imbrique : résolvez donc chaque include avec dig +short TXT <name>, en descendant toute la chaîne. Pour ne pas dépasser 10, supprimez les outils abandonnés ou donnez à chaque ESP son propre sous-domaine de Return-Path, comme bounce.example.com, qui dispose de son propre budget de 10. Le guide de configuration SPF de Microsoft recommande de terminer par -all sur les domaines qui utilisent aussi DKIM et DMARC.

Par défaut, beaucoup d’ESP utilisent leur propre domaine de Return-Path, qui n’est pas aligné sur le vôtre. Configurez un Return-Path personnalisé ou appuyez-vous sur DKIM.

DKIM : clés de 2048 bits, sélecteurs et rotation

DKIM signe chaque message avec un domaine d= et un sélecteur s= ; le serveur de réception récupère la clé sur <selector>._domainkey.<d domain>. Un outil qui signe avec d=vendor-mail.example réussit DKIM mais échoue à DMARC.

Selon la RFC 8301, les signataires doivent utiliser des clés RSA d’au moins 1024 bits et devraient utiliser 2048 bits. Les consignes de Google pour les expéditeurs disent la même chose pour les envois vers des comptes Gmail personnels. Une clé de 2048 bits dépasse la limite de 255 caractères d’une chaîne TXT : elle est donc saisie sous forme de plusieurs chaînes entre guillemets dans un seul enregistrement, un découpage que la plupart des hébergeurs DNS font pour vous.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Donnez à chaque système d’envoi son propre sélecteur et ne réutilisez jamais un nom. Une date, comme s202610, garde l’historique lisible. Les bonnes pratiques de rotation des clés du M3AAWG recommandent une rotation au moins tous les six mois :

1. Publiez le nouveau sélecteur et laissez-le se propager.
2. Basculez la signature sur la nouvelle clé.
3. Laissez l’ancienne clé publique dans le DNS pendant 7 à 30 jours, pour que les e-mails en transit puissent être vérifiés.
4. Révoquez l’ancien sélecteur en publiant un p= vide. Ne le supprimez pas.

Alignement : souple ou strict

La RFC 9989 définit deux modes :

La RFC 9989 note que « presque tous les propriétaires de domaines ont jugé l’alignement souple suffisant ». N’indiquez ni aspf ni adkim. L’alignement SPF strict est incompatible avec le Return-Path habituel sur un sous-domaine.

Le plan sur 30 jours

L’enregistrement de chaque étape. Ne passez à la suivante qu’après une semaine de rapports sans anomalie.

Si la deuxième semaine révèle une source que personne ne peut corriger, restez en p=none. Rejeter vos propres factures est pire qu’appliquer la politique en retard.

Jours 1 à 7 : publier p=none avec les rapports

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

Les rapports sont des fichiers XML compressés en gzip, envoyés au moins une fois par jour par chaque serveur de réception : faites donc pointer rua vers un service de traitement des rapports, pas vers une personne. Si l’adresse appartient à un autre domaine organisationnel, la RFC 9990 demande aux serveurs de réception de l’ignorer, sauf si example.com._report._dmarc.<report domain> l’autorise. Les services de traitement publient cet enregistrement ; pour vos propres domaines, ajoutez-le vous-même.

Publiez un seul et unique enregistrement DMARC. Si des assistants de configuration laissent deux enregistrements v=DMARC1 sur _dmarc.example.com, les serveurs de réception les ignorent tous les deux.

Laissez ruf de côté. La RFC 9989 note que les serveurs de réception soucieux de la confidentialité expurgent fortement les rapports d’échec, voire ne les envoient pas, et la FAQ de l’annonce de Microsoft consacrée aux expéditeurs à fort volume précise que Microsoft envoie les rapports rua et ne prévoit pas d’envoyer de rapports ruf.

Comment lire un rapport agrégé

La RFC 9990 décrit des rapports XML « quotidiens (ou plus fréquents) », un par domaine de politique. Voici un enregistrement, adapté de son exemple :

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Dans policy_evaluated, dkim et spf sont des résultats d’alignement, et disposition indique ce que le serveur de réception a fait. auth_results contient les résultats bruts et leurs domaines. Ici, les deux réussissent pour vendor.example, et les deux échouent donc à l’alignement : c’est le signe d’un éditeur qui envoie sous votre nom sans signer avec votre domaine. Activez son DKIM personnalisé ou son authentification de domaine.

Jours 1 à 7 : identifier les expéditeurs inconnus

Regroupez par source_ip, envelope_from et par couple domain + selector DKIM, triez par count, puis classez les résultats :

Pour identifier une IP, lancez dig -x 192.0.2.123 +short et regardez le sélecteur, qui porte souvent le nom de l’éditeur. Demandez ensuite à la finance, au support et aux ventes ce qui envoie des e-mails au nom de l’entreprise : facturation, outil de support, invitations d’agenda, scanners de bureau.

Les e-mails transférés et ceux des listes de diffusion échoueront d’une manière que vous ne pouvez pas corriger, et la FAQ de Google pour les expéditeurs n’exige pas d’alignement pour eux : ne les attendez donc pas pour avancer.

Jours 8 à 14 : corriger chaque source légitime

Partez du count le plus élevé et descendez :

1. Messagerie professionnelle (Google Workspace, Microsoft 365). Activez DKIM dans la console d’administration, en 2048 bits si c’est proposé, et vérifiez que l’include du fournisseur figure dans SPF.
2. ESP et outils marketing. Configurez l’authentification de domaine pour qu’ils signent avec votre d=, ainsi qu’un Return-Path personnalisé si c’est proposé.
3. Support, facturation, CRM. Même chose que pour les ESP. Si l’un d’eux ne peut pas signer avec votre domaine, utilisez un sous-domaine pour lequel il peut signer, ou son propre domaine.
4. Outils abandonnés. Supprimez leurs include et leurs sélecteurs.

Recomptez ensuite les requêtes DNS de SPF.

Jour 15 : p=quarantine

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

En pratique, la quarantaine se traduit le plus souvent par un classement en spam. Surveillez les sources légitimes dont la disposition est quarantine. Pour un essai à blanc, p=quarantine; t=y demande aux serveurs de réception conformes à la RFC 9989 d’appliquer none, mais la RFC n’a que quelques mois et tous les serveurs de réception ne respectent pas encore t.

Jour 22 : p=reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

Les serveurs de réception qui respectent p=reject refusent les e-mails en échec pendant la session SMTP, mais la RFC 9989 leur demande de les mettre en quarantaine quand la politique est leur seul élément pour trancher : une partie atterrit donc en spam.

La même RFC précise qu’un domaine en p=reject « ne doit pas (MUST NOT) s’appuyer uniquement sur SPF » et doit signer avec DKIM, car le transfert casse SPF mais pas DKIM. Vérifiez d’abord le DKIM aligné sur chaque source.

Gardez rua pour toujours. Le nouvel outil adopté le trimestre prochain apparaîtra dans vos rapports avant de remonter dans la file de votre support.

Quand allonger le plan

Selon la section 7.4 de la RFC 9989, les domaines dont les utilisateurs envoient des messages à des listes de diffusion « ne devraient pas (SHOULD NOT) » publier p=reject, et ceux qui le font devraient d’abord passer « au moins un mois » en p=none et « une période tout aussi longue » en p=quarantine. C’est le cas de la plupart des domaines racines d’entreprise : accordez-y donc un mois à chacune des deux premières étapes. Un sous-domaine utilisé uniquement par votre ESP ne génère aucun trafic de liste de diffusion et peut garder le rythme de 30 jours.

Politique des sous-domaines : sp= et np=

p couvre le domaine et ses sous-domaines. sp remplace p pour les sous-domaines existants, et np pour les sous-domaines inexistants. Un sous-domaine qui a son propre enregistrement utilise celui-ci, et la RFC 9989 y ignore sp.

Un sous-domaine d’envoi dédié comme mail.example.com, utilisé par un seul ESP avec SPF et DKIM vérifiés, peut publier p=reject dès le premier jour. p=none; sp=reject sur le domaine racine protège les sous-domaines pendant que vous terminez le domaine principal, mais bloque BIMI.

Les domaines parkés devraient publier v=spf1 -all, selon le guide SPF de Microsoft, ainsi que v=DMARC1; p=reject; sur _dmarc.

Jour 30 et au-delà : BIMI

BIMI affiche votre logo à côté des e-mails authentifiés dans les boîtes de réception compatibles :

Le draft BIMI en est à sa révision 14 (mai 2026). C’est toujours un Internet-Draft rédigé sur la base de la RFC 7489, d’où la présence de pct. N’indiquez pas pct et ne définissez pas t=y.

La règle du domaine organisationnel piège les expéditeurs qui envoient depuis un sous-domaine : avec mail.example.com en p=reject et example.com en p=none, les serveurs de réception ne doivent pas afficher le logo. Le domaine racine doit donc lui aussi aller au bout du plan.

Les recommandations SVG du BIMI Group préconisent un logo carré, centré, sur un fond uni, de moins de 32 Ko. Google a ajouté la prise en charge des CMC en septembre 2024. L’enregistrement, selon le guide de mise en œuvre du BIMI Group :

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

L’enregistrement d’une marque prend des mois : si vous visez un VMC, lancez les démarches dès maintenant.

Ce qu’exigent Gmail, Yahoo et Microsoft

Aucun des trois n’exige une politique appliquée : seulement un enregistrement DMARC et l’alignement.

Sources : les consignes de Google pour les expéditeurs et leur FAQ, les bonnes pratiques de Yahoo pour les expéditeurs, ainsi que l’annonce d’avril 2025 et la page d’assistance sur l’erreur 5.7.515 de Microsoft. Microsoft a commencé à appliquer ces règles le 5 mai 2025, après une mise à jour du 29 avril qui a remplacé le classement en courrier indésirable par le rejet.

La FAQ de Google indique que l’alignement à la fois de SPF et de DKIM « deviendra à terme une exigence pour les expéditeurs » : alignez donc les deux dès la deuxième semaine. Pour les taux de désabonnement et de spam, consultez ce qui s’applique toujours quand un agent envoie vos e-mails et notre guide de la délivrabilité.

DMARC sur un domaine d’envoi Brew

La configuration de domaine de Brew demande :

• DKIM : un enregistrement TXT sur un sélecteur ._domainkey de votre domaine d’envoi. Obligatoire.
• SPF : un enregistrement MX et un enregistrement TXT sur send.<your sending domain>, le Return-Path de Brew. Obligatoire.
• DMARC : un enregistrement TXT sur _dmarc.<your sending domain>. Facultatif, mais recommandé.
• Un CNAME pour le suivi des clics, uniquement avec un sous-domaine de suivi personnalisé.

Le domaine peut envoyer dès que SPF et DKIM sont vérifiés, et Brew propose une valeur DMARC adaptée :

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Un sous-domaine dédié reçoit p=reject, car rien n’envoie depuis ce sous-domaine avant la vérification du SPF et du DKIM de Brew. Un domaine racine reçoit p=none, car vos autres outils envoient probablement aussi en son nom : suivez donc le plan ci-dessus. L’alignement reste souple, car le Return-Path send.<domain> n’est aligné qu’en mode souple.

Brew lit l’enregistrement _dmarc.<sending domain> en vigueur à l’ajout du domaine, à sa vérification et à chaque nouvelle vérification. La page Domaines affiche le résultat, tout comme get_domain_health via MCP et GET /v1/domains/{domainId}/health :

• dmarc_missing : un avertissement, avec l’enregistrement exact à ajouter.
• dmarc_invalid : deux enregistrements DMARC sur ce nom, une version ou une politique incorrecte, ou des balises en double. Le message indique l’enregistrement à supprimer.
• Vérifié : dès qu’un seul et unique enregistrement valide est trouvé.

La configuration DNS automatique n’écrit l’enregistrement DMARC que s’il n’en existe aucun : elle ne crée donc jamais de doublon. La vérification porte sur le domaine d’envoi, pas sur son domaine parent : donnez donc à chaque sous-domaine d’envoi son propre enregistrement, y compris à celui des e-mails transactionnels si vous séparez les deux comme le conseille la documentation. C’est dans votre outil de traitement rua que vous lisez les rapports et décidez quand passer à reject.

Questions fréquentes

Combien de temps rester en p=none avant de passer à quarantine ?

Jusqu’à ce qu’une semaine complète de rapports montre que chaque source légitime réussit SPF ou DKIM aligné, ce qui prend en général une à deux semaines pour un sous-domaine d’envoi. Pour un domaine que vos équipes utilisent au quotidien, la RFC 9989 demande au moins un mois. Deux ans en p=none sans que personne lise les rapports ne valent rien.

La balise DMARC pct est-elle obsolète ?

Oui. La RFC 9989 classe pct comme « historique » et remplace ses seules valeurs fiables par t : t=y se comporte comme pct=0, et t=n comme pct=100. Les anciens serveurs de réception peuvent encore lire pct, mais n’ont jamais appliqué les valeurs intermédiaires de façon cohérente : avancez donc par étapes entières.

p=reject va-t-il bloquer mes e-mails transférés ?

Un simple transfert casse généralement SPF, mais pas DKIM : le DKIM aligné réussit donc toujours. Les listes de diffusion qui modifient l’objet ou le pied de page cassent DKIM, et certaines réécrivent l’en-tête From pour compenser. Un DKIM aligné partout reste votre meilleure protection.

Gmail et Yahoo exigent-ils p=reject ?

Non. Tous deux exigent des expéditeurs en masse qu’ils publient DMARC, et acceptent p=none, tout comme Microsoft au-delà de 5 000 messages par jour vers Outlook.com. Une politique appliquée bloque l’usurpation et elle est indispensable pour BIMI, mais aucun des trois ne l’exige.

Faut-il un VMC pour BIMI ?

Pour Gmail, il vous faut un VMC, qui exige une marque déposée et affiche une coche, ou un CMC, qui affiche le logo sans coche. Selon le BIMI Group, quelques fournisseurs, dont Yahoo et Fastmail, affichent aussi des logos auto-déclarés, sans certificat.