DMARCbis : le guide complet pour les expéditeurs

Q: Quelle différence entre t=y et pct ?

pct demandait aux destinataires d’appliquer la politique à une part aléatoire des messages, ce qui était imprévisible. t=y indique que tout l’enregistrement est en test : les destinataires évaluent et envoient des rapports sans forcément appliquer la politique. Vous obtenez des données fiables avant de vous engager.

Ordinateur portable d’où s’envolent des emails, titre DMARCbis : l’avenir de l’authentification en 2026

DMARCbis est la révision IETF de DMARC (RFC 7489) : une évolution, pas une rupture. Le tag pct disparaît, les tags np (sous-domaine inexistant) et psd (Public Suffix Domain) font leur entrée, et le mode test t=y remplace le déploiement partiel. L’application par les fournisseurs de messagerie devrait s’étaler du T4 2026 à 2027. Auditez votre DMARC actuel et corrigez chaque échec avant de migrer.

Qu’est-ce que DMARCbis, et pourquoi c’est important

DMARCbis est la révision de DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) en cours à l’IETF. Elle clarifie les comportements ambigus, supprime des mécanismes obsolètes comme le tag pct, et encadre explicitement les Public Suffix Domains et les sous-domaines inexistants. Pour la plupart des expéditeurs, c’est une évolution plutôt qu’une révolution. Mais les redirecteurs légitimes, les listes de diffusion et les expéditeurs multi-sources complexes verront la différence.

De la RFC 7489 à DMARCbis

DMARC a été publié en 2015 sous forme de RFC informative. Ce n’était pas un document Standards-Track, mais la description d’un fonctionnement déjà en production, portée par de grands expéditeurs et fournisseurs de messagerie. Cette origine a laissé des zones floues : la découverte de la politique entre organisations, le traitement des sous-domaines inexistants, le fonctionnement réel du déploiement partiel. Avec DMARCbis, le groupe de travail de l’IETF fait de DMARC un vrai document Standards-Track, enrichi de dix ans de retours terrain.

La découverte de la politique était mal définie. La spécification d’origine s’appuyait sur la Public Suffix List, une ressource maintenue par la communauté et non un standard IETF. DMARCbis introduit une découverte explicite par remontée de l’arborescence (tree walk) et la gestion des PSD.
Le tag pct n’était pas fiable. Les destinataires appliquaient le déploiement partiel de façon incohérente. DMARCbis le supprime au profit d’un mode test clair : t=y.
Les sous-domaines inexistants étaient une faille d’usurpation. Les attaquants usurpent des sous-domaines qui n’ont jamais été prévus pour envoyer des emails. Le tag np leur fixe une politique explicite.

Qui est concerné, et quand

Expéditeur B2B, plus de 5 000 emails par jour, p=reject propre : urgence faible. Auditez et ajustez la syntaxe.
Expéditeur B2B en p=none ou p=quarantine : urgence moyenne. Planifiez une migration progressive.
Expéditeur multi-sources (ESP, transactionnel, outils) : urgence élevée. Un audit complet est recommandé.
ESP, hébergeur ou SaaS multi-tenant : critique. Vous devez maîtriser la politique PSD.
Opérateur de TLD, registre ou PSL : critique. La politique PSD est obligatoire.

Si votre DMARC est déjà en p=reject avec toutes vos sources alignées, DMARCbis se résume à une vérification de syntaxe. Si vous êtes bloqué en p=none, si vous envoyez depuis de nombreuses sources ou si vous gérez l’infrastructure des domaines d’autres entreprises, c’est le moment de remettre votre authentification en ordre. Les enregistrements existants restent valides : rien ne casse du jour au lendemain.

DMARC vs DMARCbis : ce qui change vraiment

DMARCbis garde le cœur intact (alignement SPF et DKIM, politique p=, rapports rua et ruf) et modifie les marges. En bref : pct et rf disparaissent, np, psd et t=y arrivent, et la découverte de la politique est désormais explicitement définie au lieu de reposer officieusement sur la Public Suffix List.

