DMARCbis : tout ce qui change (et comment s'y préparer)

État au 29 octobre 2025. Le corpus DMARCbis est quasiment finalisé : le document principal dmarcbis-41 et aggregate-reporting-32 sont en RFC Editor Queue (état MISSREF), en attente du document failure-reporting, toujours en cours de finalisation. Les enregistrements DMARC existants restent au format v=DMARC1.

TL;DR

• Découverte de politique & domaine organisationnel : abandon du Public Suffix List (PSL) → DNS Tree Walk + ajout du marqueur psd (y/n).
• Nouveaux tags : psd, np (politique pour non-existent domains), t (testing, remplaçant l'usage utile de pct=0).
• Tags supprimés : pct, ri, rf.
• Reporting : scindé en 2 documents normatifs (agrégats et échecs) ; suppression de la limite de taille dans l'URI ; un rapport DOIT être envoyé à chaque URI listée.
• Interopérabilité : DMARCbis déconseille p=reject pour les domaines à trafic généraliste (listes, alias, redirections) et recommande p=quarantine tant que la chaîne d'authentification n'est pas totalement maîtrisée ; gardez p=reject pour les cas où vous contrôlez chaque intermédiaire. Les MTA ne devraient pas rejeter uniquement sur la base de p=reject.
• Compatibilité : les enregistrements DMARC actuels continuent de fonctionner. Préparez la transition vers les nouveaux tags et nouvelles pratiques.

👉 Un glossaire en fin d'article résume les notions clés : Public Suffix Domain, Organizational Domain et DNS Tree Walk.

1) Calendrier & statut

• 17 mars 2025 : Aggregate Reporting v**–32** → RFC Editor Queue (MISSREF).
• 4 avril 2025 : DMARCbis v**–41** → RFC Editor Queue (MISSREF).
• 9 octobre 2025 : Failure Reporting v**–17** : WG Last Call en cours.
• Publication en 2025 visée si les dépendances sont résolues.
• Impact immédiat : aucun changement de version d'enregistrement (v=DMARC1) ; en revanche, les implémenteurs et opérateurs doivent se préparer aux nouveaux algorithmes et tags.

2) Découverte de politique & Organizational Domain : le DNS Tree Walk

DMARCbis remplace la dépendance au PSL par une marche dans l'arbre DNS pour :

1. Découvrir la politique applicable (Policy Discovery), et
2. Déterminer le domaine organisationnel (Organizational Domain) pour l'Alignment.

Principes clefs :

• On cherche d'abord un enregistrement à "_dmarc." + AuthorDomain. À défaut, on remonte label par label (limite : 8 requêtes) pour identifier le domaine organisationnel ou un PSD.
• Le tag psd pilote l'interprétation :
  • psd=n ⇒ le domaine porteur est un Organizational Domain.
  • psd=y (au-dessus) ⇒ l'Organizational Domain est un label en-dessous.
• Si une politique vient d'un domaine parent (Org ou PSD), on applique sp (si le sous‑domaine existe) ou np (s'il n'existe pas).
• Si rien n'est trouvé, DMARC ne s'applique pas au message.

3) Tags : ajouts, suppressions, inchangés

Ajoutés

• psd : marque qu'un domaine est un Public Suffix Domain (y/n), pour guider le Tree Walk.
• np : politique pour domaines inexistants (héritée de l'expérience PSD).
• t : mode test (y/n) - remplace l'usage utile de pct=0 (voir plus bas).

Supprimés

• pct : l'application partielle était incohérente selon les implémentations ; on garde uniquement l'usage 0/100 via t.
• ri : intervalle des rapports agrégés (dorénavant géré par le document Aggregate Reporting et la pratique opérateur).
• rf : format de rapport d'échec (clarifié dans le document Failure Reporting).

Inchangés (exemples)

v, p, sp, adkim, aspf, fo, rua, ruf, pct (supprimé - à retirer).

4) psd : marqueur Public Suffix Domain

Le tag psd précise si le domaine qui publie l'enregistrement DMARC doit être traité comme un Public Suffix Domain (PSD) par l'algorithme de Tree Walk :

• psd=y : le domaine est reconnu comme PSD. La politique publiée s'applique au suffixe que vous administrez, mais laisse la main aux domaines enregistrables situés en dessous pour gérer leur propre DMARC.
• psd=n : le domaine est bien un Organizational Domain et sert de point d'ancrage à la découverte de politique DMARC pour ses sous-domaines.

Réservez psd=y aux opérateurs de suffixe (TLD, registres sectoriels, grandes organisations qui délèguent des sous-domaines). Ailleurs, laissez psd absent ou indiquez psd=n pour clarifier que la zone est un domaine émetteur « classique ».

5) np : politique pour domaines inexistants

Le tag np étend DMARC aux sous-domaines inexistants découverts lors du Tree Walk :

• Il ne s'applique que si aucun enregistrement _dmarc dédié n'est trouvé pour le sous-domaine ciblé (retour NXDOMAIN).
• Les valeurs autorisées (none, quarantine, reject) suivent la même logique que p/sp.
• En l'absence de np, la valeur de p (ou sp) est utilisée par défaut.

Publiez np=reject au niveau de votre domaine organisationnel (ou d'un PSD que vous opérez) pour bloquer les tentatives d'usurpation sur des sous-domaines « vides » sans devoir multiplier les enregistrements DMARC individuels.

6) t = testing : le successeur pratique de pct=0

