Déployer DMARC à grande échelle

DMARC fait partie de ces technologies qui semblent simples sur le papier — publiez un enregistrement TXT DNS, c’est fait — puis qui finissent par consommer des semaines de votre vie à mesure que vous découvrez chaque façon obscure dont un email peut être envoyé depuis votre domaine. J’ai passé la majeure partie d’un mois à déployer DMARC sur une plateforme avec des dizaines de domaines, des centaines de milliers d’emails quotidiens, et toutes les combinaisons possibles de Google Workspace, AWS SES, relais Postfix et services tiers. Voici tout ce que j’ai appris.

Ceci n’est pas un aperçu « qu’est-ce que DMARC ». C’est le guide de terrain — la théorie nécessaire pour comprendre pourquoi les choses cassent, les étapes pratiques pour les corriger, et les pièges qu’aucune RFC ne vous signalera.

Les trois piliers : SPF, DKIM et DMARC

L’authentification email repose sur trois protocoles, chacun résolvant un aspect différent du problème de confiance. Comprendre comment ils interagissent — et où ils divergent — est la base de tout le reste.

SPF : qui est autorisé à envoyer

SPF (Sender Policy Framework, RFC 7208) permet à un domaine de déclarer quelles adresses IP sont autorisées à envoyer du courrier en son nom. C’est un enregistrement TXT DNS à l’apex du domaine :

v=spf1 include:_spf.google.com include:amazonses.com ip4:107.21.203.170 -all

Quand un serveur de réception reçoit un email, il vérifie l’ expéditeur d’enveloppe (le MAIL FROM dans la transaction SMTP, pas l’en-tête From que l’utilisateur voit) et consulte l’enregistrement SPF de ce domaine. Si l’IP d’envoi correspond, SPF passe.

SPF a une limitation critique : il vérifie l’ expéditeur d’enveloppe, pas l’en-tête From. Ces deux valeurs sont souvent différentes. Un service d’email transactionnel peut utiliser bounce-id@ses.example.com comme expéditeur d’enveloppe alors que l’en-tête From indique noreply@votreentreprise.com. SPF passe pour ses.example.com, mais ce n’est pas votre domaine — donc ça n’aide pas pour l’alignement DMARC (on y revient bientôt).

DKIM : preuve cryptographique d’origine

DKIM (DomainKeys Identified Mail, RFC 6376) adopte une approche différente : le serveur d’envoi signe les messages sortants avec une clé privée, et le serveur de réception vérifie la signature à l’aide d’une clé publique publiée en DNS.

selector._domainkey.example.com TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkq…”

La signature couvre certains en-têtes (From, Subject, Date, etc.) et le hash du corps. Elle est incluse sous forme d’en-tête DKIM-Signature dans le message. Le tag d= identifie le domaine signataire, et le tag s= identifie le sélecteur (pour pouvoir effectuer la rotation des clés sans interruption).

L’avantage de DKIM sur SPF est qu’il survit au transfert. Quand Gmail transfère un message vers une autre boîte, la vérification SPF échoue (l’IP de Gmail n’est pas autorisée pour votre domaine), mais la signature DKIM reste intacte car le contenu du message n’a pas changé.

DMARC : le liant

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) s’appuie sur SPF et DKIM en ajoutant deux choses : l’ alignement et la politique.

L’alignement signifie que le domaine dans SPF ou DKIM doit correspondre au domaine de l’en-tête From. L’alignement SPF vérifie que le domaine de l’expéditeur d’enveloppe correspond au domaine de l’en-tête From. L’alignement DKIM vérifie que le domaine de signature d= correspond au domaine de l’en-tête From. En mode relaxé (le défaut), la correspondance au niveau du domaine organisationnel suffit — bounce.example.com s’aligne avec example.com. En mode strict, les domaines doivent correspondre exactement.

La politique indique aux destinataires quoi faire en cas d’échec d’authentification :

• p=none — surveillance uniquement, tout est livré, rapports envoyés

• p=quarantine — les échecs vont en spam

• p=reject — les échecs sont rejetés

Un enregistrement DMARC se place à _dmarc.example.com :

_dmarc.example.com TXT “v=DMARC1; p=none; pct=100;
rua=mailto:dmarc-reports@example.com;”