pct (pourcentage de messages) : supprimé.
rf (format de rapport) : supprimé, AFRF uniquement.
np (sous-domaine inexistant) : nouveau.
psd (Public Suffix Domain) : nouveau.
t=y (mode test) : nouveau, remplace pct.
Découverte de la politique : domaine organisationnel, plus remontée explicite de l’arborescence et recherche PSD.
Redirections et listes de diffusion : clarifiées, avec ARC recommandé.
Alignement, rapports, rétrocompatibilité : inchangés. Les enregistrements existants restent valides.

Ce qui disparaît

Le tag pct. Avec DMARC, pct=10 demandait aux destinataires d’appliquer la politique à environ 10 % des messages. Il était appliqué de façon incohérente et servait souvent de béquille pour éviter l’application complète. Le déploiement progressif passe désormais par le mode test et les politiques de sous-domaines, bien plus prévisibles.

Le tag rf. Il permettait en théorie de choisir le format des rapports forensiques, mais tout le monde utilisait AFRF : le tag n’apportait aucune information utile.

Ce qui arrive

Le tag psd. Un Public Suffix Domain est un domaine sous lequel des organisations indépendantes enregistrent leurs noms : .com, .co.uk, ou une plateforme où chaque client reçoit un sous-domaine. DMARCbis permet à l’opérateur de publier une politique qui protège cette frontière. C’est essentiel pour les opérateurs de TLD, les registres et les SaaS multi-tenant, et c’était impossible avec la RFC 7489.

Le tag np. Il fixe la politique des sous-domaines qui n’existent pas dans le DNS, ceux que seul un attaquant utiliserait. Vous pouvez garder p=none tout en passant np=reject : la faille est fermée sans toucher aux emails légitimes de vos vrais sous-domaines. Il complète sp, qui s’applique aux sous-domaines existants.

Le mode test, t=y. Il indique que l’enregistrement est en phase de test : les destinataires évaluent et envoient des rapports, sans forcément appliquer la politique. Vous pouvez ainsi valider une nouvelle politique sur de vrais rapports agrégés avant de vous engager. C’est le rôle que pct remplissait mal.

Calendrier : quand DMARCbis devient le standard

En 2026, DMARCbis est encore un draft IETF, en phase finale au sein du groupe de travail. Il n’y a pas de date butoir comme pour les exigences Gmail et Yahoo de février 2024. Le support par les fournisseurs de messagerie devrait arriver progressivement, du T4 2026 à 2027 et 2028. Préparez-vous dès maintenant, sans céder à la panique.

2026 : le draft est finalisé, les éditeurs d’outils ajoutent la lecture DMARCbis. Les expéditeurs auditent et font le ménage.
2027 : publication probable de la RFC, les destinataires commencent à prendre en compte np et psd. Les expéditeurs passent en mode application.
2028 : le comportement DMARCbis devient la norme, et les expéditeurs encore en p=none voient leur placement se dégrader.

Gmail, Yahoo et Microsoft ont participé à l’écriture de DMARC et prennent part à DMARCbis : l’adoption est attendue, mais elle sera progressive et discrète. À faire maintenant : auditer votre DMARC, recenser toutes vos sources d’envoi, corriger les échecs d’alignement, ajouter la protection np. À garder pour plus tard : tout ce qui dépend d’un support universel de psd par les destinataires, sauf si vous êtes vous-même opérateur de PSD.

Ce que DMARCbis change pour la délivrabilité

DMARCbis n’ajoute pas de nouveau filtre antispam. Il renforce la couche d’authentification sur laquelle les filtres s’appuient déjà : l’impact est indirect, mais bien réel. Une découverte de la politique plus claire et un traitement explicite des sous-domaines inexistants réduisent l’usurpation et protègent la réputation de votre domaine. À l’inverse, une migration bâclée casse l’alignement et envoie vos emails légitimes en spam.

