Migration DMARC vers DMARCbis

Guide de migration DMARC vers DMARCbis

Pourquoi migrer ?

La migration de DMARC vers DMARCbis n'impose aucune date limite. Vos enregistrements DMARC actuels continuent de fonctionner. Cependant, utiliser un outil de migration permet de :

• Protéger les sous-domaines inexistants avec le tag np, fermant une faille exploitée par les attaquants
• Simplifier la gestion en supprimant les tags ignorés par les récepteurs modernes
• Déclarer votre périmètre organisationnel avec psd=n, clarifiant la hiérarchie DNS pour les récepteurs

Étapes de migration

1. Supprimer les tags obsolètes

2. Ajouter le tag np

Choisissez une politique pour les sous-domaines inexistants :

• np=reject : recommandé si p=reject (protection maximale)
• np=quarantine : approche intermédiaire
• np=none : monitoring uniquement

Si np est absent, la politique de sp s'applique (puis celle de p).

3. Évaluer le tag t

• Si vous utilisez actuellement pct=0 pour le mode test, passez à t=y
• Si votre politique est pleinement appliquée, aucune action requise (le défaut t=n est équivalent)
• Ne combinez pas pct et t : t prend toujours précédence

4. Déclarer psd si pertinent

• Domaine organisationnel (captaindns.com) : psd=n déclare que vous n'êtes pas un suffixe public
• Registre (.bank, .gov.uk) : psd=y permet la publication d'une politique pour tous les registrants
• Par défaut : psd=u (indéterminé), le tree walk DNS détermine le domaine organisationnel

Exemple de migration

Avant :

v=DMARC1; p=reject; sp=quarantine; pct=100; ri=86400; rua=mailto:dmarc@captaindns.com

Après :

v=DMARC1; p=reject; sp=quarantine; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Modifications :

• pct=100 supprimé (équivalent au défaut t=n)
• ri=86400 supprimé (ignoré par les récepteurs)
• np=reject ajouté (protection des sous-domaines inexistants)
• psd=n ajouté (déclaration du périmètre organisationnel)

Exemples concrets de migration

Voici trois scénarios représentatifs que vous pouvez rencontrer lors de la migration de votre enregistrement DMARC vers DMARCbis.

Scénario 1 : enregistrement avec pct partiel

Avant :

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com

Après :

v=DMARC1; p=quarantine; t=y; np=quarantine; rua=mailto:dmarc@captaindns.com

La valeur pct=50 signifie que la politique n'était appliquée qu'à la moitié des messages. En DMARCbis, cette approche granulaire disparait au profit d'un mode binaire. Le tag t=y active le mode test : les récepteurs DMARCbis appliquent la politique un cran en dessous (quarantine devient none). Le tag np=quarantine hérite de la politique p pour protéger les sous-domaines inexistants.

Scénario 2 : enregistrement strict sans tags obsolètes

Avant :

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@captaindns.com

Après :

v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Cet enregistrement est déjà propre : aucun tag obsolète à supprimer. Il suffit d'ajouter np=reject pour couvrir les sous-domaines inexistants et psd=n pour déclarer que le domaine n'est pas un suffixe public. La migration se fait en ajoutant deux tags sans modifier la politique existante.

Scénario 3 : enregistrement avec tous les tags obsolètes

Avant :

v=DMARC1; p=reject; pct=100; ri=86400; rf=afrf; rua=mailto:dmarc@captaindns.com

Après :

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@captaindns.com

Ici, trois tags obsolètes sont supprimés d'un coup. pct=100 correspond au comportement par défaut (application complète), donc aucun tag t n'est nécessaire. ri=86400 n'a jamais influencé la fréquence réelle des rapports. rf=afrf était la seule valeur possible, désormais implicite. Le tag np=reject est ajouté pour la protection complète.

Que se passe-t-il pendant la transition ?

La période de transition entre DMARC et DMARCbis ne présente aucun risque pour votre délivrabilité. Voici pourquoi :