Le tag rua indique où envoyer les rapports agrégés — des fichiers XML qui montrent chaque IP ayant envoyé du courrier en prétendant être votre domaine, et si SPF/DKIM a réussi ou échoué. C’est votre outil principal pendant le déploiement.

Il existe aussi ruf — l’URI de rapport d’échec, où les rapports individuels par message sont envoyés. La plupart des organisations n’utilisent pas ruf car les rapports d’échec contiennent les en-têtes complets des messages et posent des problèmes de confidentialité. Deux tags associés, fo (qui contrôle quand les rapports d’échec sont générés) et rf (le format du rapport), sont couramment copiés-collés dans les enregistrements DMARC sans en comprendre les prérequis. Or, selon la RFC 7489 section 6.3, le contenu du tag fo

. Donc si votre enregistrement DMARC contient fo=1; rf=afrf; mais pas de ruf, ces tags sont du code mort. Ne les incluez pas.

Un enregistrement DMARC propre et complet pour la phase de surveillance ressemble à :

v=DMARC1; p=none; pct=100;
rua=mailto:reports@aggregateur.example.com,mailto:dmarc@votredomaine.com;

C’est tout. v, p, pct, et rua. Tout le reste est soit pour l’application (sp, adkim, aspf), soit nécessite ruf pour fonctionner.

Phase 1 : Découverte — commencer à p=none

La première règle du déploiement DMARC : ne jamais commencer à p=reject. Vous ne savez pas qui envoie du courrier en tant que votre domaine tant que vous n’avez pas regardé. Publiez p=none avec les rapports agrégés et attendez.

v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com;

Inscrivez-vous à un agrégateur de rapports DMARC — des services comme dmarcian, MXToolbox ou Report URI transforment les rapports XML en tableaux de bord lisibles. Pointez votre rua vers leurs adresses d’ingestion. Vous voudrez plusieurs destinations pour la redondance :

rua=mailto:id@ag.dmarcian.com,mailto:id@mxtoolbox.dmarc-report.com,mailto:dmarc+rua@example.com;

Donnez-lui au moins deux semaines. Les rapports révéleront chaque source envoyant du courrier en tant que votre domaine : vos serveurs applicatifs, votre service d’email transactionnel, Google Workspace, les plateformes marketing, les outils SaaS tiers que vous aviez oubliés, et — si vous n’avez pas de chance — du courrier usurpé par des attaquants. Pour une grande plateforme, attendez-vous à trouver 10 à 20 sources d’envoi légitimes réparties sur une dizaine de sous-domaines.

Phase 2 : Corriger les problèmes d’alignement

Une fois que les rapports affluent, vous verrez des patterns. Voici les échecs les plus courants et comment les corriger.

AWS SES : le double problème d’alignement

Par défaut, SES envoie avec MAIL FROM: id@us-west-2.amazonses.com et signe DKIM avec d=amazonses.com. SPF et DKIM passent tous les deux, mais aucun ne s’aligne avec le domaine de votre en-tête From. DMARC échoue à 0% de conformité.

La correction nécessite deux fonctionnalités SES :

• Signature DKIM : Activez aws_ses_domain_dkim, qui génère 3 enregistrements CNAME. Une fois vérifiés, SES signe avec d=votredomaine.com.

• MAIL FROM personnalisé : Configurez aws_ses_domain_mail_from avec un sous-domaine comme bounce.votredomaine.com. SES exige que ce soit un sous-domaine — vous ne pouvez pas utiliser l’apex. Ajoutez un enregistrement MX pointant vers l’endpoint de feedback SES et un enregistrement SPF autorisant SES.

Avec les deux en place, SES envoie du courrier aligné sur SPF et DKIM. En Terraform :

resource "aws_ses_domain_dkim" "main" {
domain   = aws_ses_domain_identity.main.domain
provider = aws.ses
}

resource "aws_route53_record" "ses_dkim" {
count   = 3
zone_id = var.zone_id
name    = "${aws_ses_domain_dkim.main.dkim_tokens[count.index]}._domainkey"
type    = "CNAME"
ttl     = 300
records = ["${aws_ses_domain_dkim.main.dkim_tokens[count.index]}.dkim.amazonses.com"]
}

resource "aws_ses_domain_mail_from" "main" {
domain           = aws_ses_domain_identity.main.domain
mail_from_domain = "bounce.${aws_ses_domain_identity.main.domain}"
provider         = aws.ses
}