Une découverte de la politique plus stricte. Grâce à la remontée explicite de l’arborescence, les destinataires trouvent et appliquent plus sûrement la bonne politique organisationnelle. Si des sous-domaines héritent d’une politique non prévue, leurs emails peuvent être mis en quarantaine ou rejetés. Cartographiez vos envois par sous-domaine avant de passer en application.
Protection des sous-domaines inexistants. np=reject empêche les attaquants d’usurper les sous-domaines que vous n’utilisez jamais. Un gain de réputation rapide et sans risque.
Redirections et listes de diffusion. Une redirection casse SPF et parfois DKIM : des emails attendus échouent. DMARCbis recommande ARC, qui permet à un redirecteur de confiance d’attester l’authentification d’origine. Validez ARC avant de passer en application si votre audience passe beaucoup par des listes.
Rapports. Les rapports agrégés restent la colonne vertébrale du dispositif. Vérifiez que votre outil d’analyse comprend les nouveaux tags au lieu de les ignorer.

Les pièges classiques : passer en application avant d’avoir corrigé tous les échecs ; oublier une source d’envoi ; passer np=reject alors que de vrais emails partent d’un sous-domaine mal déclaré dans le DNS ; supposer que tous les destinataires supportent déjà les nouveaux tags.

Étape par étape : migrer de DMARC vers DMARCbis

Le déroulé : audit, inventaire des sources, correction des échecs, mise à jour de la syntaxe, mode test pendant 30 à 60 jours, application, suivi, documentation. Ne passez jamais en application avant d’avoir corrigé les échecs.

1. Auditez votre configuration DMARC actuelle

Récupérez votre enregistrement _dmarc, notez la politique et collectez deux à quatre semaines de rapports agrégés. L’erreur classique : juger sa situation sur le seul enregistrement. Comptez un à deux jours, plus la période de collecte des rapports.

2. Recensez toutes vos sources d’envoi

Listez chaque système qui envoie au nom de votre domaine (ESP, plateforme transactionnelle, CRM, facturation, automatisation, support client) et vérifiez que chacun est déclaré dans SPF et signe en DKIM, avec alignement. Les rapports agrégés révèlent les sources que tout le monde a oubliées. Comptez deux à quatre jours.

3. Corrigez tous les échecs DMARC avant de migrer

Corrigez SPF (restez sous les dix requêtes DNS, aplatissez si besoin), publiez ou réparez DKIM avec des clés 2048 bits, et alignez chaque source. L’erreur classique : traiter les symptômes au lieu d’aligner la source. Comptez une à trois semaines.

4. Mettez à jour la syntaxe de votre enregistrement

Supprimez pct= et rf=, ajoutez np= pour protéger les sous-domaines inexistants, et n’ajoutez psd=y que si vous opérez réellement un public suffix domain. Moins d’une journée de travail.

5. Testez en mode t=y pendant 30 à 60 jours

Publiez avec t=y, surveillez les échecs dans les rapports agrégés et ajustez. L’erreur classique : écourter la période de test.

6. Passez en application, de quarantine à reject

Passez de none ou du mode test à p=quarantine, surveillez, puis passez à p=reject. Faites évoluer np et sp en parallèle. Ne sautez pas directement à reject. Comptez deux à quatre semaines, par paliers.

7. Surveillez avec un outil d’analyse compatible DMARCbis

Continuez à lire les rapports agrégés, soyez alerté dès qu’une nouvelle source échoue, et surveillez l’évaluation de np et des frontières PSD. Le suivi ne s’arrête pas une fois la politique appliquée.

8. Documentez et maintenez

Consignez chaque source, son responsable et ses entrées DNS, puis planifiez une revue trimestrielle. L’erreur classique : personne n’est responsable de la délivrabilité.

Syntaxe d’un enregistrement DMARCbis, avec exemples

Un enregistrement DMARCbis ressemble presque trait pour trait à un enregistrement DMARC, et les enregistrements existants restent valides. Les différences : les tags pct et rf disparaissent, np, psd et t=y arrivent.

Enregistrement minimal, en mode test