• Tags inconnus ignorés : les récepteurs qui ne supportent pas encore DMARCbis ignorent simplement les tags np, t et psd. Ils continuent d'appliquer les tags p, sp et rua comme avant.
• La version reste v=DMARC1 : DMARCbis ne change pas l'identifiant de version. Aucun récepteur ne rejettera votre enregistrement à cause de la mise à jour.
• Le tag t en pratique : un récepteur DMARCbis applique le mode test si t=y est présent. Un récepteur DMARC v1 ne reconnait pas t et applique directement la politique p à 100%. Cela signifie que pendant la transition, vos emails bénéficient du niveau de protection le plus élevé des deux standards.
• Adoption progressive : les grands fournisseurs (Google, Microsoft, Yahoo) adoptent les nouvelles spécifications graduellement. La coexistence des deux comportements est prévue pour durer plusieurs années.
• Aucune action urgente requise : vos enregistrements DMARC actuels restent fonctionnels. La migration peut se faire à votre rythme, sans fenêtre de maintenance ni interruption de service.

Stratégie de déploiement recommandée

Pour migrer en toute sécurité, suivez ces quatre étapes dans l'ordre :

Étape 1 : Auditer l'enregistrement actuel. Utilisez notre DMARCbis Checker pour analyser votre enregistrement DMARC publié. L'outil identifie les tags obsolètes et évalue la conformité DMARCbis.

Étape 2 : Supprimer les tags obsolètes. Retirez pct, rf et ri de votre enregistrement. Ces tags n'ont plus d'effet dans DMARCbis et leur présence alourdit inutilement votre configuration DNS.

Étape 3 : Ajouter les nouveaux tags. Ajoutez np=reject (ou la politique de votre choix) pour protéger les sous-domaines inexistants. Ajoutez psd=n pour déclarer explicitement votre périmètre organisationnel. Ces deux ajouts renforcent votre posture de sécurité email sans modifier la politique principale.

Étape 4 : Tester avant d'appliquer. Si vous passez d'une politique souple (none ou quarantine) à une politique stricte (reject), utilisez t=y pendant quelques semaines. Surveillez vos rapports agrégés DMARC pour vérifier qu'aucun flux légitime n'est impacté. Une fois les rapports validés, retirez le tag t (le défaut t=n applique la politique intégralement).

Erreurs courantes à éviter

Oublier de désactiver le mode test. Le tag t=y est utile pendant la phase de validation, mais il réduit volontairement le niveau de protection. Programmez un rappel pour passer à t=n (ou supprimer le tag) après votre période de test.

Confondre np et sp. Le tag sp définit la politique pour les sous-domaines existants. Le tag np cible exclusivement les sous-domaines inexistants, ceux que les attaquants inventent pour contourner les protections. Les deux tags ont des rôles distincts et complémentaires.

Supprimer le tag rua par mégarde. Lors du nettoyage de l'enregistrement, veillez à conserver le tag rua qui pointe vers votre adresse de rapports agrégés. Sans reporting, vous perdez toute visibilité sur les tentatives d'usurpation et les problèmes d'alignement.

Déclarer psd=y sans être un registre. Le tag psd=y est réservé aux registres de suffixes publics (comme .bank ou .gov.uk). Si vous êtes propriétaire d'un domaine organisationnel classique, utilisez psd=n. Une déclaration erronée pourrait envoyer un signal incorrect aux récepteurs et compliquer le tree walk DNS.

Migrer sans consulter les rapports existants. Avant de modifier votre enregistrement, analysez vos rapports DMARC agrégés récents. Ils révèlent quels expéditeurs légitimes ne sont pas encore alignés SPF ou DKIM. Migrer sans cette vérification risque de bloquer des flux email légitimes lors du passage à une politique plus stricte.

Outils complémentaires

Avant de migrer, vérifiez la compatibilité DMARCbis actuelle de votre domaine avec le DMARCbis Checker. Le checker effectue une analyse tree walk DNS complète et détecte tous les tags obsolètes.

Pour un audit DMARC complet, explorez ces outils :

• Validateur DMARC pour valider la syntaxe de votre enregistrement DMARC
• Inspecteur DMARC pour consulter et analyser l'enregistrement DMARC publié sur votre domaine
• Générateur DMARC pour créer un nouvel enregistrement DMARC
• Lecteur de rapports DMARC pour décoder les rapports agrégés XML

En savoir plus sur les changements du protocole : DMARCbis : tous les changements et comment se préparer.