DMARCbis : le guide complet pour comprendre et migrer vers le nouveau standard DMARC

⚡TL;DR

• DMARCbis remplace DMARC (RFC 7489) et devient un Proposed Standard IETF. Les trois documents sont en file d'attente du RFC Editor, publication attendue courant 2026.
• Le DNS Tree Walk remplace la Public Suffix List : la découverte du domaine organisationnel se fait par requêtes DNS successives (max 8), sans dépendance à une liste externe.
• Trois tags ajoutés : psd (marqueur Public Suffix Domain), np (politique pour sous-domaines inexistants), t (mode testing binaire).
• Trois tags supprimés : pct (remplacé par t), ri et rf (déplacés vers les documents de reporting).
• Vos enregistrements DMARC actuels restent valides (v=DMARC1). La migration consiste à retirer les tags obsolètes et à adopter les nouveaux progressivement.

DMARC protège les domaines contre l'usurpation d'identité email depuis 2015. Mais la RFC 7489 souffrait de faiblesses structurelles : dépendance à une liste externe (la Public Suffix List), un tag pct mal compris et mal implémenté, aucun mécanisme pour les sous-domaines inexistants.

DMARCbis corrige ces problèmes. Ce n'est pas une simple mise à jour : c'est une réécriture qui élève DMARC au rang de Proposed Standard IETF, le premier statut normatif du protocole. Les trois documents (base, rapports agrégés, rapports d'échec) sont en file d'attente du RFC Editor depuis fin 2025. La publication est imminente.

Ce guide s'adresse aux administrateurs systèmes, responsables email et ingénieurs sécurité qui doivent comprendre les changements et préparer la migration. Vous y trouverez le fonctionnement détaillé du DNS Tree Walk, un comparatif complet des tags, un plan de migration et les implications pour la conformité (PCI DSS 4.0, Google, Yahoo, Microsoft).

Un glossaire en fin d'article définit les termes techniques : PSL, PSD, PSO, Tree Walk, Organizational Domain, Author Domain.

Qu'est-ce que DMARCbis ?

DMARCbis est le successeur de DMARC tel que défini par la RFC 7489. Le terme "bis" suit la convention IETF pour désigner la deuxième itération d'un protocole. Concrètement, DMARCbis regroupe trois documents normatifs :

• draft-ietf-dmarc-dmarcbis : le document de base (découverte de politique, alignement, tags)
• draft-ietf-dmarc-aggregate-reporting : les rapports agrégés XML
• draft-ietf-dmarc-failure-reporting : les rapports d'échec (message par message)

Pourquoi cette refonte ?

La RFC 7489, publiée en 2015, portait le statut "Informational". Cela signifie que DMARC n'était pas un standard Internet au sens strict. DMARCbis corrige cette anomalie en devenant un Proposed Standard, ce qui lui confère un poids normatif dans l'écosystème IETF.

Les motivations techniques sont précises :

1. La Public Suffix List est fragile. Maintenue manuellement par Mozilla, non standardisée, mise à jour hors bande. Un registre oublié ou un nouveau TLD non listé provoque des faux négatifs.
2. Le tag pct était inutile. En pratique, seules les valeurs 0 et 100 étaient utilisées. Les implémentations variaient entre récepteurs, rendant le comportement imprévisible.
3. Les sous-domaines inexistants n'étaient pas protégés. Un attaquant pouvait envoyer depuis faux.sous-domaine.captaindns.com sans que DMARC ne s'applique.
4. PSD DMARC (RFC 9091) restait expérimental. DMARCbis intègre et remplace cette extension en unifiant le modèle via le tag psd et le Tree Walk.

Chronologie IETF

Date	Événement
2015	RFC 7489 publiée (Informational)
2021	RFC 9091 PSD DMARC (Experimental)
2024-2025	Drafts DMARCbis itératifs au sein du WG DMARC
Q4 2025	Les trois drafts entrent en file du RFC Editor (état EDIT)
Q1/Q2 2026	Publication attendue comme Proposed Standard

Point essentiel : la version de l'enregistrement DNS reste v=DMARC1. Il n'y a pas de v=DMARC2. Les enregistrements existants continuent de fonctionner.

Le tree walk DNS : la fin du PSL

Le changement le plus structurant de DMARCbis est le remplacement de la Public Suffix List par un algorithme de découverte purement DNS : le Tree Walk.

Le problème du PSL

Avec DMARC v1, pour déterminer le domaine organisationnel (Organizational Domain), le récepteur consultait la Public Suffix List. Cette liste, maintenue par Mozilla, recense les suffixes publics (co.uk, com.au, gouv.fr). Le récepteur soustrayait le suffixe public du domaine pour identifier l'organisation.

Les limites étaient connues :

• La liste doit être téléchargée et mise à jour régulièrement (décalage possible)
• Les nouveaux TLD ou suffixes non listés provoquent des erreurs
• Le mécanisme n'est pas standardisé : chaque implémentation gère la liste différemment
• Aucune autorité DNS ne valide l'exactitude de la liste

Comment fonctionne le tree walk ?

Le Tree Walk interroge directement le DNS pour découvrir la politique DMARC applicable. L'algorithme est le suivant :

Entrée : le domaine de l'en-tête From: (Author Domain)

Étapes :

1. Interroger _dmarc.<AuthorDomain>. Si un enregistrement DMARC est trouvé avec psd=n (ou sans tag psd), ce domaine est le domaine organisationnel. Fin.
2. Si aucun enregistrement n'est trouvé, retirer le label le plus à gauche et recommencer.
3. Si un enregistrement est trouvé avec psd=y, le domaine organisationnel est un label en dessous du domaine courant.
4. Si un enregistrement est trouvé avec psd=u, continuer la remontée.
5. Répéter jusqu'à trouver un résultat ou atteindre la limite de 8 requêtes DNS.

Sortie : le domaine organisationnel et la politique applicable (ou "pas de DMARC" si rien n'est trouvé).

Exemples concrets

Cas 1 : domaine simple

Pour newsletter.captaindns.com :

Requête 1 : _dmarc.newsletter.captaindns.com → pas de record
Requête 2 : _dmarc.captaindns.com → "v=DMARC1; p=reject; psd=n"

Résultat : psd=n confirme que captaindns.com est le domaine organisationnel. 2 requêtes DNS.

Cas 2 : Public Suffix Domain

Pour contact.banque.co.uk :

Requête 1 : _dmarc.contact.banque.co.uk → pas de record
Requête 2 : _dmarc.banque.co.uk → pas de record
Requête 3 : _dmarc.co.uk → "v=DMARC1; p=reject; psd=y"

Résultat : psd=y signale que co.uk est un PSD. Le domaine organisationnel est banque.co.uk (un label sous le PSD). 3 requêtes DNS.

Cas 3 : domaine profond

Pour un domaine avec plus de 8 labels, l'algorithme saute directement à 7 labels après la première requête, puis remonte label par label. La limite de 8 requêtes garantit que le processus se termine.

Comparaison entre le PSL et le tree walk

Aspect	PSL (RFC 7489)	DNS Tree Walk (DMARCbis)
Source de vérité	Liste statique (Mozilla)	Le DNS lui-même
Mise à jour	Téléchargement périodique	Temps réel via les requêtes DNS
Couverture	Manuelle, potentiellement incomplète	Tout domaine publiant un record _dmarc
Détection PSD	Lookup dans la liste	Tag psd=y dans le record DNS
Standardisation	Projet communautaire, non normatif	Standards Track IETF

Performances du tree walk

Pour un domaine typique à 3 labels (comme newsletter.captaindns.com), le Tree Walk ajoute au maximum 1 requête DNS supplémentaire par rapport à DMARC v1. La limite de 8 requêtes garantit que les domaines profonds ne causent pas de surcharge.

Le cache DNS atténue l'impact en pratique. Les records _dmarc du domaine organisationnel sont mis en cache après la première requête. Les réponses NXDOMAIN sont aussi mises en cache selon le TTL du champ MINIMUM du SOA. Un domaine qui reçoit des milliers de messages par heure ne générera qu'une poignée de requêtes Tree Walk effectives.

En comparaison, l'approche PSL ne générait aucune requête DNS pour la découverte. Mais elle nécessitait le téléchargement périodique d'une liste d'environ 250 Ko et sa maintenance en mémoire.

Recommandation TTL : publiez vos records _dmarc avec un TTL d'au moins 3600 s. Un TTL de 86400 s réduit encore la charge DNS. C'est particulièrement utile pour les records avec psd=n ou psd=y, qui servent de points d'ancrage au Tree Walk.

Ce qui change dans les tags DMARC

DMARCbis ajoute trois tags, en supprime trois et modifie le comportement de deux existants. Le tag de version (v=DMARC1) et les tags fondamentaux (p, sp, adkim, aspf, fo) restent inchangés.

Tags ajoutés

Le tag psd : marqueur de suffixe public

Le tag psd indique si le domaine publiant l'enregistrement est un Public Suffix Domain.

Valeur	Signification
y	Ce domaine est un PSD (ex : co.uk, gouv.fr). Le domaine organisationnel se situe un label en dessous.
n	Ce domaine est un domaine organisationnel normal.
u	Non déterminé. Le Tree Walk continue la remontée.

Valeur par défaut : u (undetermined).

Qui doit l'utiliser ? Uniquement les opérateurs de suffixes publics (registres TLD, registres sectoriels). Pour un domaine standard, laissez psd absent ou indiquez psd=n.

Exemple pour un registre :

_dmarc.co.uk. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:dmarc-agg@registry.co.uk"

Le tag np : politique pour sous-domaines inexistants

Le tag np comble un angle mort de DMARC v1 : les sous-domaines qui n'existent pas dans le DNS. Un attaquant pouvait envoyer depuis faux.captaindns.com sans politique applicable si aucun record _dmarc n'existait à ce niveau.

Avec np, le domaine organisationnel peut déclarer une politique spécifique pour ces cas. Les valeurs sont identiques à p : none, quarantine, reject.

La chaîne de fallback est : np (si présent) puis sp (si présent) puis p.

Le récepteur vérifie l'existence du sous-domaine via DNS. Si le DNS retourne NXDOMAIN, la politique np s'applique.

Exemple :

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

Résultat : les sous-domaines existants héritent de p=quarantine. Les sous-domaines inexistants sont bloqués par np=reject.

Le tag t : mode testing

Le tag t remplace l'usage du pct=0 pour le mode test. La sémantique est binaire :

• t=y : la politique est rétrogradée d'un niveau (reject devient quarantine, quarantine devient none)
• t=n : la politique s'applique normalement (valeur par défaut)

Le mode testing n'affecte pas le reporting : les rapports agrégés sont envoyés normalement, ce qui permet de surveiller les résultats avant d'appliquer la politique stricte.

Point critique pour la transition : les récepteurs DMARC v1 ignorent les tags inconnus. Si vous publiez p=reject; t=y, un récepteur qui n'implémente pas encore DMARCbis appliquera reject sans tenir compte du t=y. Ce comportement est par conception : il garantit que la politique la plus stricte s'applique par défaut.

Tags supprimés

Tag	Raison de la suppression	Remplacement
pct	En pratique, seules les valeurs 0 et 100 étaient utilisées. Le comportement variait entre implémentations.	t=y pour le mode test, suppression pour le reste
ri	L'intervalle de reporting était standardisé de facto à 24 h. Les récepteurs ignoraient les autres valeurs.	Géré par le document Aggregate Reporting
rf	Un seul format existait (afrf). Aucune alternative n'a jamais été déployée.	Géré par le document Failure Reporting

Si vos enregistrements DMARC contiennent encore pct, ri ou rf, ils continueront de fonctionner (les récepteurs les ignoreront). Mais il est recommandé de les retirer pour éviter toute ambiguïté.

Tags modifiés

rua (rapports agrégés) : la syntaxe de limite de taille (!10m) est supprimée. La vérification de destination externe est renforcée : si le domaine de l'adresse rua diffère du domaine DMARC, un record d'autorisation _dmarc-report._report.<rua-domain> doit exister.

ruf (rapports d'échec) : défini dans un document RFC séparé (Failure Reporting). Même vérification de destination externe que rua.

Tableau récapitulatif v1 vs DMARCbis

Tag	DMARC v1	DMARCbis	Statut
v	DMARC1	DMARC1	Inchangé
p	none / quarantine / reject	Identique	Inchangé
sp	Politique sous-domaines	Identique	Inchangé
adkim	r / s	Identique	Inchangé
aspf	r / s	Identique	Inchangé
fo	0 / 1 / d / s	Identique	Inchangé
rua	URIs avec limite taille	URIs sans limite, vérification externe renforcée	Modifié
ruf	URIs	Défini dans RFC séparé	Modifié
pct	0-100	Supprimé	Supprimé
ri	Secondes	Supprimé	Supprimé
rf	afrf	Supprimé	Supprimé
np	N/A	none / quarantine / reject	Nouveau
psd	N/A	y / n / u	Nouveau
t	N/A	y / n	Nouveau

Le reporting se sépare en trois documents

DMARC v1 regroupait tout dans la RFC 7489 : politique, rapports agrégés et rapports d'échec. DMARCbis sépare ces responsabilités en trois documents normatifs distincts.

Les rapports agrégés

Les rapports agrégés restent au format XML, mais le schéma évolue. Les principaux changements :

• Nouveau namespace XML : urn:ietf:params:xml:ns:dmarc-2.0
• Nouveau champ <testing> : indique si le domaine était en mode test (t=y)
• Nouveau champ <np> : politique pour sous-domaines inexistants
• Nouveau champ <discovery_method> : comment la politique a été découverte (Tree Walk vs direct)
• Nouvelle disposition pass : ajoutée aux dispositions possibles
• Suppression de sampled_out : la raison d'override disparaît avec pct

Chaque URI listée dans rua reçoit son propre rapport. Ce n'est plus optionnel : les récepteurs DOIVENT envoyer un rapport distinct à chaque adresse.

Les rapports d'échec

Les rapports d'échec sont désormais couverts par un document séparé. Ce changement reflète la réalité : la plupart des grands fournisseurs n'envoyaient pas de rapports d'échec, pour des raisons de vie privée et de volume.

Le document clarifie les exigences de confidentialité et les cas où l'envoi est approprié.

Autres changements notables

• SPF restreint à MAIL FROM : DMARCbis élimine la vérification SPF basée sur HELO/EHLO. Seul le domaine MAIL FROM est évalué pour l'alignement.
• Guidance renforcée sur p=reject : les domaines avec p=reject doivent utiliser DKIM (pas seulement SPF). Les récepteurs ne doivent pas rejeter uniquement sur la base de p=reject sans évaluation DKIM/SPF. Les domaines dont les utilisateurs postent sur des listes de diffusion ne devraient pas publier p=reject.

DMARCbis et les listes de diffusion

Les listes de diffusion sont le cas d'usage le plus problématique pour DMARC depuis 2015. DMARCbis ne résout pas le problème, mais le documente formellement et renforce les recommandations.

Pourquoi les listes cassent l'alignement ?

Une liste de diffusion modifie le message en transit. L'enveloppe SMTP change (nouveau MAIL FROM), ce qui casse l'alignement SPF. Le contenu est souvent modifié (ajout d'un préfixe au sujet, footer de désabonnement), ce qui invalide la signature DKIM. Le résultat : un échec DMARC systématique pour les domaines en p=reject.

DMARCbis renforce formellement la recommandation : les domaines dont les utilisateurs participent à des listes de diffusion ne devraient pas publier p=reject. La politique p=quarantine est préférable dans ce cas.

ARC comme mécanisme de secours

ARC (Authenticated Received Chain, RFC 8617) permet aux intermédiaires de préserver une chaîne d'authentification. DMARCbis référence ARC comme mécanisme que les récepteurs PEUVENT utiliser pour récupérer les résultats d'authentification originaux. Mais DMARCbis ne rend pas ARC obligatoire. C'est une option, pas une garantie.

Les types d'override dans les rapports agrégés

DMARCbis reconnaît les types d'override suivants dans les rapports agrégés :

• forwarded : message redirigé par un tiers
• mailing_list : message issu d'une liste de diffusion
• trusted_forwarder : redirecteur de confiance identifié par le récepteur
• local_policy : politique locale du récepteur (whitelist, réputation)
• policy_test_mode : nouveau type, remplace sampled_out (supprimé avec pct)

Ces types permettent de comprendre pourquoi un récepteur a choisi de ne pas appliquer la politique publiée.

Conseil pratique

Les logiciels modernes de listes de diffusion (Mailman 3, Sympa) incluent des mitigations DMARC intégrées. La plus courante : la réécriture du From: pour utiliser l'adresse de la liste au lieu de l'adresse originale. Si votre domaine est utilisé par des listes, vérifiez que ces mitigations sont activées. Et préférez p=quarantine à p=reject.

DMARCbis et les fournisseurs d'envoi (ESP)

Aucun ESP majeur (SendGrid, Mailgun, Amazon SES, Postmark, Brevo) n'a annoncé de support DMARCbis spécifique en mars 2026. C'est normal et attendu : DMARCbis est un changement côté récepteur, pas côté expéditeur. Les ESP n'ont pas besoin de modifier leur infrastructure.

L'alignement DKIM : l'enjeu critique

L'enjeu principal pour les ESP reste l'alignement DKIM. Deux modes de signature existent :

• Domaine partagé (ex : d=sendgrid.net) : la signature DKIM utilise le domaine de l'ESP. L'alignement strict échoue car le domaine DKIM ne correspond pas au domaine From:. L'alignement relaxed échoue aussi.
• Domaine personnalisé via CNAME (ex : d=captaindns.com) : la signature DKIM utilise votre propre domaine. L'alignement passe en strict et en relaxed.

DMARCbis recommande adkim=s (strict). Cette recommandation rend la signature DKIM personnalisée indispensable pour tout domaine qui utilise un ESP.

SPF et le domaine de rebond

DMARCbis élimine la vérification SPF basée sur HELO/EHLO. Seul le domaine MAIL FROM (Return-Path) compte pour l'alignement SPF. La plupart des ESP utilisent un domaine de rebond générique par défaut (ex : bounce.sendgrid.net). Ce domaine ne correspond pas à votre domaine From:, ce qui fait échouer l'alignement SPF.

La solution : configurez un domaine de rebond personnalisé (Return-Path) qui correspond à votre domaine From:. La plupart des ESP proposent cette option via un CNAME DNS.

Checklist ESP

1. Vérifier la signature DKIM personnalisée : votre ESP doit signer avec d=captaindns.com, pas avec son propre domaine.
2. Vérifier le Return-Path personnalisé : le domaine de rebond doit correspondre à votre domaine From:.
3. Tester l'alignement strict : envoyez un email de test et vérifiez les en-têtes. Les champs d= (DKIM) et Return-Path doivent correspondre au domaine From:.
4. Commencer en relaxed, passer en strict : publiez adkim=r d'abord, validez les rapports, puis passez à adkim=s.

Comment migrer vers DMARCbis

La bonne nouvelle : la migration est progressive. Vos enregistrements DMARC actuels restent fonctionnels. Voici les étapes recommandées.

Étape 1 : auditer vos enregistrements actuels

Identifiez tous vos domaines et sous-domaines qui publient un enregistrement _dmarc. Notez les tags utilisés, en particulier pct, ri et rf.

Exemple d'enregistrement existant :

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Étape 2 : retirer les tags obsolètes

Supprimez pct, ri et rf de vos enregistrements. Ces tags seront ignorés par les récepteurs DMARCbis et n'apportent rien aux récepteurs v1.

Enregistrement nettoyé :

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Étape 3 : activer le mode testing si nécessaire

Si vous préparez un passage de quarantine à reject, utilisez t=y pour tester d'abord :

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Avec t=y, les récepteurs DMARCbis appliqueront quarantine au lieu de reject. Les rapports refléteront ce mode test. Après validation (2 à 4 semaines de rapports propres), retirez t=y ou passez à t=n.

Rappel : les récepteurs DMARC v1 ignoreront t=y et appliqueront p=reject directement. Ce n'est pas un bug : c'est le comportement attendu.

Étape 4 : protéger les sous-domaines inexistants

Ajoutez np=reject pour bloquer l'usurpation depuis des sous-domaines qui n'existent pas dans votre DNS :

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; sp=quarantine; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Étape 5 : vérifier l'alignement DKIM

DMARCbis recommande adkim=s (strict) pour les domaines où vous maîtrisez la signature DKIM. L'alignement strict empêche un sous-domaine de réutiliser la signature d'un domaine parent.

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Étape 6 : valider les autorisations de reporting externe

Si vos adresses rua ou ruf pointent vers un domaine différent du domaine DMARC, vérifiez que le record d'autorisation existe :

captaindns.com._dmarc-report._report.monitoring.captaindns.com. IN TXT "v=DMARC1"

Erreurs courantes de migration

Sept pièges reviennent régulièrement lors de la migration vers DMARCbis. Les connaître vous évitera des surprises en production.

1. Publier t=y sans comprendre le comportement v1. Les récepteurs DMARC v1 (encore la majorité en mars 2026) ignorent t=y car c'est un tag inconnu. Ils appliquent p=reject directement, sans rétrogradation. Ce comportement est prévu par conception, mais surprend souvent les administrateurs qui s'attendent à un mode test universel.

2. Garder pct=0 avec t=y. Cette combinaison crée un comportement incohérent. Les récepteurs v1 appliquent pct=0 (pas d'enforcement). Les récepteurs DMARCbis ignorent pct et appliquent t=y (enforcement rétrogradé). Résultat : deux populations de récepteurs avec des comportements différents. Solution : retirez pct avant d'ajouter t.

3. Tree Walk produisant un domaine organisationnel différent du PSL. Certains TLD peu courants ont une entrée PSL qui n'est pas à jour. Le Tree Walk peut alors identifier un domaine organisationnel différent de celui déterminé par l'ancien mécanisme PSL. Mitigation : publiez un record _dmarc explicite avec psd=n au niveau de votre domaine organisationnel.

4. Oublier les records d'autorisation de reporting externe. Quand vous changez de fournisseur de monitoring DMARC, les anciens records _dmarc-report._report pointent vers l'ancien fournisseur. Les rapports cessent silencieusement sans message d'erreur. Mettez à jour ces records à chaque changement de fournisseur.

5. Ne pas tester l'impact de np=reject. Cette politique peut affecter des services légitimes qui utilisent des sous-domaines dynamiques. Certains CDN, plateformes marketing ou outils de campagne créent des sous-domaines à la volée. Vérifiez que ces services n'envoient pas d'email depuis des sous-domaines non enregistrés dans votre DNS.

6. Se fier aux rapports d'échec (ruf). Les grands fournisseurs (Google, Yahoo, Microsoft) ont quasi cessé d'envoyer des rapports d'échec pour des raisons de vie privée et de conformité RGPD. Utilisez les rapports agrégés (rua) comme source principale d'analyse. Les rapports d'échec sont un complément, pas une base fiable.

7. Planifier un déploiement progressif sans pct. Avec pct supprimé dans DMARCbis, le déploiement par pourcentage n'existe plus. Les options sont t=y (rétrogradation complète) ou enforcement complet (pas de t ou t=n). Utilisez t=y avec des fenêtres de monitoring manuelles de 2 à 4 semaines pour reproduire un déploiement progressif.

DMARCbis et la conformité réglementaire

Conformité anti-phishing et norme de paiement

La version 4.0 de PCI DSS (applicable depuis mars 2025) exige des contrôles anti-phishing pour les entités qui traitent des paiements. DMARC en mode enforcement (quarantine ou reject) fait partie des mesures attendues. DMARCbis renforce cette posture avec np=reject (protection des sous-domaines inexistants) et la recommandation d'alignement strict DKIM.

Les exigences de Google et Yahoo pour l'envoi en masse

Depuis février 2024, Google et Yahoo exigent DMARC pour les expéditeurs de plus de 5 000 messages par jour. Bien que ces fournisseurs n'aient pas encore implémenté DMARCbis, ils reconnaîtront les enregistrements nettoyés (sans pct, ri, rf) puisque ces tags sont déjà largement ignorés.

Microsoft et Exchange Online

Microsoft applique progressivement des vérifications DMARC plus strictes sur Exchange Online et Outlook. L'adoption de DMARCbis par Microsoft n'est pas encore annoncée, mais la préparation anticipée évitera des ajustements de dernière minute.

Adoption actuelle (mars 2026)

L'adoption côté récepteurs est encore marginale. Seul United Internet AG (GMX, mail.com, WEB.DE) émet des rapports au format DMARCbis (3 reporters sur 3 493 dans les données observées). Google, Microsoft, Yahoo et Amazon SES n'ont pas encore migré. C'est le moment de préparer vos enregistrements : quand les grands fournisseurs basculeront, vous serez prêt.

🎯 Plan d'action : préparer la transition

1. Inventorier tous les domaines et sous-domaines publiant un record _dmarc. Identifier les Author Domains réels et les zones sans enregistrement DMARC.
2. Tester avec le DMARCbis Checker la compatibilité de chaque domaine. Identifier les tags obsolètes et les recommandations spécifiques.
3. Nettoyer vos enregistrements : retirer pct, ri, rf. Conserver v=DMARC1.
4. Ajouter np=reject au niveau du domaine organisationnel pour protéger les sous-domaines inexistants.
5. Utiliser t=y pour toute montée en puissance de politique (passage de quarantine à reject).
6. Renforcer l'alignement : cibler adkim=s en priorité, garder aspf=r sauf besoin strict.
7. Valider les autorisations externes si vos adresses rua/ruf pointent vers un tiers.
8. Surveiller les rapports agrégés pendant 2 à 4 semaines après chaque changement pour détecter les anomalies.

FAQ

Faut-il changer v=DMARC1 en v=DMARC2 ?

Non. La version de l'enregistrement reste v=DMARC1. DMARCbis ne modifie pas le tag de version. Vos enregistrements existants continuent de fonctionner sans aucune modification du tag v.

Qu'est-ce que le DNS tree walk ?

Le DNS Tree Walk est l'algorithme DMARCbis qui remplace la Public Suffix List pour découvrir la politique DMARC applicable à un domaine. Il interroge le DNS en remontant label par label depuis le domaine expéditeur (Author Domain), avec une limite de 8 requêtes, jusqu'à trouver un enregistrement _dmarc qui identifie le domaine organisationnel via le tag psd.

Le PSL disparaît-il totalement ?

Oui, du point de vue de DMARCbis. La découverte de politique et la détermination du domaine organisationnel passent intégralement par le DNS Tree Walk. La Public Suffix List n'est plus référencée dans le standard. Certains récepteurs pourront maintenir un fallback PSL pendant la transition, mais ce n'est pas requis.

Pourquoi le tag pct a-t-il été supprimé ?

En pratique, seules les valeurs 0 (mode test) et 100 (application complète) étaient utilisées. Le comportement pour les valeurs intermédiaires variait entre récepteurs, rendant le résultat imprévisible. Le tag t=y/n le remplace avec une sémantique binaire claire : soit la politique est rétrogradée d'un niveau (test), soit elle s'applique normalement.

Mon enregistrement DMARC actuel est-il compatible DMARCbis ?

Oui, à condition que le tag v=DMARC1 soit présent. DMARCbis est rétrocompatible. Les tags pct, ri et rf seront ignorés par les récepteurs DMARCbis, sans provoquer d'erreur. La migration recommandée consiste à les retirer et à adopter progressivement np, psd et t.

Puis-je publier p=reject pour tous mes domaines ?

DMARCbis déconseille p=reject pour les domaines à usage général (listes de diffusion, alias, redirections). Réservez p=reject aux domaines où vous contrôlez chaque intermédiaire de bout en bout. Pour les autres cas, p=quarantine reste recommandé. Les récepteurs ne doivent pas rejeter un message uniquement parce que p=reject est publié : ils doivent croiser avec d'autres signaux (ARC, réputation, listes de diffusion).

Le tag t=y est-il risqué pendant la transition ?

Il y a un risque calculé. Les récepteurs DMARC v1 ignorent t=y (tag inconnu) et appliquent la politique telle quelle. Si vous publiez p=reject; t=y, un récepteur v1 appliquera reject sans rétrogradation. Un récepteur DMARCbis appliquera quarantine. Ce comportement est intentionnel : il favorise la sécurité par défaut. Utilisez t=y uniquement si vous acceptez que la politique stricte s'applique chez les récepteurs qui n'ont pas encore migré.

Qui doit utiliser le tag psd ?

Uniquement les opérateurs de suffixes publics : registres de TLD (co.uk, com.au, gouv.fr), registres sectoriels, et les grandes organisations qui délèguent des sous-domaines à des entités indépendantes. Pour un domaine d'entreprise standard, laissez psd absent ou indiquez psd=n.

Quand les grands fournisseurs implémenteront-ils DMARCbis ?

Aucune date n'a été annoncée publiquement (mars 2026). L'adoption côté récepteurs est marginale : seul United Internet AG (GMX, mail.com, WEB.DE) émet des rapports au format DMARCbis. La publication des RFC déclenchera probablement l'implémentation chez les grands fournisseurs. Préparer vos enregistrements maintenant vous positionne en avance.

Comment fonctionne la chaîne de fallback np, sp, p ?

Quand un récepteur DMARCbis reçoit un email depuis un sous-domaine, il vérifie d'abord si ce sous-domaine existe dans le DNS. S'il n'existe pas (NXDOMAIN), la politique np s'applique. Si np n'est pas défini, le récepteur utilise sp. Si sp n'est pas défini non plus, p s'applique. Pour les sous-domaines existants, le fallback est sp puis p (identique à DMARC v1).

DMARCbis ralentit-il le traitement des emails ?

Non. Le Tree Walk ajoute 1 à 2 requêtes DNS pour un domaine typique à 3 labels. Le cache DNS atténue cet impact : les records _dmarc et les réponses NXDOMAIN sont mis en cache. La limite de 8 requêtes garantit un temps de traitement borné, même pour les domaines profonds. En pratique, la différence de latence est négligeable.

Mon ESP doit-il supporter DMARCbis ?

DMARCbis est un changement côté récepteur. Votre ESP n'a pas besoin de le supporter spécifiquement. En revanche, vérifiez deux points critiques : la signature DKIM personnalisée (avec d= correspondant à votre domaine) et le Return-Path personnalisé (domaine de rebond aligné avec votre domaine From:). Ces deux éléments sont indispensables pour l'alignement strict recommandé par DMARCbis.

Glossaire

• Author Domain : domaine utilisé dans l'en-tête From: du message. C'est le point de départ du Tree Walk et de l'alignement DMARC.
• DNS Tree Walk : algorithme DMARCbis qui remonte l'arbre DNS label par label pour trouver un enregistrement _dmarc et déterminer le domaine organisationnel. Limite de 8 requêtes.
• Organizational Domain : domaine principal d'une organisation, identifié par le Tree Walk (via psd=n ou absence de psd). Il fait autorité pour la politique DMARC applicable à ses sous-domaines.
• PSL (Public Suffix List) : liste maintenue par Mozilla des suffixes publics. Utilisée par DMARC v1, remplacée par le Tree Walk dans DMARCbis.
• PSD (Public Suffix Domain) : suffixe de nom de domaine opéré par une entité qui délègue des sous-domaines (ex : co.uk, gouv.fr). Identifié par psd=y dans l'enregistrement DMARC.
• PSO (Public Suffix Operator) : entité qui administre un PSD et peut publier une politique DMARC de référence pour les domaines rattachés.

📚 Guides email connexes

• DKIM2 : tout ce qui change
• ARC : la chaîne d'authentification expliquée
• BIMI, VMC, CMC : compatibilité DNS
• Gmail Bulk Sender 2025

Sources

1. draft-ietf-dmarc-dmarcbis (IETF Datatracker)
2. draft-ietf-dmarc-aggregate-reporting (IETF Datatracker)
3. draft-ietf-dmarc-failure-reporting (IETF Datatracker)
4. DMARC.org Resources
5. PCI DSS 4.0 Summary of Changes (PCI SSC)