resource "aws_route53_record" "ses_mail_from_mx" {
zone_id = var.zone_id
name    = aws_ses_domain_mail_from.main.mail_from_domain
type    = "MX"
ttl     = 300
records = ["10 feedback-smtp.us-west-2.amazonses.com"]
}

resource "aws_route53_record" "ses_mail_from_spf" {
zone_id = var.zone_id
name    = aws_ses_domain_mail_from.main.mail_from_domain
type    = "TXT"
ttl     = 300
records = ["v=spf1 include:amazonses.com -all"]
}

Google Workspace : DKIM auto-généré

Google Workspace signe le courrier sortant avec DKIM par défaut, mais utilise une clé auto-générée àd=votredomaine-com.20230601.gappssmtp.com. Cela ne s’aligne pas avec votre domaine pour DMARC.

Pour corriger : allez dans Google Admin → Apps → Google Workspace → Gmail → Authentifier les emails, sélectionnez votre domaine, générez une clé DKIM (2048 bits, n’importe quel sélecteur — google est la convention), publiez l’enregistrement TXT en DNS, puis cliquez sur « Démarrer l’authentification ». Google signera alors avec d=votredomaine.com, ce qui s’aligne.

Attention aux domaines secondaires dans Google Workspace. Si vous avez core.entreprise.com comme domaine additionnel, il obtient sa propre clé DKIM auto-générée qui ne s’alignera pas avec entreprise.com. Vous devez générer et activer DKIM pour chaque domaine individuellement.

Les bounces Postfix : le tueur silencieux de DMARC

Celui-ci vous rendra fou si vous ne le connaissez pas. Vos rapports DMARC montrent des centaines de messages avec SPF: none, DKIM: none provenant de vos propres serveurs de messagerie. Tout le reste passe. Que se passe-t-il ?

Les messages de rebond (Delivery Status Notifications). Quand Postfix génère un bounce, il l’envoie avec MAIL FROM:<> — un expéditeur d’enveloppe vide, selon la RFC 3461. SPF vérifie alors le hostname HELO au lieu de votre domaine, ce qui retourne typiquement spf=none. Et par défaut, Postfix ne fait pas passer les messages générés en interne (bounces, notifications de délai) par les filtres de contenu comme OpenDKIM. Donc le bounce n’a ni alignement SPF ni signature DKIM. DMARC échoue.

La correction tient en un seul paramètre Postfix :

internal_mail_filter_classes = bounce

Cela indique à Postfix de faire passer les bounces par la chaîne non_smtpd_milters, qui inclut OpenDKIM. Une fois appliqué, les bounces sont signés DKIM avec la clé de votre domaine, DKIM s’aligne, et DMARC passe.

Vous pouvez le vérifier immédiatement. Envoyez un email à une adresse inexistante pour déclencher un bounce :

$ sendmail inexistant@example.com <<'EOF'
Subject: test bounce
From: test@votredomaine.com

test
EOF

$ grep 'from=<>' /var/log/mail.log | tail -1
# Trouver l'ID de file du bounce

$ grep 'QUEUE_ID' /var/log/mail.log | grep dkim
# Confirmer que DKIM-Signature a été ajouté

Vérifiez les en-têtes du bounce — vous devriez voir à la fois une DKIM-Signature sur le bounce lui-même (avec Return-Path: <>) et dmarc=pass dans les Authentication-Results du serveur de réception.

Une approche architecturale plus propre consiste à utiliser un sous-domaine dédié aux bounces — par exemple bounces.example.com — avec sa propre clé DKIM et sa propre infrastructure de signature, complètement séparée de votre courrier client. Le mailer qui signe les bounces n’émet pas vos communications habituelles, et ne peut donc pas être utilisé pour falsifier des emails normaux même s’il est compromis. C’est aussi important pour la réputation : les fournisseurs de messagerie prêtent une attention particulière au domaine DNS source, et isoler le trafic de rebond évite qu’il ne plombe la réputation d’expéditeur de votre domaine principal.

Expéditeurs tiers

Chaque outil SaaS qui envoie des emails « depuis » votre domaine est un échec DMARC potentiel. Plateformes marketing, systèmes de helpdesk, outils CRM, alertes de monitoring — chacun doit être autorisé via SPF (ajoutez leurs IP ou incluez leur enregistrement SPF) et idéalement configuré avec une signature DKIM utilisant la clé de votre domaine.