Le tag t=y n'empêche pas le reporting, mais demande d'adoucir l'application de la politique d'évaluation :

• p=reject + t=y ⇒ appliquer quarantine aux échecs.
• p=quarantine + t=y ⇒ appliquer none aux échecs.
• p=none ⇒ inchangé.

Objectif : permettre la montée en puissance sûre sans les problèmes d'implémentation de pct.

7) Reporting : séparation, livrabilité & sécurité

• Scindé en deux documents : agrégats (XML) et échecs (message‑par‑message).
• Plus de limite de taille dans l'URI de reporting.
• Plusieurs URIs (rua=/ruf=) : un rapport doit être envoyé à chacune.
• Vérification externe (rua/ruf vers un autre domaine) : mécanisme inchangé (records d'autorisation côté destinataire).
• Vie privée : échecs (failure reports) à activer avec discernement, la plupart des opérateurs privilégient les agrégats.

8) Interopérabilité & politiques

• DMARCbis explicite que pour un domaine de messagerie à usage général (listes de diffusion, alias, redirections), il est déconseillé de publier p=reject et est recommandé p=quarantine tant que la chaîne d'authentification n'est pas maîtrisée de bout en bout. Conservez p=reject uniquement si vous contrôlez entièrement vos flux et leurs intermédiaires.
• Les récepteurs ne devraient pas rejeter un message uniquement parce qu'une politique reject est publiée. Ils doivent croiser avec d'autres signaux (listes de diffusion, réécritures d'entêtes, ARC, réputation, etc.).
• Pour éviter les contournements en mode relaxed, publier des enregistrements DMARC au plus près des domaines expéditeurs (et envisager adkim=s/aspf=s là où c'est pertinent).

9) Compatibilité & transition

• Rien ne change pour v=DMARC1 : vos enregistrements existants restent valides.
• À retirer progressivement : pct, ri, rf.
• À introduire : psd là où c'est nécessaire (PSO / TLD ou domaines enregistrables particuliers), np pour cadrer les non-existent domains, t pour piloter vos paliers.

Exemples d'enregistrements

Politique Org + montée contrôlée

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=r; 
  rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; t=y"

Marquage PSD côté opérateur de suffixe

_dmarc.bank.example. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:psd-agg@pso.example"

Politique pour domaines inexistants

_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:agg@example.net"

10) Playbook CaptainDNS (recommandations pratiques)

1. Inventaire : listez Author Domains réels et sous‑domaines actifs, identifiez les zones sans enregistrement DMARC.
2. Arbres DNS : vérifiez l'effet du Tree Walk (où tomberait l'Organizational Domain ?) et publiez des enregistrements au plus près des émetteurs effectifs.
3. Politiques : commencez par p=quarantine + t=y, monitoring des agrégats pendant 2–4 semaines, passez à t=n, puis renforcez si les faux positifs sont maîtrisés.
4. Alignment : ciblez adkim=s en priorité (DKIM signer sur le From), gardez aspf=r sauf contexte strict.
5. PSD / np : si vous opérez un domaine racine, utilisez np pour bloquer les non-existent domains. N'utilisez psd que si vous êtes PSO/PSD.
6. Reporting : conservez des adresses rua/ruf dédiées, chiffrées en transit. Validez les autorisations externes si vous passez par un tiers.
7. Listes / Intermédiaires : anticipez les réécritures de From:. ARC peut aider à conserver la réputation tout en évitant les rejets abusifs.
8. Nettoyage : retirez pct, ri, rf des zones. Surveillez les agrégats pour détecter des divergences d'implémentation.

11) FAQ

• Faut‑il changer v=DMARC1 en v=DMARC2 ? Non, la valeur reste DMARC1.

• pct est‑il encore compris ? Il est retiré du standard. Certains récepteurs peuvent l'ignorer. Utilisez t.

• Le PSL disparaît‑il totalement ? Oui, côté DMARCbis : la découverte passe par le DNS Tree Walk.

• Puis‑je publier p=reject partout ? À réserver aux domaines où vous maîtrisez intégralement la chaîne d'authentification. Pour la messagerie générale (listes de diffusion, alias, redirections, etc.), DMARCbis recommande d'être en p=quarantine.

12) Glossaire

• Public Suffix List (PSL) : liste maintenue historiquement par Mozilla des suffixes publics. DMARCbis remplace son usage par le DNS Tree Walk.
• Public Suffix Domain (PSD) : suffixe de nom de domaine opéré par une entité qui délègue des sous-domaines à d'autres organisations (ex. TLD, regroupements sectoriels) et qui publie une politique DMARC couvrant tout le suffixe.
• Public Suffix Operator (PSO) : entité qui gère un suffixe public (PSD) et peut publier une politique DMARC de référence pour les domaines qui y sont rattachés.
• DNS Tree Walk : procédure DMARCbis consistant à remonter l'arbre DNS label par label pour trouver un enregistrement _dmarc, reconnaitre un PSD et, au besoin, appliquer une politique héritée (p, sp, np).
• Organizational Domain : domaine principal d'une organisation, identifié par le Tree Walk, qui fait autorité pour déterminer la politique DMARC applicable à ses sous-domaines.
• Author Domain : domaine utilisé dans l'entête From: visible par le destinataire ; il sert de base au calcul de l'alignement DMARC.

---

Illustrations : schémas SVG faits maison pour CaptainDNS.