Pourquoi migrer vers DMARCbis ?
DMARCbis succède à la RFC 7489 publiée en 2015. Le draft introduit quatre changements structurants :
- Suppression de
pct,rf,ri: la politique s'applique désormais à 100% du trafic, un seul format de rapport reste défini et l'intervalle de remontée est imposé par défaut. Le tagfoest conservé. - Ajout de
np: la politique des sous-domaines inexistants devient explicite, fermant une faille exploitée par les attaquants qui inventent des sous-domaines fictifs. - Conversion
pct<100ent=y: le mode test remplace le pourcentage. Plus simple, plus prévisible, plus aligné avec le comportement réel des récepteurs. - Tree walk DNS pour identifier le domaine organisationnel, en remplacement de la Public Suffix List.
L'enregistrement DMARC actuel continue de fonctionner pendant la transition. Migrer dès maintenant permet d'être prêt à la publication officielle et de bénéficier immédiatement de la protection des sous-domaines inexistants via np.
Comment fonctionne l'analyseur
L'outil parse votre enregistrement DMARC v1, applique les transformations DMARCbis et calcule un score de DMARCbis-compatibilité sur 100. Le calcul est local, sans résolution DNS ni appel externe.
Les cinq verdicts possibles
| Verdict | Score | Signification |
|---|---|---|
| Configuration déjà compatible | 90 à 100 | Aucun changement requis ou ajustement mineur. Surveillez la publication officielle du RFC. |
| Migration partielle | 75 à 89 | Une à trois modifications mineures (typiquement pct=100 redondant ou np absent). |
| Migration majeure | 50 à 74 | Quatre changements ou plus. Plusieurs tags dépréciés présents et politique faible. |
| Record invalide | 0 à 49 ou état invalide | Erreurs de syntaxe à corriger avant migration. |
| Aucun enregistrement | N/A | Champ vide. Collez d'abord un record DMARC avant l'analyse. |
Les six dimensions du score
| Dimension | Pondération | Ce que mesure la dimension |
|---|---|---|
| Tags dépréciés absents | 40 points | Présence de pct, rf, ri. Plus il y en a, plus la déduction est forte. |
Tag np présent | 15 points | Politique sous-domaines inexistants explicite. Hérite de sp ou p si absent. |
| Force de la politique | 20 points | reject rapporte le maximum, quarantine une fraction, none un crédit minimal. |
| Alignement DKIM et SPF | 10 points | adkim=s et aspf=s valent le maximum, r retient une partie. |
Reporting rua configuré | 10 points | URI mailto valide pour la remontée agrégée. |
| Hygiène syntaxique | 5 points | Record bien formé et parsable. |
Trois facteurs prioritaires sont affichés en tête de résultat pour expliquer immédiatement le score, avant le détail dimension par dimension.
Les changements clés DMARC vers DMARCbis
Tags supprimés
| Tag | Action | Pourquoi |
|---|---|---|
pct | Retirer | La politique s'applique à 100% par défaut. Si pct<100, l'outil convertit en t=y. |
rf | Retirer | Un seul format de rapport reste défini en DMARCbis. |
ri | Retirer | Les récepteurs imposent un intervalle de rapport par défaut. |
Tag ajouté
| Tag | Valeur | Pourquoi |
|---|---|---|
np | hérite de sp ou p | Politique pour les sous-domaines inexistants. Doit être explicite en DMARCbis. |
Tags conservés inchangés
v=DMARC1, p, sp, adkim, aspf, rua, ruf. Leur sémantique reste identique.
Plan de migration recommandé
Étape 1 : auditer le record actuel. Lancez l'analyse avec votre enregistrement DMARC publié. Notez le score, le verdict et les recommandations.
Étape 2 : appliquer les changements proposés. Copiez le record migré et publiez-le dans votre zone DNS à _dmarc.captaindns.com. Conservez l'ancien record pendant 48 heures via un TTL court (300 secondes) pour permettre un rollback rapide si nécessaire.
Étape 3 : surveiller les rapports rua. Pendant deux à quatre semaines, vérifiez vos rapports DMARC agrégés pour confirmer l'absence d'impact sur les flux légitimes. Le passage à np peut révéler des sous-domaines actifs non documentés.
Étape 4 : stabiliser le TTL. Une fois les rapports validés, repassez le TTL à 3600 ou 86400 secondes. La migration est terminée.
Si vous passez aussi d'une politique souple à p=reject, utilisez t=y pendant quelques semaines. Les récepteurs DMARCbis appliquent alors une politique un cran en dessous, ce qui sert de filet de sécurité pendant la phase de validation.
Erreurs courantes à éviter
Conserver pct=100. Cette valeur est redondante en DMARCbis. Le tag entier peut être supprimé sans modifier le comportement.
Confondre np et sp. sp cible les sous-domaines existants, np cible exclusivement les sous-domaines inexistants. Les deux tags sont complémentaires, pas interchangeables.
Combiner pct et t. En DMARCbis, t prend toujours précédence. Inutile de conserver pct quand t=y est présent.
Supprimer rua lors du nettoyage. Le reporting agrégé est la seule source de vérité sur l'efficacité de votre politique. Conservez rua=mailto:reports@captaindns.com (ou votre adresse dédiée) dans le record migré.
Migrer sans relire les rapports existants. Avant de durcir la politique, vérifiez quels expéditeurs légitimes ne sont pas encore alignés SPF ou DKIM. Une migration vers p=reject sans cette étape peut bloquer des flux internes.
Déclarer psd=y sans être un registre. Le tag psd=y est réservé aux opérateurs de suffixes publics comme .bank ou .gov.uk. Pour un domaine organisationnel classique, omettez le tag ou utilisez psd=n si vous voulez l'expliciter.
Outils complémentaires
| Outil | Utilité |
|---|---|
| DMARCbis Checker | Auditer un domaine publié contre DMARCbis avec Tree Walk DNS |
| DMARC Checker | Vérifier la publication et résoudre l'enregistrement DMARC depuis le DNS |
| DMARC Validator | Valider la syntaxe d'un record DMARC v1 avant publication |
| Générateur DMARC | Créer un enregistrement DMARC ou DMARCbis depuis zéro |
| Lecteur de rapports DMARC | Décoder les rapports agrégés XML |
| Monitoring DMARC | Recevez et analysez automatiquement vos rapports DMARC agrégés |