Déploiement de DMARC en détail

Une fois que vous comprenez ce que fait DMARC, faire passer un domaine à une politique contraignante sans risque demande de régler correctement de nombreux détails : l’ensemble des balises, la politique des sous-domaines, l’échantillonnage par pourcentage, la rigueur de l’alignement, le traitement des rapports, les scénarios d’échec courants et l’ordre du déploiement. Pour les notions, l’alignement et l’enregistrement de base, commencez par DMARC.

Les informations ci-dessous proviennent de dmarc.org, le site de référence de la spécification DMARC.

État de la spécification

Les principales évolutions des nouvelles RFC ne cassent pas les enregistrements existants, qui commencent toujours par v=DMARC1 :

• Balises supprimées : pct, rf et ri. pct a été supprimée parce que sa définition dans la RFC 7489 était ambiguë dès le départ (« pourcentage des messages du flux de courrier du propriétaire du domaine auxquels la politique DMARC doit être appliquée »).
• Nouvelles balises : np (politique des sous-domaines inexistants), psd (un indicateur pour les domaines de suffixe public) et t (un indicateur de test, qui remplace l’usage de type pct=0 pour « surveiller sans appliquer »).
• Découverte du domaine organisationnel : la Public Suffix List est remplacée par un DNS Tree Walk. Le serveur de réception interroge _dmarc.<author-domain>, puis _dmarc.<parent>, et ainsi de suite en remontant l’arborescence, dans la limite de huit requêtes.

La plupart des enregistrements déployés et des serveurs de réception utilisent encore la sémantique de la RFC 7489, et la référence des balises ci-dessous couvre donc les deux.

Référence complète des balises

Les enregistrements DMARC utilisent la syntaxe extensible balise-valeur empruntée à DKIM. Toutes les balises autres que v et p sont facultatives.

Exemple d’enregistrement :

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:postmaster@example.com"

Politique des sous-domaines (sp=)

Sans sp=, les sous-domaines héritent de la politique p= du domaine organisationnel. Publier sp= vous permet d’appliquer des règles différentes selon les parties de l’organisation, par exemple :

• p=none; sp=reject : le domaine apex est encore en surveillance, tandis que les messages qui usurpent des sous-domaines n’envoyant pas d’emails sont rejetés.
• p=reject; sp=none : l’apex est verrouillé pendant que les flux d’emails d’un sous-domaine sont encore en cours d’alignement. Les attaquants peuvent exploiter ce point faible, alors comblez-le dès que possible.

Pour être éligible à BIMI, les deux doivent être en politique contraignante : p=quarantine|reject, sans sp=none (voir BIMI). La RFC 9989 ajoute aussi np=, pour que les sous-domaines inexistants puissent être rejetés même lorsque les sous-domaines réels ont une politique plus souple.

Échantillonnage par pourcentage (pct=, RFC 7489)

pct définit le pourcentage des messages en échec auxquels la politique p= s’applique. Les messages restants reçoivent la politique immédiatement inférieure :

• p=reject; pct=60 signifie que 60 % du trafic en échec est rejeté et que 40 % est mis en quarantaine.
• p=quarantine; pct=25 signifie que 25 % est mis en quarantaine et que 75 % est traité comme none.

Ce réglage intégré permet une application progressive : augmentez pct par paliers à chaque niveau de politique, et surveillez les rapports avant d’atteindre 100. Avec la RFC 9989, pct n’existe plus. L’indicateur de test t=y couvre le cas où l’on publie l’intention d’appliquer une politique sans effet, et un déploiement progressif passe d’un niveau de politique au suivant.

Rigueur de l’alignement (adkim= / aspf=)

Les deux balises d’alignement acceptent :

• r (souple, par défaut) : le domaine authentifié (le d= de DKIM ou le RFC5321.MailFrom de SPF) doit seulement avoir le même domaine organisationnel que le domaine RFC5322.From. news.example.com est aligné avec example.com.
• s (strict) : les domaines doivent correspondre exactement.

Le mode souple est le bon choix par défaut pour presque tous les expéditeurs. Le mode strict s’adresse aux propriétaires de domaines qui veulent empêcher même des sous-domaines frères d’authentifier des messages les uns pour les autres, par exemple pour isoler des unités commerciales, ou pour se protéger d’un tiers compromis qui signe au nom d’un sous-domaine délégué. N’utilisez pas s avant que les rapports agrégés confirment que chaque flux légitime s’authentifie avec le domaine From exact.

Traitement des rapports

Rapports agrégés (rua=)

• Des documents XML, généralement produits chaque jour par chaque serveur de réception qui envoie des rapports. Attendez-vous aux premiers rapports 24 heures ou plus après la publication de l’enregistrement.
• Ils contiennent des décomptes pour chaque adresse IP source, avec les résultats bruts SPF et DKIM, l’évaluation de l’alignement et le traitement appliqué.
• Ils sont livrés compressés en gzip à des URI mailto:. Utilisez une boîte aux lettres dédiée et une analyse automatisée, jamais la boîte de réception d’une personne.
• C’est le jeu de données principal pour les décisions de déploiement. Il révèle toutes les sources qui utilisent votre domaine dans le RFC5322.From, y compris des tiers oubliés.

Rapports d’échec (ruf=)

• Envoyés immédiatement, pour chaque message en échec. Si le domaine est usurpé à grande échelle, leur volume « pourrait représenter plusieurs fois le volume de vos emails légitimes ».
• Ils permettent une analyse forensique de messages individuels, mais de nombreux serveurs de réception ne les envoient pas (pour des raisons de confidentialité), et ils exigent de prévoir la capacité nécessaire. Ne déployez ruf= qu’après avoir compris votre trafic grâce aux rapports agrégés, voire pas du tout.

