DMARCbis est désormais une proposition de norme (Proposed Standard) de l'IETF. Il remplacera RFC 7489 et RFC 9091. Vos enregistrements existants continuent d'utiliser v=DMARC1.
Commencez à planifier dès maintenant pour être prêt à adopter DMARCbis dès sa publication.
Qu'est-ce que DMARCbis : petit rappel
L'objectif de DMARCbis reste inchangé. Il vous permet de spécifier quelles sources d'envoi utilisant votre domaine sont légitimes et comment les destinataires doivent traiter les messages qui échouent à ces vérifications. La mise à jour clarifie la spécification, formalise la conformité et modifie la méthode de détermination du domaine organisationnel en utilisant une recherche arborescente DNS (Tree Walk) à la place de la Public Suffix List.
Ce qui change concrètement, et les avantages pour les domaines complexes :
- Recherche et alignement plus clairs : Les destinataires recherchent un enregistrement DMARC au niveau de l'Author Domain, puis de l'Organisation Domain, puis du Public Suffix Domain. DMARCbis définit la Tree Walk utilisée pour la découverte des stratégies et l’alignement.
- Fin de la Public Suffix List (PSL), place à la Tree Walk : La Tree Walk va remplacer les vérifications PSL, ce qui permet de définir des limites cohérentes, même avec des sous-domaines imbriqués et les enregistrements PSD.
- Conformité explicite : Une participation totale à DMARC suppose de publier des enregistrements pour chaque Author et Organisation Domain, d'envoyer des emails alignés via SPF et DKIM, et de consommer les rapports agrégés.
- Mieux adapté aux DNS décentralisés : Les enregistrements peuvent être publiés à plusieurs niveaux. Pour des noms d'hôte très profonds, ajoutez un enregistrement au niveau de l'Author Domain pour qu'il soit trouvé avant la Tree Walk.
Vos mises à jour sont dans les tags
Utilisez le tableau ci-dessous pour passer de l'ancien au nouveau : mettez [t] pour les tests, utilisez [np] si vous souhaitez une règle pour les noms inexistants, définissez [psd] uniquement si vous gérez un public suffix, retirez [pct], [rf], [ri], et gardez [v=DMARC1].
Aperçu des tags
Tag | Signification simple | Quand l'utiliser | Options | Exemple |
[t] | Signal de mode test pour la politique définie dans p, sp ou np | Activez-le lors des tests ; désactivez-le pour le fonctionnement normal | [y] test activé, n'appliquez pas la politique spécifiée mais appliquez toutes les règles de gestion spéciales | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com |
[psd] | Indique qu'un enregistrement est publié par un opérateur de Public Suffix et guide la Tree Walk | À définir uniquement si vous gérez un Public Suffix Domain (registre ou équivalent). La plupart des domaines n'auront pas besoin de ce tag explicitement | [y] = le domaine est un PSD [n] = le domaine n'est pas un PSD | v=DMARC1; p=quarantine; psd=y; rua=mailto:dmarc@example.com |
[np] | Politique pour les courriels utilisant des noms inexistants sous votre domaine | À utiliser si vous souhaitez une règle explicite pour les sous-domaines faux ou erronés | [none], [quarantine], [reject] | v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com |
[rf], [ri] | Anciennes indications pour le format des rapports de défaillance et l'intervalle des rapports agrégés | À supprimer des anciens enregistrements | - | - |
[pct] | Ancien contrôle du déploiement progressif par pourcentage | Remplacez par [t] pour les tests, ne pas utiliser dans les nouveaux enregistrements | - | Voir ci-dessous |
Préparez-vous pour DMARCbis avec Red Sift OnDMARC
[Pct] -> [t] correspondance
- [pct=0] -> utiliser [t=y]
- [pct=100] -> omettre le tag, inutile de déclarer t=n explicitement
- [pct=1-99] -> pas d’équivalent direct ; utilisez [t=y] et gérez le risque pendant la phase de test (par exemple sur des domaines à faible impact).
Mise à jour des enregistrements DMARCbis : 5 vérifications rapides
1. Trouvez vos enregistrements
Listez l'enregistrement DMARC de votre Organisation Domain ainsi que ceux de vos sous-domaines clés. Notez tout tag hérité : pct, rf ou ri. Ces tags sont maintenant dépréciés dans DMARCbis.
2. Mettez à jour la syntaxe des tags
Si vous n’êtes pas encore à pct=100, remplacez pct par le nouveau flag de test t. pct égal à zéro correspond à t égal à y. Si vous êtes à pct=100, vous pouvez retirer le tag pct. Supprimez rf et ri. Laissez psd de côté sauf si vous gérez réellement un public suffix domain. Gardez v égal à DMARC1.
3. Définissez la portée de la politique
Décidez de la valeur de p pour le domaine de base et de sp pour les sous-domaines. Ajoutez np si vous souhaitez une règle pour les messages destinés à des noms inexistants, par exemple np = reject. Si np est absent, les serveurs consultent d’abord sp puis p.
4. Choisissez les modes d’alignement
Utilisez adkim et aspf. (r signifie « relaxé » et s signifie « strict »). Choisissez strict si vous souhaitez des correspondances exactes entre le domaine d'authentification et le domaine From.
5. Vérifiez la génération de rapports
Gardez rua pour les rapports agrégés. Utilisez ruf avec fo uniquement si vous avez besoin du détail des échecs par message. Beaucoup de destinataires n’envoient pas de rapports d’échec et certains les refusent pour des raisons de confidentialité. Prévoyez cela.
Pourquoi Red Sift OnDMARC ?
DMARCbis change la façon dont la politique est trouvée et les tags à utiliser. Red Sift OnDMARC le prend en charge nativement, reliant DMARC, SPF et DKIM pour que vous puissiez appliquer la mise à jour rapidement.
- Un seul endroit pour DMARC, SPF, DKIM - Modifiez les enregistrements en parallèle, visualisez les résultats d'alignement [adkim/aspf] et corrigez ce qui bloque l’application de la politique.
- Conçu pour la Tree Walk - Visualisez le nœud que la walk atteindra (Author -> Org -> PSD) et où publier pour les sous-domaines profonds.
- Mise à jour des tags étape par étape - Utilisez [t], [np], [psd] ; retirez [pct], [rf], [ri] ; conservez [v=DMARC1]. L’outil vous guide à chaque étape.
- SPF à grande échelle - Le SPF dynamique gère la limite des 10 consultations grâce à un seul include qui s’étend dynamiquement lors des requêtes.
- Déploiement plus sûr - Modélisez, ne faites pas (one level softer) [t=y] avant d’aller en production, puis appliquez les changements en masse sur toutes vos marques et régions.
- Rapports clairs - Les vues agrégées mettent en évidence les problèmes d’alignement par source afin de faciliter leur résolution.
Contactez notre équipe pour un examen rapide de vos enregistrements et lancez un contrôle Investigate gratuit pour voir ce que les destinataires signalent pour votre domaine.




