Déploiement de DMARC en détail

Cet article complète DMARC (notions, alignement, enregistrement de base) avec les détails opérationnels dont le propriétaire d’un domaine a besoin pour déployer DMARC sans risque : 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 le chemin vers une politique contraignante. Le contenu provient de dmarc.org, le site de référence de la spécification DMARC.

État de la spécification

Principales évolutions des nouvelles RFC (sans rupture : les enregistrements commencent toujours par v=DMARC1) :

• Balises supprimées : pct, rf, 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 (indicateur de domaine de suffixe public), t (indicateur de test, qui remplace l’usage de type pct=0, « 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.

Comme la sémantique de la RFC 7489 reste celle qu’utilisent la plupart des enregistrements déployés et des serveurs de réception, la référence des balises ci-dessous couvre 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= permet d’appliquer des règles différentes selon les niveaux de l’organisation, par exemple :

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

L’éligibilité à BIMI exige une politique contraignante sur les deux : p=quarantine|reject sans sp=none (voir BIMI). À noter : la RFC 9989 ajoute np= pour que les sous-domaines inexistants puissent être rejetés même lorsque les sous-domaines réels sont soumis à 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 sont traités avec la politique immédiatement inférieure :

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

Ce dosage 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 disparaît ; l’indicateur de test t=y couvre le cas « publier l’intention d’appliquer sans effet », et le déploiement progressif se fait en passant d’un niveau de politique à l’autre.

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

Les deux balises d’alignement acceptent :

• r (souple, par défaut) — le domaine authentifié (d= de DKIM ou 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 du courrier 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=)

• 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, par adresse IP source, des décomptes avec les résultats bruts SPF/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 (y compris des tiers oubliés) qui utilisent votre domaine dans le RFC5322.From.

Rapports d’échec (ruf=)

• Envoyés immédiatement, pour chaque message en échec : leur volume « pourrait représenter plusieurs fois le volume de vos emails légitimes » si le domaine est usurpé à grande échelle.
• Ils permettent une analyse forensique au niveau du message, mais de nombreux serveurs de réception ne les envoient pas (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=/ruf= pointent vers un autre domaine que celui qui publie l’enregistrement DMARC, les serveurs de réception vérifient l’autorisation. Le domaine qui reçoit les rapports doit publier :

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

(ce qui signifie : 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 cela 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 qu’il contrôle votre DNS.

Outils

dmarc.org tient à jour des répertoires d’outils de déploiement (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, Mimecast ; réflecteurs et validateurs de messages : autoreply@dmarctest.org, aboutmy.email, Red Sift Investigate) et de code et bibliothèques (milter OpenDMARC, Mail::DMARC en Perl, mail-auth en Rust, scripts d’analyse de rapports rddmarc, dmarc-report-processor pour la conversion en CSV, Lafayette pour le stockage des rapports, entre autres). Les solutions commerciales de traitement des rapports sont recensées dans la rubrique produits et services.

Scénarios d’échec courants

Transfert

Le transfert simple réécrit le RFC5321.MailFrom (ou réutilise celui d’origine depuis une nouvelle IP), de sorte que l’alignement SPF est perdu. DKIM ne résiste au transfert que si le service de transfert ne modifie pas le contenu signé : en général, ajouter de nouveaux en-têtes ne pose pas de problème ; toucher à l’en-tête Subject ou au corps casse la signature. C’est l’une des principales raisons de s’authentifier avec les deux protocoles et de faire reposer l’essentiel sur le 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. Parades connues :

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

Le processus de déploiement en cinq étapes proposé par dmarc.org aux expéditeurs :

1. Déployer DKIM et SPF sur chaque flux d’envoi 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 (d= de DKIM et/ou RFC5321.MailFrom).
3. Publier p=none avec rua= pointant vers une boîte aux lettres ou un service de traitement de rapports dédiés. 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 (serveurs de réception RFC 7489), en montant progressivement jusqu’à pct=100 ; surveiller dans les rapports le courrier légitime mis en quarantaine. Quand il n’y en a plus, passer à p=reject, là encore en augmentant éventuellement pct par paliers.

Recommandations opérationnelles pour chaque phase :

• Phase p=none : comptez des semaines, pas des jours. Les expéditeurs tiers (facturation, RH, plateformes événementielles) apparaissent lentement dans les rapports, car certains envoient rarement.
• Phase p=quarantine : le courrier légitime en échec atterrit 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.
• Phase p=reject : uniquement lorsque les rapports agrégés ne montrent plus aucun message légitime mis en quarantaine. Le rejet est visible par l’expéditeur (rebond), ce qui aide à détecter les flux défaillants, mais signifie aussi la perte du courrier pour tout ce qui vous aurait échappé.
• Pensez à sp= à chaque étape : une migration de politique sur l’apex ne protège pas (ni ne casse) 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 — notions, rappel sur SPF et DKIM, alignement, enregistrement de base
• BIMI — affichage du logo, qui exige une politique DMARC contraignante
• Fondamentaux de la délivrabilité des emails