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

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, surveillez les 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 besoin 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 un tiers reçoit les rapports.

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, alias, redirections), DMARCbis recommande 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.