Certains services supportent le DKIM personnalisé (vous fournissez une paire de clés ou ils vous donnent un CNAME à publier). D’autres n’envoient qu’avec leur propre domaine en DKIM et comptent sur l’alignement SPF. Vérifiez la documentation de chaque service. Si un service ne peut faire ni l’un ni l’autre, envisagez de le faire envoyer depuis un sous-domaine avec sa propre politique DMARC, ou de router son courrier via votre propre relais.

Phase 3 : Stratégie de sous-domaines

DMARC s’applique au domaine organisationnel et à tous ses sous-domaines. Si votre apex a p=none, chaque sous-domaine hérite de cette politique sauf s’il publie son propre enregistrement _dmarc. Le tag sp= dans l’enregistrement DMARC de l’apex définit une politique par défaut pour les sous-domaines — utile pour verrouiller les sous-domaines qui ne devraient pas envoyer de courrier tout en gardant l’apex permissif pendant le déploiement.

En pratique, vous rencontrerez trois types de sous-domaines :

• Sous-domaines qui envoient du courrier (ex : notifications.example.com) : nécessitent SPF, DKIM corrects, et possiblement leur propre enregistrement DMARC.

• Sous-domaines qui n’envoient pas de courrier mais existent en DNS (ex : cdn.example.com, api.example.com) : ajoutez un enregistrement SPF nul (v=spf1 -all) pour déclarer explicitement qu’ils n’envoient pas d’email. Cela empêche l’usurpation et élimine le bruit dans les rapports DMARC causé par des services internes qui envoient accidentellement du courrier système depuis ces domaines.

• Sous-domaines d’infrastructure interne (ex : foundation.tools.entreprise.com) : les hôtes EC2 et services internes utilisent souvent le domaine de la machine pour le courrier système. Soit reconfigurez-les pour utiliser le bon domaine d’envoi, soit ajoutez un SPF nul pour rejeter ce trafic.

Phase 4 : Passer à l’application

Une fois que vos rapports agrégés montrent 95%+ de conformité DMARC sur toutes les sources légitimes, vous êtes prêt à appliquer. Ne passez pas directement à p=reject.

Le tag pct est votre régulateur. Il contrôle quel pourcentage des messages en échec est soumis à la politique :

1. Passez à p=quarantine; pct=10; — seulement 10% des échecs vont en spam. Surveillez les rapports pendant une semaine.

2. Augmentez progressivement : pct=25, puis pct=50, puis pct=100.

3. Une fois la quarantaine à 100% propre, passez à p=reject; pct=10; et augmentez à nouveau.

À chaque étape, consultez vos rapports agrégés. Cherchez les expéditeurs légitimes qui montrent soudainement des échecs — ce sont ceux que vous avez manqués. Corrigez-les avant d’augmenter le pourcentage.

Pièges opérationnels

Une collection de choses qui vous mordront si vous ne faites pas attention.

Le fallback HELO de SPF

Quand l’expéditeur d’enveloppe est vide (bounces, comme discuté ci-dessus), SPF se rabat sur la vérification du hostname HELO/EHLO. Cela signifie que le hostname de votre serveur de messagerie compte pour SPF. Si smtp-relay1.example.com s’annonce en HELO et qu’il n’y a pas d’enregistrement SPF pour ce hostname, les bounces obtiennent spf=none. Vous pouvez ajouter un enregistrement SPF pour le hostname HELO par précaution, mais signer les bounces en DKIM est la correction la plus fiable.

Conflits d’enregistrements DNS

Route53 (et la plupart des fournisseurs DNS) n’autorisent pas deux jeux d’enregistrements du même type au même nom. Si votre domaine a déjà un enregistrement TXT (par exemple, une chaîne de vérification de site), votre enregistrement SPF doit être dans le même jeu d’enregistrements. En Terraform, cela signifie une seule ressource aws_route53_record avec plusieurs valeurs dans la liste records — pas deux ressources séparées.

Import d’enregistrements DNS existants

Si vous ajoutez SPF à un domaine qui a déjà des enregistrements TXT créés en dehors de Terraform, vous devrez d’abord importer l’enregistrement existant dans le state :