_dmarc.example.com. IN TXT "v=DMARC1; p=none; t=y; rua=mailto:dmarc@example.com"

Le point de départ le plus sûr : aucune application, mode test activé et une adresse de réception des rapports. Pendant le test, mieux vaut définir explicitement np=none et sp=none, pour que les rapports montrent ce qui se passerait avant de durcir quoi que ce soit.

Prêt pour la quarantaine

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; np=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com"

Application complète

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com; fo=1"

Politique PSD, pour un opérateur de TLD ou de PSL

_dmarc.example.tld. IN TXT "v=DMARC1; p=none; psd=y; rua=mailto:psd-reports@example.tld"

N’utilisez psd=y que si vous opérez réellement un public suffix. DMARCbis étant encore un draft, les enregistrements qui utilisent ces tags sont compatibles avec l’avenir : les fournisseurs qui ne les supportent pas encore les ignorent. Déployer np dès aujourd’hui ne présente donc aucun inconvénient.

Outils et suivi

DMARCbis se gère comme DMARC : on publie un enregistrement, on collecte les rapports agrégés, on agit en conséquence. Seule nouveauté : il faut un outil d’analyse qui comprend np, psd et t=y. Les grandes plateformes ajoutent ce support à mesure que le draft se stabilise. Demandez à votre fournisseur si les nouveaux tags sont bien remontés ou ignorés sans prévenir.

Les rapports agrégés sont des synthèses XML par source. Lisez-les pour repérer les sources qui échouent à l’alignement, le volume par source, et l’évaluation des sous-domaines inexistants et des frontières PSD. Un rapport propre montre chaque source légitime valide en SPF ou en DKIM, avec alignement. Les rapports forensiques donnent le détail message par message, mais peu de fournisseurs les envoient, pour des raisons de confidentialité : voyez-les comme un bonus, pas comme votre signal principal.

Moins de 5 000 messages par jour : revue hebdomadaire.
De 5 000 à 100 000 par jour : revue quotidienne.
Plus de 100 000 par jour : revue quotidienne, avec alertes automatiques.

Quand faire appel à un expert en délivrabilité

La plupart des expéditeurs en bonne santé, avec une seule source, peuvent migrer avec ce guide. Faites-vous accompagner quand la complexité, votre rôle dans l’infrastructure ou des échecs inexpliqués augmentent le coût d’une erreur. Une mise en application ratée rejette de vrais emails et abîme votre réputation pendant des semaines.

Vous avez au moins trois sources d’envoi distinctes et vous n’êtes pas sûr qu’elles soient toutes alignées.
Votre DMARC est en p=none et vous n’êtes jamais passé en application.
Vous êtes ESP, hébergeur ou SaaS multi-tenant : la politique PSD vous concerne et une erreur aurait un impact très large.
Vos rapports montrent des échecs que vous ne comprenez pas.

Un audit de préparation MailSoar comprend la revue complète de votre authentification (SPF, DKIM, DMARC, ARC et alignement), la cartographie de toutes vos sources d’envoi, l’analyse des causes des échecs remontés dans les rapports, une stratégie np, psd et t=y adaptée à votre configuration, et un plan de migration par paliers avec un guide de suivi.

Un cas récent. Un SaaS B2B qui envoyait depuis cinq sources était resté deux ans en p=none, par peur de bloquer ses emails de facturation. L’audit a cartographié les cinq sources et en a trouvé deux non alignées : une plateforme de facturation et un outil de support. Après correction de l’alignement et 45 jours en mode test, le domaine est passé en p=reject sans perdre un seul email légitime, et les tentatives d’usurpation sont tombées à zéro dans les rapports.

FAQ DMARCbis

Qu’est-ce que DMARCbis, en termes simples ?

La nouvelle version de DMARC, le standard d’authentification email qui indique aux destinataires quoi faire des emails qui échouent à SPF et DKIM. Elle supprime un tag peu fiable (pct), ajoute une protection pour les sous-domaines inexistants (np) et les public suffix domains (psd), et clarifie la découverte de la politique. Les enregistrements existants continuent de fonctionner.