Destinations de rapports externes

Si rua= ou ruf= pointe vers un autre domaine que celui qui publie l’enregistrement DMARC, les serveurs de réception vérifient que la destination est autorisée. Le domaine qui reçoit les rapports doit publier :

example.com._report._dmarc.thirdparty.com. IN TXT "v=DMARC1"

Cela signifie que thirdparty.com accepte de recevoir des rapports concernant example.com. Une forme générique (wildcard) accepte les rapports pour n’importe quel domaine, mais ouvre la porte aux abus :

*._report._dmarc.thirdparty.com. IN TXT "v=DMARC1"

Les services de traitement des rapports DMARC s’appuient sur ce mécanisme. C’est pourquoi faire pointer rua= vers l’adresse d’un prestataire fonctionne sans que ce prestataire contrôle votre DNS.

Outils

dmarc.org tient à jour des répertoires d’outils de déploiement et de code et bibliothèques. Les solutions commerciales de traitement des rapports sont recensées dans la rubrique produits et services.

• Générateurs et assistants d’enregistrement : dmarcian, EasyDMARC, DMARCLY, Fortra (Agari), Kitterman, Proofpoint, Global Cyber Alliance.
• Vérificateurs d’enregistrement : les mêmes éditeurs, plus Sendmarc, Valimail et Mimecast.
• Réflecteurs et validateurs de messages : autoreply@dmarctest.org, aboutmy.email, Red Sift Investigate.
• Code et bibliothèques : le milter OpenDMARC, Mail::DMARC en Perl, mail-auth en Rust, les scripts rddmarc pour l’analyse des rapports, dmarc-report-processor pour la conversion en CSV, et Lafayette pour le stockage des rapports, entre autres.

Scénarios d’échec courants

Transfert

Le transfert simple réécrit le RFC5321.MailFrom (ou conserve celui d’origine mais envoie depuis une nouvelle adresse IP), si bien que l’alignement SPF est perdu. DKIM ne résiste au transfert que si le service de transfert ne modifie pas le contenu signé. Ajouter de nouveaux en-têtes ne pose généralement pas de problème, mais modifier l’objet ou le corps casse la signature.

C’est l’une des principales raisons de s’authentifier avec les deux protocoles, et de s’appuyer avant tout sur un DKIM aligné. Un message dont la signature DKIM reste intacte passe DMARC après le transfert, même si SPF échoue.

Listes de diffusion

Les listes traditionnelles modifient les messages (étiquettes dans l’objet, pieds de page), ce qui casse DKIM, et les envoient depuis leur propre infrastructure, ce qui casse l’alignement SPF. Les messages postés depuis un domaine en p=reject rebondissent alors chez tous les abonnés. Les parades connues sont les suivantes :

La réécriture du From est ce que font aujourd’hui la plupart des grands logiciels de listes lorsque le domaine de l’auteur est en politique contraignante. Si vos utilisateurs publient sur des listes de diffusion, attendez-vous à ce comportement dès que vous dépasserez p=none.

Le chemin de déploiement : none, quarantine, reject

dmarc.org décrit pour les expéditeurs un processus de déploiement en cinq étapes :

1. Déployer DKIM et SPF sur chaque flux d’emails légitime : messagerie d’entreprise, plateforme marketing, CRM, système de facturation, service client, tous sans exception.
2. Garantir l’alignement : vérifier que les identifiants de chaque flux sont alignés avec le domaine RFC5322.From (le d= de DKIM et/ou le RFC5321.MailFrom).
3. Publier p=none, avec rua= pointant vers une boîte aux lettres ou un service de traitement de rapports dédié. Cela n’a aucun effet sur la livraison : vous ne faites que collecter des données.
4. Analyser les rapports et corriger les flux. Chaque source en échec est soit (a) un expéditeur légitime à aligner, soit (b) un abus que la politique contraignante arrêtera. Répétez jusqu’à ce que les rapports agrégés montrent que tout le courrier légitime passe.
5. Durcir : passer à p=quarantine, d’abord avec un échantillonnage pct faible (pour les serveurs de réception RFC 7489), et monter progressivement vers pct=100. Surveillez dans les rapports le courrier légitime mis en quarantaine. Quand il n’y en a plus, passez à p=reject, là encore en augmentant éventuellement pct par paliers.

Recommandations opérationnelles pour chaque phase :

• La phase p=none : prévoyez des semaines, pas des jours. Les expéditeurs tiers (facturation, RH, plateformes événementielles) apparaissent lentement dans les rapports, car certains envoient rarement.
• La phase p=quarantine : le courrier légitime en échec va dans le dossier spam au lieu de disparaître, si bien que les destinataires peuvent encore le récupérer. C’est ce filet de sécurité qui fait de la quarantaine l’étape intermédiaire obligatoire. Surveillez le trafic transféré et celui des listes de diffusion (voir plus haut), qui échouera par construction.
• La phase p=reject : n’y passez qu’une fois que les rapports agrégés ne montrent plus aucun message légitime mis en quarantaine. L’expéditeur voit un rejet (sous forme de rebond), ce qui aide à détecter les flux défaillants, mais tout ce qui vous a échappé est perdu.
• Pensez à sp= à chaque étape. Changer la politique de l’apex ne protège pas, et ne casse pas, les sous-domaines que vous avez exclus.

Une politique contraignante (quarantine ou reject à 100 %) est aussi la condition d’accès à BIMI.

Voir aussi

• DMARC, sur les notions, les bases de SPF et DKIM, l’alignement et l’enregistrement de base
• BIMI, l’affichage du logo, qui exige une politique DMARC contraignante
• Fondamentaux de la délivrabilité des emails