En mai 2026, l’IETF a publié officiellement DMARCbis, la nouvelle version du standard DMARC (Domain-based Message Authentication, Reporting, and Conformance). Cette mise à jour remplace la RFC 7489 de 2015 avec trois nouveaux documents : RFC 9989, RFC 9990 et RFC 9991.
Mais qu’est-ce qui change réellement ? Est-ce une révolution ou une évolution ? Quelles sont les implications concrètes pour vous, que vous soyez administrateur de domaine, fournisseur de messagerie ou spécialiste en sécurité email ?
Cet article démystifie DMARCbis, explique ses innovations, et vous aide à comprendre l’impact sur votre infrastructure.
Contexte : Une mise à jour bien attendue
Pourquoi une nouvelle RFC ?
La RFC 7489 (2015) a servi pendant 11 ans. Pendant ce temps, plusieurs limites et ambiguïtés ont émergé :
- Découverte de politique floue : Utiliser une Public Suffix List (PSL) externe crée des divergences d’implémentation et des problèmes de performance.
- Tags confus : Le tag
pct=(sampling rate) est mal utilisé ;rf=etri=sont rarement supportés. - Rapports mal structurés : Absence de clarté sur la méthode de découverte utilisée, absence de test mode explicite.
- SPF alignement ambigu : Quelle adresse utiliser pour SPF, HELO, EHLO ou MAIL FROM ?
DMARCbis adresse tous ces problèmes.
Statut du standard
| Version | Type | Statut |
|---|---|---|
| RFC 7489 (2015) | Publication “Informational” | Informelle, non contraignante |
| RFC 9989/9990/9991 (2026) | Standards Track IETF | Formelle, contraignante |
Le passage en Standards Track signifie que les implémentations futures devront s’y conformer strictement.
Le changement le plus important : DNS Tree Walk
Avant (RFC 7489 + PSL)
La découverte de policy utilisait une Public Suffix List externe, hébergée et maintenue de façon centralisée :
mail.example.com → Vérifier PSL → Récupérer policy de example.com
Problèmes :
- Divergence entre implémentations (quelle version de PSL ?)
- Dépendance à un opérateur centralisé (Mozilla gère la PSL publique)
- Manque de flexibilité pour structures de domaines complexes
Maintenant (RFC 9989 - DNS Tree Walk)
La découverte utilise un algorithme de traversée DNS décentralisé :
Domaine: mail.example.com
↓
Cherche _dmarc.mail.example.com → Non trouvé
↓
Cherche _dmarc.example.com → Trouvé ✓
↓ (limite : max 8 labels, anti-DoS)
Avantages :
- ✅ Décentralisé, chaque domaine contrôle sa propre découverte
- ✅ Transparent, pas de liste externe à maintenir
- ✅ Flexible, supporte les structures complexes (*.co.uk, *.github.io, etc.)
Où les divergences se produisent
Exemple : news.fr.example.com
| Approche | Chemin suivi | Résultat |
|---|---|---|
| PSL | Consulte la liste → example.com | Cherche _dmarc.example.com |
| Tree Walk | _dmarc.news.fr.example.com → _dmarc.fr.example.com → _dmarc.example.com | Même résultat ici |
Cas critique : mycompany.co.uk
| Approche | Résultat |
|---|---|
| PSL | .co.uk est un PSD → cherche policy co.uk |
| Tree Walk | Cherche mycompany.co.uk puis co.uk → peut trouver une policy différente |
Action recommandée : Lors de la migration vers RFC 9989, testez votre domaine avec les deux méthodes pour détecter une divergence.
Nouveau tag : psd= pour les Public Suffix Domains
Avec le tree walk vient une nouvelle responsabilité pour les opérateurs de domaines “publics” (.co.uk, .github.io, etc.).
v=DMARC1; p=none; psd=y; rua=mailto:dmarc@example.com
psd=y: Ce domaine est un Public Suffix Domainpsd=n: Non, ce n’est pas un PSD (défaut)psd=u: Incertain
Les receivers savent ainsi comment gérer la découverte pour les sous-domaines de ce PSD.
Tags dépréciés : Ce qui disparaît
Ces tags existent toujours dans l’enregistrement DNS mais seront ignorés par les implémentations RFC 9989 :
| Tag | Ancienne fonction | Pourquoi déprécié | Remplacement |
|---|---|---|---|
pct | Sampling rate (%) | Mauvaise pratique, confusion | t=y (mode test) |
rf | Format des rapports d’échec | Rarement implémenté | RFC 9991 clarifie |
ri | Intervalle de rapport | Rarement utilisé | Recommandation RFC 9990 |
⚠️ Important : Si votre policy contient
pct=50, un receiver RFC 9989 l’ignorera complètement et appliquera la policy à 100%. Ne comptez plus surpct=pour tester.
Nouveaux tags : Ce qui arrive
t=, Mode test explicite
C’est le remplaçant propre du pct=0 mal utilisé.
Avant (RFC 7489) :
v=DMARC1; p=none; pct=0; rua=mailto:...
→ Ambigu : testez-vous reject, ou avez-vous juste oublié de monter la policy ?
Maintenant (RFC 9989) :
v=DMARC1; p=reject; t=y; rua=mailto:...
→ Explicite : “Je teste reject, mais appliquez quarantine ou none pendant ce test.”
Les rapports RUA indiqueront testing: y pour confirmer le mode actif.
np=, Policy pour sous-domaines inexistants
Protège contre les attaquants qui envoient depuis des sous-domaines aléatoires ou inexistants.
v=DMARC1; p=reject; np=reject; rua=mailto:...
np=reject: Rejette les emails de sous-domaines inexistantsnp=quarantine: Les met en quarantinenp=none: Pas d’action (défaut)
Cas d’usage : Un attaquant envoie depuis fakesupport.example.com qui n’existe pas dans votre DNS. Avec np=reject, l’email est rejeté.
SPF dans DMARC : Une clarification importante
Le problème (RFC 7489)
Certaines implémentations utilisaient le domaine HELO/EHLO pour valider SPF dans DMARC. D’autres utilisaient MAIL FROM. Ambiguïté totale.
La règle (RFC 9989)
SPF domain scope = MAIL FROM uniquement. Pas de fallback HELO.
Exemple :
MAIL FROM: <sender@subdomain.example.com>
HELO: smtp.cloudflare.com
From: user@example.com
Pour DMARC, SPF doit valider subdomain.example.com (MAIL FROM), pas smtp.cloudflare.com (HELO).
Format des rapports RUA (RFC 9990)
Nouveaux champs dans les rapports
Les rapports agrégés incluent maintenant deux champs clés absents en RFC 7489 :
<policy_published>
<discovery_method>treewalk</discovery_method> <!-- treewalk ou psl -->
<testing>y</testing> <!-- y si t=y actif -->
<np>none</np> <!-- policy np= appliquée -->
</policy_published>
Ce que ces champs vous apprennent
| Champ | Valeur | Signification |
|---|---|---|
discovery_method | treewalk | Receiver a utilisé RFC 9989 |
discovery_method | psl | Receiver utilise encore RFC 7489 |
testing | y | Votre mode test est actif |
testing | n | Vous êtes en production |
Implications pour les senders
Ce qui reste inchangé
- ✅ Vos policies existantes continuent de fonctionner
- ✅ Les tags
v,p,sp,rua,rufsont inchangés - ✅ Pas d’action urgente requise
Ce qui nécessite attention
- ⚠️
pct=sera ignoré par les receivers RFC 9989 → migrer verst=y - ⚠️ Tester les divergences PSL vs tree walk si votre domaine a une structure complexe
- ⚠️ Vérifier que votre SPF valide bien MAIL FROM (pas HELO)
Chemin de migration recommandé
| Phase | Policy | Durée |
|---|---|---|
| Audit | Tester PSL vs tree walk, vérifier SPF | 1-2 semaines |
| Transition | Remplacer pct= par t=y; p=reject | 2-6 mois |
| Production | Passer à p=reject (sans t=y) + ajouter np= | 6 mois+ |
Implications pour les mailbox providers (Receivers)
Complexité accrue
L’implémentation du tree walk est plus complexe que la consultation d’une PSL :
- Requêtes DNS supplémentaires par email
- Algorithme de traversée à gérer
- Dual support PSL + tree walk pendant la transition
Timeline de déploiement estimée
| Période | État |
|---|---|
| 2026 | RFC publiée, implémentations débutent |
| 2026-2027 | Grands providers (Gmail, Microsoft, Yahoo) annoncent support |
| 2027-2028 | Déploiement principal, dual support PSL + tree walk |
| 2028+ | RFC 7489 en “Historic”, deprecation formelle |
La transition prendra 2 à 3 ans. Support des deux méthodes obligatoire pendant cette période.
Rétrocompatibilité : Le bilan
Niveau de rétrocompatibilité : Modéré ⚠️
| Aspect | Impact | Risque |
|---|---|---|
| Policies existantes | ✅ Compatibles | Faible |
Tags pct, rf, ri | ⚠️ Ignorés par RFC 9989 | Moyen (si utilisés pour tester) |
| PSL vs Tree Walk | ⚠️ Peut diverger | Élevé pour domaines complexes |
| SPF MAIL FROM only | ✅ La plupart l’implémentaient déjà | Faible |
Recommandations
- Tester votre domaine avec PSL et tree walk, vérifier qu’il n’y a pas de divergence
- Remplacer
pct=part=y; p=rejectdès maintenant - Surveiller
discovery_methoddans vos rapports RUA - Votre fournisseur de rapports doit supporter les deux méthodes jusqu’en 2028
Récapitulatif : RFC 7489 vs RFC 9989
| Fonctionnalité | RFC 7489 | RFC 9989 |
|---|---|---|
| Découverte policy | PSL externe | DNS Tree Walk |
| Mode test | pct=0 (ambigu) | t=y (explicite) |
| Subdomains inexistants | Non géré | np= |
| SPF scope | Ambigu (HELO ou MAIL FROM) | MAIL FROM uniquement |
| Statut IETF | Informational | Standards Track |
| Rapport RUA | Pas de discovery_method | discovery_method + testing |
Ressources officielles
- RFC 9989, DMARC Specification (Protocol core)
- RFC 9990, DMARC Aggregate Reporting
- RFC 9991, DMARC Failure Reporting
- dmarc.org, Ressources communautaires
- IETF DMARC WG, Groupe de travail IETF
DMARCbis est une évolution majeure, pas une révolution pour la plupart des administrateurs de domaine. Vos policies existantes restent valides, mais exploiter les nouvelles fonctionnalités (mode test, np=, tree walk) vous donnera une meilleure protection et plus de flexibilité.
Prochaine étape : Consultez notre guide pratique DMARCbis pour les actions concrètes à entreprendre sur votre domaine.