terraform import aws_route53_record.spf ZONEID_example.com_TXT

Puis mettez à jour votre configuration Terraform pour inclure à la fois les valeurs existantes et le nouvel enregistrement SPF. Sinon Terraform essaiera de créer un nouvel enregistrement et échouera avec un conflit.

Rotation des clés DKIM

Les clés DKIM doivent être renouvelées périodiquement (annuellement est courant). Le mécanisme de sélecteur rend cela transparent : publiez une nouvelle clé avec un nouveau sélecteur, mettez à jour votre configuration de signature pour utiliser le nouveau sélecteur, puis supprimez l’ancienne clé du DNS après un délai de grâce. Ce délai est important car les messages en transit ou en quarantaine de spam peuvent encore référencer l’ancien sélecteur.

TTL bas pendant le déploiement

Mettez les TTL DNS à 300 secondes pendant que vous faites activement des changements. Si vous publiez un enregistrement SPF cassé avec un TTL de 3600s, vous êtes bloqué pendant une heure. À 300s, vous pouvez corriger et propager en cinq minutes. Remontez les TTL une fois que tout est validé et stable.

Domaines multiples, même infrastructure

Si vous opérez plusieurs domaines via la même infrastructure mail (mêmes relais Postfix, même compte SES), chaque domaine a besoin de ses propres enregistrements SPF, DKIM et DMARC. Les enregistrements SPF peuvent partager des includes, et la signature DKIM peut utiliser des sélecteurs spécifiques au domaine sur le même milter, mais chaque domaine a besoin de ses propres entrées DNS. Il n’y a pas de raccourci.

Services tiers défunts

Auditez vos adresses rua et ruf DMARC périodiquement. Des services ferment (dmarcanalyzer a été racheté et arrêté), et les adresses obsolètes perdent simplement les rapports en silence. Si votre seule destination rua tombe, vous volez à l’aveugle. Utilisez plusieurs destinations de rapports.

La checklist

Pour chaque domaine qui envoie des emails :

1. Publiez un enregistrement DMARC à _dmarc.example.com avec p=none et rua pointant vers votre/vos agrégateur(s) de rapports.

2. Attendez les rapports agrégés. Identifiez chaque source d’envoi légitime.

3. Corrigez SPF : assurez-vous que chaque IP ou service d’envoi est dans votre enregistrement SPF. Restez sous 10 résolutions DNS.

4. Corrigez DKIM : assurez-vous que chaque service d’envoi signe avec d=votredomaine.com (ou un sous-domaine aligné). Activez DKIM dans Google Workspace Admin si applicable.

5. Corrigez les bounces : ajoutez internal_mail_filter_classes = bounce à Postfix si vous exploitez vos propres MTA.

6. Corrigez les services cloud : activez DKIM et le MAIL FROM personnalisé dans SES. Vérifiez les autres fournisseurs cloud de la même façon.

7. Ajoutez un SPF nul (v=spf1 -all) aux sous-domaines qui n’envoient pas d’email.

8. Nettoyez les enregistrements DMARC : supprimez les tags fo et rf si vous n’avez pas de ruf, retirez les adresses de rapports obsolètes, supprimez les includes de services dépréciés du SPF.

9. Montez progressivement l’application : p=quarantine avec pct croissant, puis p=reject.

10. Surveillez en permanence. Nouvelles sources d’envoi, rotations de clés, changements d’infrastructure — DMARC n’est pas du « configurer et oublier ».

Conclusion

L’application de DMARC n’est pas un changement unique — c’est un projet. Le protocole lui-même est simple, mais le vrai travail est dans la découverte : trouver chaque façon dont le courrier quitte votre organisation, comprendre pourquoi chaque chemin existe, et corriger l’alignement source par source. Les pièges sont dans les détails — les bounces qui contournent les milters, SES qui envoie avec le domaine d’Amazon, Google Workspace qui utilise des clés DKIM auto-générées, les enregistrements SPF qui atteignent la limite de résolutions, les enregistrements TXT DNS qui cassent à 255 caractères.

Commencez à p=none, soyez patient pendant la phase de découverte, corrigez l’alignement méthodiquement, et montez l’application progressivement. Vos rapports agrégés sont la source de vérité. Quand vous atteindrez p=reject, vous comprendrez votre infrastructure email mieux que vous ne l’auriez jamais voulu.