Vous avez mis en place SPF. Vous avez configuré DKIM. Vos emails sont authentifiés, et vous êtes serein sur votre posture de sécurité. Puis vous découvrez que quelqu’un a envoyé des milliers d’emails de phishing depuis votre domaine pendant des mois, et qu’aucune de vos authentifications n’a servi parce que vous n’avez jamais dit à personne quoi faire en cas d’échec.
C’est la lacune que DMARC comble. SPF et DKIM sont des mécanismes de vérification — ils peuvent indiquer à un serveur de réception si un email est légitime. Mais ils ne précisent pas ce qui doit se passer quand la vérification échoue. Faut‑il quand même livrer l’email ? Le mettre en quarantaine ? Le rejeter purement et simplement ? Sans instructions explicites, la plupart des serveurs choisissent par défaut de livrer l’email, éventuellement avec un avertissement que les utilisateurs ignorent.
DMARC — Domain-based Message Authentication, Reporting, and Conformance — est la couche de politique. Elle dit au monde : « Voici ce que je veux que vous fassiez des emails qui échouent l’authentification. Et au passage, envoyez‑moi des rapports sur ce que vous observez. »
Les trois politiques DMARC
Les politiques DMARC sont spécifiées avec le tag 'p=' dans votre enregistrement DMARC. Il y a trois options, et le bon choix dépend de là où vous en êtes dans votre parcours d’authentification email.
'p=none' est le mode surveillance. Il dit aux serveurs de réception : « Ne faites rien de particulier en cas d’échec, mais envoyez‑moi des rapports sur ce que vous voyez. » C’est par là que tout le monde devrait commencer. Vous obtenez de la visibilité sur votre écosystème email sans risquer de bloquer des emails légitimes.
'p=quarantine' est le juste milieu. Il dit aux serveurs : « Si l’authentification échoue, traitez l’email comme suspect. » En pratique, cela signifie généralement que l’email part dans les dossiers spam ou courrier indésirable. Les utilisateurs peuvent toujours le retrouver s’ils cherchent, mais il n’est pas dans leur boîte de réception.
'p=reject' est l’application complète. Il dit aux serveurs : « Si l’authentification échoue, ne livrez pas l’email. » C’est l’objectif — une protection totale contre l’usurpation de domaine. Mais c’est aussi le plus risqué si votre authentification n’est pas correctement configurée, car des emails légitimes seront bloqués.
Le parcours de 'none' à 'reject' prend généralement des semaines ou des mois. Vous commencez par la surveillance, analysez les rapports pour trouver toutes les sources d’email légitimes, vous assurez qu’elles sont correctement authentifiées, puis augmentez progressivement l’application. Se précipiter vers 'reject' avant d’être prêt est une excellente façon de casser votre email.
Comprendre l’alignement DMARC
C’est là que DMARC devient subtil, et là où beaucoup se trompent. DMARC ne se contente pas de vérifier si SPF et DKIM passent — il vérifie s’ils « s’alignent » avec l’adresse From visible.
Considérez ce scénario : Un attaquant envoie un email avec une adresse From [email protected]. Il l’envoie via son propre serveur, qui a un SPF valide pour attackerdomain.com. L’email passe SPF — mais pour le mauvais domaine. Sans vérification de l’alignement, cette attaque réussirait.
L’alignement DMARC exige que le domaine authentifié par SPF ou DKIM corresponde au domaine de l’en‑tête From. « Correspondre » peut signifier soit une correspondance exacte (alignement strict), soit une correspondance au niveau du domaine organisationnel (alignement relâché).
Avec l’alignement relâché (par défaut), mail.yourcompany.com s’aligne avec yourcompany.com. Avec l’alignement strict, non — seules les correspondances exactes comptent. La plupart des organisations utilisent l’alignement relâché parce qu’il est plus pratique, surtout si vous utilisez des sous‑domaines pour différents flux d’emails.
Pour que DMARC passe, soit SPF doit passer ET s’aligner, soit DKIM doit passer ET s’aligner (ou les deux). C’est pourquoi avoir SPF et DKIM configurés est important — si l’un échoue (par exemple, SPF échoue à cause d’un transfert), l’autre peut encore fournir un résultat passant.
Rapports DMARC : votre fenêtre sur les abus email
La fonction de reporting de DMARC est probablement aussi précieuse que l’application de politique. Lorsque vous publiez un enregistrement DMARC avec un tag 'rua=', les serveurs de réception vous envoient des rapports agrégés sur les emails qu’ils ont vus prétendre provenir de votre domaine.
Ces rapports sont des fichiers XML qui arrivent quotidiennement (en général). Ils contiennent des données sur les volumes d’emails, les résultats d’authentification et les sources d’envoi. Pour chaque IP source, vous verrez combien d’emails ont été envoyés, si SPF et DKIM ont réussi, et quelle politique a été appliquée.
La première fois que vous regardez des rapports DMARC, vous serez probablement surpris. Vous verrez des emails provenant de sources que vous aviez oubliées — cet ancien outil marketing que vous avez cessé d’utiliser mais jamais décommissionné, le système de facturation qui envoie des reçus, le service de monitoring qui envoie des alertes. Vous verrez aussi probablement des sources non autorisées : des spammeurs, des hameçonneurs, ou simplement des systèmes mal configurés qui se retrouvent à envoyer au nom de votre domaine.
Les rapports DMARC bruts sont difficiles à lire. La plupart des organisations utilisent un service d’analyse DMARC (il existe des options gratuites et payantes) qui agrège les rapports, visualise les données et vous alerte en cas de problème. C’est fortement recommandé — essayer de parser des rapports XML manuellement ne passe pas à l’échelle.
Il existe aussi 'ruf=' pour des rapports forensic, qui envoient des informations détaillées sur des emails individuels en échec. Ils sont plus sensibles en matière de confidentialité (ils peuvent inclure le contenu de l’email) et beaucoup de récepteurs ne les envoient pas, mais ils peuvent être utiles pour investiguer des incidents spécifiques.
La voie vers l’application
Passer de p=none à p=reject est un processus, pas un événement. Voici comment cela se déroule généralement en pratique.
Vous commencez en publiant un enregistrement DMARC avec p=none et une adresse rua pour les rapports. Vous n’avez pas besoin d’un SPF et DKIM parfaits à ce stade — vous collectez simplement des données. Attendez au moins deux semaines, idéalement un mois, pour accumuler suffisamment de rapports et voir l’ensemble du tableau.
Analysez les rapports. Identifiez chaque source légitime d’email pour votre domaine. Pour chacune, vérifiez que SPF et DKIM sont correctement configurés. C’est souvent là que vous découvrez des services oubliés ou des mauvaises configurations. Corrigez‑les.
Une fois que vos sources légitimes passent l’authentification de manière constante, passez à p=quarantine. Mais n’y allez pas à fond immédiatement — utilisez le tag 'pct=' pour appliquer la politique seulement à un pourcentage des emails en échec. Commencez avec pct=10, ce qui signifie que 10 % des échecs sont mis en quarantaine tandis que 90 % sont encore délivrés normalement.
Surveillez les rapports. Si vous voyez des emails légitimes mis en quarantaine, investiguez et corrigez. Si tout semble bon, augmentez progressivement le pourcentage : 25 %, 50 %, 75 %, 100 %.
Une fois que vous êtes à p=quarantine avec pct=100 et que tout est stable, répétez le processus pour p=reject. Là encore, commencez avec un faible pourcentage et augmentez progressivement. Lorsque vous atteignez p=reject avec pct=100 (ou sans tag pct, ce qui revient par défaut à 100 %), vous avez une application DMARC complète.
Ce processus prend généralement de 2 à 6 mois selon la complexité de votre écosystème email. Se précipiter, c’est risquer de bloquer des emails légitimes. Être trop lent vous laisse vulnérable à l’usurpation. Trouvez le rythme qui convient à votre organisation.
Erreurs DMARC courantes
L’erreur la plus fréquente est de passer directement à p=reject sans phase de surveillance préalable. Vous allez casser quelque chose. Peut‑être le système RH qui envoie des lettres d’offre, l’outil finance qui envoie des factures, ou l’application legacy que personne ne se souvient d’avoir. Commencez avec p=none, toujours.
Autre erreur fréquente : configurer DMARC mais ne jamais regarder les rapports. Les rapports sont tout l’intérêt de la phase de surveillance. Si vous ne les analysez pas, vous avancez à l’aveugle. Mettez en place un outil d’analyse DMARC et examinez réellement les données.
Oublier les sous‑domaines piège beaucoup d’organisations. Par défaut, la politique DMARC s’applique uniquement au domaine exact, pas aux sous‑domaines. Si vous voulez protéger marketing.yourcompany.com, vous avez besoin soit d’un enregistrement DMARC séparé pour ce sous‑domaine, soit d’un tag 'sp=' dans votre enregistrement principal qui spécifie la politique des sous‑domaines.
La mauvaise configuration des services tiers est endémique. Quand vous ajoutez un nouveau service d’email, vous devez mettre à jour SPF (pour autoriser leurs serveurs) et vous assurer qu’ils signent avec DKIM sur votre domaine (et non leur domaine par défaut). Beaucoup de services nécessitent une configuration explicite pour utiliser le DKIM de votre domaine.
Enfin, traiter DMARC comme « on le configure et on l’oublie » conduit à des problèmes. Votre écosystème email évolue dans le temps. De nouveaux services sont ajoutés, d’anciens sont supprimés, les configurations dérivent. Révisez vos rapports DMARC régulièrement, même après avoir atteint l’application complète.
Frequently asked questions
Puis-je utiliser DMARC sans SPF ou DKIM ?
Techniquement oui, mais cela ne sert à rien. La politique DMARC se base sur les résultats de SPF et DKIM. Sans au moins l’un des deux configuré, chaque email échouera DMARC. Vous avez besoin de SPF, DKIM, ou des deux pour que DMARC ait du sens.
Quelle est la différence entre les rapports rua et ruf ?
Les rapports rua (agrégés) sont des synthèses quotidiennes des résultats d’authentification — volumes et taux de réussite/échec par source. Les rapports ruf (forensic) sont des informations détaillées sur des emails individuels en échec. La plupart des organisations n’utilisent que rua ; les rapports ruf sont moins fréquemment envoyés et soulèvent des questions de confidentialité.
Combien de temps dois-je rester à p=none avant de passer à quarantine ?
Au moins 2 à 4 semaines, plus longtemps si vous avez un écosystème email complexe. Vous avez besoin de suffisamment de données pour identifier toutes les sources d’email légitimes et vérifier qu’elles sont correctement authentifiées. Bâcler cette phase est la cause la plus courante des problèmes email liés à DMARC.
DMARC va-t-il arrêter tout le phishing ?
Non. DMARC empêche l’usurpation exacte de domaine (quelqu’un qui envoie en @yourcompany.com), mais il n’arrête pas les domaines ressemblants (yourcompany-secure.com) ni l’usurpation du nom d’affichage (« Votre entreprise `<[email protected]>` »). C’est une couche importante, mais pas une solution anti-phishing complète.