Quand DMARCbis remplacera-t-il officiellement DMARC ?

Il n’y a pas de date fixe. C’était un draft IETF avancé en 2026, une RFC Standards-Track est probable en 2027, et les fournisseurs de messagerie devraient l’appliquer progressivement en 2027 et 2028.

DMARCbis est-il rétrocompatible ?

Oui. Les enregistrements existants restent valides et les destinataires ignorent les tags qu’ils ne reconnaissent pas : vous pouvez déployer np dès aujourd’hui, sans inconvénient.

Dois-je migrer en 2026 ?

Rien ne presse, mais préparez-vous : auditez votre DMARC, corrigez les échecs, ajoutez np. Les ESP et les plateformes multi-tenant doivent se pencher dès maintenant sur la politique PSD.

Qu’est-ce que le tag np ?

Il fixe la politique des sous-domaines inexistants : des noms absents du DNS que des attaquants pourraient usurper. Vous pouvez passer np=reject tout en gardant p=none, et fermer cette faille avec un risque très faible.

Qu’est-ce qu’un PSD ?

Un Public Suffix Domain est un domaine sous lequel des entités indépendantes enregistrent leurs noms, comme .com ou le domaine d’une plateforme multi-tenant. Le tag psd permet à l’opérateur de publier une politique de protection, un enjeu clé pour les registres, les opérateurs de TLD et les hébergeurs SaaS.

Qu’est devenu le tag pct ?

Il a été supprimé. Les destinataires l’appliquaient de façon incohérente et les expéditeurs s’en servaient pour éviter l’application complète. Le déploiement progressif passe désormais par le mode test t=y.

Quelle différence entre t=y et pct ?

pct demandait aux destinataires d’appliquer la politique à une part aléatoire des messages, ce qui était imprévisible. t=y indique que tout l’enregistrement est en test : les destinataires évaluent et envoient des rapports sans forcément appliquer la politique. Vous obtenez des données fiables avant de vous engager.

DMARCbis va-t-il casser mes listes de diffusion ?

Pas en soi. Mais les listes et les redirections cassent SPF, et parfois DKIM, ce qui provoque des échecs. DMARCbis recommande ARC pour y remédier. Validez ARC avant de passer en application si votre audience passe beaucoup par des listes.

Gmail supporte-t-il déjà DMARCbis ?

Google participe au processus et applique déjà les règles de 2024 pour les expéditeurs en masse. Le support complet arrivera progressivement, sans grande annonce, à mesure que la RFC sera finalisée.

Puis-je publier un enregistrement DMARCbis si mon fournisseur ne le supporte pas ?

Oui. Les nouveaux tags sont compatibles avec l’avenir et les destinataires qui ne les supportent pas les ignorent : déployer np dès maintenant est un gain sans risque.

Combien de temps rester en mode test ?

Trente à soixante jours pour la plupart des expéditeurs : assez pour couvrir toutes vos sources et les cas particuliers avant de passer en application.

DMARCbis impose-t-il ARC ?

Non, mais il le recommande fortement pour les redirecteurs légitimes et les listes de diffusion, car ARC conserve le résultat d’authentification d’origine d’un intermédiaire à l’autre.

Pour aller plus loin

Sources externes : le draft IETF draft-ietf-dmarc-dmarcbis, la RFC 7489 pour le DMARC d’origine, la documentation Google Postmaster Tools et les recommandations DMARC du M3AAWG.

Prêt à préparer votre domaine ? Si vous vous reconnaissez (bloqué en p=none, plusieurs sources d’envoi, un rôle d’ESP ou d’hébergeur, des échecs inexpliqués), un diagnostic gratuit de 30 minutes vous apporte une revue en direct de SPF, DKIM et DMARC, l’identification des sources non alignées, une stratégie np, psd et t=y, et un plan par paliers jusqu’à l’application. Réservez votre diagnostic.