DMARCbis : ce qui change pour votre domaine
DMARCbis (aussi appelé DMARC v2) n'est pas une simple mise à jour. C'est la refonte complète du protocole DMARC, divisée en trois RFC distincts. Un DMARCbis checker permet d'identifier les ajustements nécessaires :
- Mécanisme principal (draft-ietf-dmarc-dmarcbis) : découverte de politique, alignment, évaluation
- Rapports agrégés (draft-ietf-dmarc-aggregate-reporting) : format XML, schéma, distribution
- Rapports d'échec (draft-ietf-dmarc-failure-reporting) : rapports ARF, privacy, rate limiting
Nouveaux tags
| Tag | Rôle | Valeurs | Par défaut |
|---|---|---|---|
np | Politique pour les sous-domaines inexistants (NXDOMAIN) | none, quarantine, reject | Hérite de sp, puis p |
t | Mode test (remplace pct) | y, n | n (application complète) |
psd | Déclaration Public Suffix Domain | y, n, u | u (indéterminé) |
Tags supprimés
| Tag | Raison |
|---|---|
pct | Application inconsistante entre récepteurs. Remplacé par le tag binaire t. |
rf | Seul le format afrf était supporté. Tag inutile. |
ri | Rarement respecté par les récepteurs. Les rapports sont désormais envoyés quotidiennement. |
Tree walk DNS
Le changement le plus important de DMARCbis est le remplacement de la Public Suffix List (PSL) par un algorithme de parcours DNS natif.
Pourquoi ? La PSL est une liste communautaire maintenue par des volontaires Mozilla. Elle souffre de délais de mise à jour, d'incohérences entre implémentations et de l'absence de spécification IETF sur la version à utiliser. Le tree walk DNS résout ces problèmes en s'appuyant uniquement sur les données DNS réelles.
Comment ça marche : le récepteur interroge _dmarc.<domaine>, puis remonte d'un label à chaque étape. Si un enregistrement contient psd=n, c'est le domaine organisationnel. Si psd=y est trouvé, le domaine un niveau en dessous est le domaine organisationnel.
Qui adopte DMARCbis aujourd'hui ?
En mars 2026, seuls GMX, mail.com et WEB.DE (groupe United Internet) envoient des rapports au format DMARCbis. L'adoption massive est attendue après la publication officielle des RFC. Les enregistrements DMARCbis sont rétrocompatibles : les récepteurs qui ne comprennent pas les nouveaux tags les ignorent simplement.
Préparez-vous maintenant
Même si la migration n'est pas urgente, préparer son domaine dès maintenant permet de :
- Identifier les tags obsolètes à supprimer avant qu'ils ne génèrent des avertissements
- Ajouter le tag
nppour protéger les sous-domaines inexistants - Comprendre le tree walk et vérifier que votre domaine organisationnel est correctement déterminé
- Anticiper les changements de reporting dans vos outils d'analyse DMARC
DMARC vs DMARCbis : tableau comparatif
| Aspect | DMARC (RFC 7489) | DMARCbis |
|---|---|---|
| Version tag | v=DMARC1 | v=DMARC1 (inchangé) |
| Découverte de politique | Public Suffix List (PSL) | Tree walk DNS natif |
| Domaine organisationnel | Déterminé via la PSL externe | Déterminé dynamiquement via psd=y / psd=n |
| Tag pct | Valeur de 0 à 100 | Supprimé, remplacé par t |
| Mode test | pct=0 (comportement variable) | t=y (sémantique binaire claire) |
| Politique NP | Absente | np=none|quarantine|reject |
| Support PSD | RFC 9091 expérimental | Intégré nativement via le tree walk |
| Format de rapports | Document unique | Trois RFC séparés (mécanisme, agrégés, échecs) |
| Scope SPF | MAIL FROM et HELO | MAIL FROM uniquement |
| Tags supprimés | Aucun | pct, rf, ri |
Ce tableau résume les différences structurelles entre les deux versions du protocole. Si votre enregistrement contient des tags de la colonne DMARC qui n'existent plus dans DMARCbis, le checker les signale automatiquement.
Comment fonctionne le tree walk DNS ?
Le tree walk DNS est l'innovation centrale de DMARCbis. Il remplace la consultation de la Public Suffix List par un parcours hiérarchique du DNS. Voici un exemple détaillé pour comprendre chaque étape.
Exemple : un email reçu de user@sub.mail.captaindns.com
Le récepteur doit trouver la politique DMARC applicable. Avec DMARCbis, il effectue les requêtes suivantes dans l'ordre :
- Requête
_dmarc.sub.mail.captaindns.com: le serveur DNS répond NXDOMAIN (aucun enregistrement). Le récepteur remonte d'un label. - Requête
_dmarc.mail.captaindns.com: le serveur DNS répond NXDOMAIN. Le récepteur remonte encore. - Requête
_dmarc.captaindns.com: un enregistrement TXT est trouvé, par exemplev=DMARC1; p=reject; psd=n.
Le tag psd=n indique que captaindns.com est un domaine organisationnel (et non un suffixe public). Le tree walk s'arrête. Le résultat : domaine organisationnel = captaindns.com, méthode de découverte = tree walk.
Que se passe-t-il avec psd=y ? Si _dmarc.captaindns.com contenait psd=y, cela signifierait que captaindns.com est un suffixe public (comme .co.uk). Dans ce cas, le domaine organisationnel serait mail.captaindns.com, soit le domaine un niveau en dessous du suffixe.
Limite de sécurité : le tree walk effectue au maximum 8 requêtes DNS pour éviter toute amplification. Au-delà de 8 niveaux sans résultat, la découverte échoue et le domaine est traité comme s'il n'avait pas de politique DMARC publiée.
Avantage décisif : contrairement à la PSL qui nécessite des mises à jour manuelles et varie selon les implémentations, le tree walk s'appuie sur les données DNS en temps réel. Les administrateurs DNS conservent le contrôle total de leur périmètre organisationnel.
Pourquoi le tag np est essentiel
Le tag np (non-existent domain policy) comble une faille de sécurité que DMARC v1 ne pouvait pas adresser : l'usurpation de sous-domaines inexistants.
Le vecteur d'attaque : un attaquant envoie un email depuis fake123.captaindns.com. Ce sous-domaine n'existe pas dans votre zone DNS. Avec DMARC v1, le récepteur applique la politique sp (si présente) ou se rabat sur p. Si votre configuration est p=reject; sp=none (configuration courante pour autoriser les sous-domaines légitimes), l'attaquant passe à travers la protection.
La solution DMARCbis : le tag np=reject s'applique exclusivement aux sous-domaines dont le DNS répond NXDOMAIN. Vous pouvez ainsi maintenir une politique souple sur vos sous-domaines existants (sp=none ou sp=quarantine pour les sous-domaines avec des flux email légitimes) tout en bloquant les sous-domaines inventés par les attaquants.
Configuration recommandée :
- Si
p=reject: ajouteznp=rejectpour une couverture maximale - Si
p=quarantine: ajouteznp=reject(les sous-domaines fictifs méritent un blocage strict) - Si
p=none: ajouteznp=quarantinecomme première étape vers le renforcement
Le tag np est particulièrement efficace contre les attaques de type CEO fraud, où les attaquants inventent des sous-domaines crédibles comme secure-payment.captaindns.com ou internal-hr.captaindns.com pour tromper les destinataires.
Calendrier d'adoption DMARCbis
La transition vers DMARCbis suit un calendrier progressif piloté par l'IETF et les grands fournisseurs de messagerie.
| Date | Événement |
|---|---|
| 2015 | Publication du RFC 7489 (DMARC original) |
| 2021 | Publication du RFC 9091 (PSD DMARC, expérimental) |
| 2024 | GMX, mail.com et WEB.DE (groupe United Internet) deviennent les premiers récepteurs à envoyer des rapports au format DMARCbis |
| Avril 2025 | Approbation IESG du document principal (draft-ietf-dmarc-dmarcbis) et des rapports agrégés (draft-ietf-dmarc-aggregate-reporting) |
| Novembre 2025 | Soumission du document sur les rapports d'échec (draft-ietf-dmarc-failure-reporting) |
| 2025 / 2026 | Les trois documents sont dans la file d'attente de l'éditeur RFC |
| 2026 (prévu) | Publication officielle en tant que Proposed Standard |
Les enregistrements DMARCbis sont rétrocompatibles : vous pouvez ajouter les nouveaux tags dès maintenant sans attendre la publication officielle. Les récepteurs qui ne comprennent pas np, t ou psd les ignorent silencieusement.
Outils complémentaires
| Outil | Description |
|---|---|
| Migration DMARC vers DMARCbis | Générer automatiquement un enregistrement DMARCbis conforme |
| Validateur DMARC | Valider la syntaxe de votre enregistrement DMARC |
| Inspecteur DMARC | Consulter et analyser l'enregistrement DMARC publié |
| Générateur DMARC | Créer un nouvel enregistrement DMARC |
| Lecteur de rapports DMARC | Décoder les rapports agrégés XML |
Ressources utiles
- RFC 7489 - DMARC
- draft-ietf-dmarc-dmarcbis
- RFC 9091 - PSD DMARC
- DMARCbis : tous les changements et comment se préparer
FAQ - Questions fréquentes
Q : Qu'est-ce que DMARCbis ?
R : DMARCbis est la nouvelle version du protocole DMARC, en cours de finalisation à l'IETF comme Proposed Standard. Il remplace le RFC 7489 (2015) et le RFC 9091 (PSD DMARC). Les trois documents (mécanisme principal, rapports agrégés, rapports d'échec) sont dans la file d'attente de l'éditeur RFC depuis 2025.
Q : Quelles sont les différences entre DMARC et DMARCbis ?
R : DMARCbis ajoute trois nouveaux tags (np, t, psd), supprime trois tags (pct, rf, ri), remplace la découverte via Public Suffix List par un algorithme tree walk DNS, et restreint la validation SPF au MAIL FROM uniquement.
Q : Faut-il migrer vers DMARCbis immédiatement ?
R : Rien n'est urgent. Les enregistrements DMARC actuels continuent de fonctionner car la version reste v=DMARC1. Toutefois, il est recommandé de vérifier la compatibilité DMARCbis de ses enregistrements dès maintenant pour supprimer les tags obsolètes et ajouter les nouveaux tags np et psd avant l'adoption massive.
Q : Le tag pct est-il vraiment supprimé ?
R : Oui. L'expérience opérationnelle a montré que le tag pct était appliqué de manière inconsistante par les récepteurs. Seules les valeurs 0 et 100 étaient fiables. Il est remplacé par le tag binaire t (t=y pour le mode test, t=n pour l'application complète).
Q : Qu'est-ce que le tree walk DNS ?
R : Le tree walk DNS est l'algorithme de découverte de politique DMARC dans DMARCbis. Au lieu de consulter une Public Suffix List externe, le récepteur remonte l'arborescence DNS en interrogeant _dmarc à chaque niveau jusqu'à trouver un enregistrement valide. Cela élimine la dépendance à la PSL.
Q : Le tag fo est-il supprimé dans DMARCbis ?
R : Non. Le tag fo (failure reporting options) est conservé dans DMARCbis. Seuls les tags pct, rf et ri sont supprimés.
Q : Comment savoir si mon domaine est prêt pour DMARCbis ?
R : Lancez une analyse avec notre DMARCbis checker. L'outil effectue un tree walk DNS complet, détecte les tags obsolètes (pct, rf, ri), vérifie la présence du tag np et affiche le domaine organisationnel découvert. Le résultat indique un statut clair : conforme, compatible ou non conforme DMARCbis.
Q : Le tree walk DNS ralentit-il la livraison des emails ?
R : Non. Le tree walk effectue au maximum 8 requêtes DNS, et les récepteurs mettent les résultats en cache selon le TTL des enregistrements. En pratique, pour la plupart des domaines, le tree walk se résout en 2 ou 3 requêtes. L'impact sur le temps de livraison est négligeable.