DMARC, DKIM et SPF : guide déploiement complet et diagnostic

Chaque jour, des milliers d'emails frauduleux sont envoyés en usurpant l'identité de votre domaine sans que vous le sachiez. Le spoofing d'email est le vecteur d'entrée de 91 % des cyberattaques réussies selon le CISA : un attaquant forge l'adresse expéditeur pour imiter votre entreprise, trompe un fournisseur ou un collaborateur, et déclenche un virement frauduleux ou vole des identifiants. Les trois protocoles d'authentification email — SPF, DKIM et DMARC — forment un bouclier technique indispensable. Pourtant, en 2025, plus de 40 % des domaines français d'entreprises de taille intermédiaire n'avaient toujours pas de politique DMARC active (p=quarantine ou p=reject), laissant la porte ouverte aux attaques BEC (Business Email Compromise) qui coûtent en moyenne 125 000 euros par incident en Europe. Ce guide vous explique, de façon opérationnelle, comment déployer SPF, DKIM et DMARC sur votre domaine, interpréter les rapports, gérer les cas spéciaux (ESPs, forwarding, Microsoft 365, Google Workspace) et atteindre la politique reject sans interruption de service.

Pourquoi l'authentification email est devenue critique

Le protocole SMTP date de 1982 et n'a jamais été conçu pour authentifier l'expéditeur. N'importe qui peut ouvrir une connexion SMTP et indiquer MAIL FROM: [email protected]. Les attaques BEC (Business Email Compromise) exploitent cette faille pour escroquer les équipes financières : en 2024, le FBI IC3 a recensé 2,9 milliards de dollars de pertes liées aux BEC aux États-Unis. En France, l'ANSSI note une recrudescence des campagnes d'hameçonnage ciblant les TPE/PME via usurpation de domaine fournisseur.

Les trois piliers de l'authentification email répondent chacun à une menace précise :

• SPF empêche l'envoi depuis des serveurs non autorisés.
• DKIM garantit l'intégrité du message et prouve que votre clé privée a signé l'email.
• DMARC relie SPF et DKIM, définit la politique d'échec et génère des rapports forensiques.

Sans ces trois protocoles alignés, même les filtres anti-spam modernes laissent passer des emails frauduleux très convaincants car ils semblent venir de votre infrastructure.

SPF (Sender Policy Framework) : mécanisme et configuration

SPF est un enregistrement DNS de type TXT publié sur votre domaine. Il liste les adresses IP et les services autorisés à envoyer des emails en votre nom. Le serveur destinataire interroge le DNS pour vérifier si le serveur SMTP expéditeur est dans cette liste.

Structure d'un enregistrement SPF

Un enregistrement SPF suit cette syntaxe :

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -all

Les mécanismes principaux :

• ip4 / ip6 : adresse ou plage IP autorisée.
• include: : délègue à l'enregistrement SPF d'un tiers (votre ESP).
• a : autorise l'IP résolue par l'enregistrement A du domaine.
• mx : autorise les serveurs MX du domaine.
• -all (hard fail) : tout le reste est rejeté. ~all (soft fail) marque en spam mais accepte.

La limite des 10 lookups DNS

SPF impose une limite stricte : le serveur destinataire ne peut effectuer que 10 requêtes DNS lors de l'évaluation de votre enregistrement SPF (chaque include:, a, mx comptant comme un lookup). Si vous dépassez cette limite, le résultat SPF devient permerror, ce qui fait échouer l'authentification. Avec plusieurs ESPs (Mailchimp, Sendgrid, Salesforce Marketing Cloud), cette limite est vite atteinte. La solution est d'utiliser un service de compression SPF (SPF Flattening) qui résout tous les includes et génère une liste IP statique, ou de migrer vers des sous-domaines d'envoi dédiés.

Softfail (~all) versus Fail (-all)

Beaucoup d'organisations débutent avec ~all pour observer sans bloquer. C'est une erreur fréquente en production avancée : ~all n'empêche pas le spoofing, il se contente de marquer le message. Une fois DMARC déployé en p=reject, c'est DMARC qui gère la politique finale et non SPF seul — donc passer à -all est recommandé pour clarifier l'intention.

DKIM (DomainKeys Identified Mail) : signature cryptographique

DKIM ajoute une signature numérique dans l'en-tête de chaque email. Le serveur expéditeur signe le message avec une clé privée ; le serveur destinataire vérifie la signature en interrogeant la clé publique publiée dans votre DNS.

Comment fonctionne la signature DKIM

Le serveur de messagerie calcule un hash des en-têtes sélectionnés (From, To, Subject, Date, Body) et le chiffre avec la clé privée RSA ou Ed25519. La signature est insérée dans l'en-tête DKIM-Signature :

DKIM-Signature: v=1; a=rsa-sha256; d=votreentreprise.fr; s=mail2024;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=XXXXXXXXXXX...

Le paramètre s= est le sélecteur, qui pointe vers l'enregistrement DNS mail2024._domainkey.votreentreprise.fr contenant la clé publique.

Enregistrement DNS DKIM

mail2024._domainkey.votreentreprise.fr. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

La longueur de clé recommandée est 2048 bits minimum. Les clés 1024 bits sont considérées obsolètes depuis 2019 (RFC 8301). Pour Ed25519, 256 bits suffisent et offrent de meilleures performances.

Rotation des clés DKIM

La bonne pratique est de changer les clés DKIM tous les 6 à 12 mois. La procédure : créez un nouveau sélecteur (ex. mail2025), publiez la nouvelle clé publique, reconfigurez les serveurs pour signer avec le nouveau sélecteur, attendez 48h de propagation DNS, puis révoquez l'ancien sélecteur en supprimant son enregistrement DNS.

DMARC : orchestration et politique

DMARC (Domain-based Message Authentication, Reporting and Conformance) s'appuie sur SPF et DKIM et ajoute deux fonctionnalités cruciales : la politique d'application (que faire si l'authentification échoue ?) et le reporting (envoyer des rapports XML à une adresse désignée).

L'alignement DMARC

DMARC requiert un alignement entre le domaine du From: visible par l'utilisateur et le domaine authentifié par SPF ou DKIM :

• Alignement SPF : le domaine dans MAIL FROM (envelope sender) doit correspondre au domaine du From:.
• Alignement DKIM : le domaine d= dans la signature DKIM doit correspondre au domaine du From:.

En mode relaxed (par défaut), les sous-domaines sont acceptés (mail.votreentreprise.fr satisfait votreentreprise.fr). En mode strict, seul le domaine exact est accepté.

Enregistrement DMARC

_dmarc.votreentreprise.fr. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r"

Les paramètres clés :

• p= : politique — none (observer), quarantine (dossier spam), reject (bloquer).
• pct= : pourcentage de messages auxquels appliquer la politique (utile pour déploiement progressif).
• rua= : adresse pour les rapports agrégés (aggregate reports, envoyés quotidiennement).
• ruf= : adresse pour les rapports forensiques (failure reports, envoyés à chaque échec — attention RGPD).

Politiques none, quarantine, reject

p=none est une politique de surveillance uniquement : les emails non authentifiés sont délivrés normalement. Elle est indispensable au début pour cartographier tous vos flux email légitimes sans risque. p=quarantine dirige les emails suspects vers le dossier spam. p=reject refuse totalement les emails qui échouent à DMARC — c'est l'objectif final.

Déploiement progressif : de none à reject en 4 phases

Un déploiement brutal en p=reject peut bloquer des flux email légitimes non encore identifiés (newsletters envoyées par un prestataire oublié, système de ticketing, imprimante réseau). La méthode en 4 phases sécurise la transition sur 6 à 10 semaines.

Phase 1 — Inventaire et SPF/DKIM (semaines 1-2)

Auditez tous les services qui envoient des emails en votre nom : serveurs internes, ESPs (Mailchimp, Brevo, Sendgrid), CRM (Salesforce, HubSpot), helpdesk (Zendesk, Freshdesk), plateformes RH. Configurez un enregistrement SPF couvrant tous ces serveurs. Activez DKIM sur chaque service. Publiez p=none avec une adresse rua= valide.

Phase 2 — Analyse des rapports (semaines 2-4)

Les rapports DMARC XML arrivent chaque jour. Utilisez un outil d'analyse (DMARC Analyzer, Postmark, Dmarcian) pour les visualiser. Identifiez les sources qui échouent : ESP non configuré, serveur oublié, forwarding. Corrigez chaque source jusqu'à atteindre 95 %+ de passage DMARC.

Phase 3 — Quarantine progressive (semaines 4-6)

"v=DMARC1; p=quarantine; pct=5; rua=mailto:[email protected]"

Commencez avec pct=5 (5 % des messages en échec envoyés en spam) et augmentez progressivement à 25 %, 50 %, 100 % sur deux semaines en surveillant les rapports. Vérifiez que les plaintes de non-réception diminuent.

Phase 4 — Reject (semaine 8+)

"v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]"

Passez à p=reject une fois que vous atteignez 98 %+ de passage DMARC sur une semaine complète. Maintenez le monitoring des rapports en continu pour détecter les nouveaux services ajoutés sans configuration SPF/DKIM.

BIMI : votre logo dans les boîtes mail

BIMI (Brand Indicators for Message Identification) est une extension qui permet d'afficher le logo de votre marque à côté de vos emails dans les clients compatibles (Gmail, Apple Mail, Yahoo). Prérequis : avoir DMARC actif avec p=quarantine ou p=reject. L'enregistrement DNS BIMI pointe vers un fichier SVG de votre logo :

default._bimi.votreentreprise.fr. IN TXT "v=BIMI1; l=https://votreentreprise.fr/logo.svg; a=https://votreentreprise.fr/vmc.pem"

Le paramètre a= (optionnel mais recommandé) pointe vers un VMC (Verified Mark Certificate), un certificat délivré par DigiCert ou Entrust qui valide juridiquement votre marque. Sans VMC, le logo s'affiche dans Yahoo mais pas dans Gmail. Le VMC coûte environ 1 500 à 3 000 € par an. L'impact marketing est significatif : les études montrent une hausse de 10 % du taux d'ouverture pour les domaines affichant leur logo certifié.

Diagnostic et outils de vérification

Plusieurs outils gratuits permettent de diagnostiquer votre configuration email.

MXToolbox

MXToolbox.com propose des vérificateurs SPF, DKIM et DMARC en ligne. Entrez votre domaine pour obtenir un diagnostic instantané de vos enregistrements DNS et des alertes sur les problèmes de configuration (SPF trop permissif, DKIM expirée, DMARC absent).

mail-tester.com

Envoyez un email à l'adresse unique générée par mail-tester.com pour obtenir un score de délivrabilité sur 10 avec un détail complet : SPF pass/fail, DKIM pass/fail, score Spamassassin, contenu HTML/texte, liens rompus.

Google Postmaster Tools

Pour les domaines envoyant vers Gmail, Google Postmaster Tools (postmaster.google.com) fournit des métriques en temps réel : réputation du domaine, taux de spam signalé, taux d'erreurs de livraison, utilisation DMARC.

DMARC Analyzer

DMARC Analyzer (dmarcian.com/dmarc-resources) transforme les rapports XML bruts en tableaux de bord visuels. Il identifie automatiquement les sources légitimes vs frauduleuses et recommande les corrections SPF à apporter.

Analyse des rapports DMARC XML

Les rapports agrégés DMARC (RUA) sont des fichiers XML envoyés par chaque grand FAI (Google, Microsoft, Yahoo) à votre adresse rua=. Comprendre leur structure vous permet d'agir sans dépendre d'un outil tiers.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1700000000</end>1700086400</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>votreentreprise.fr</domain>
    <p>quarantine</p>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1250</count>
      <policy_evaluated><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
    </row>
  </record>
</feedback>

Chaque <record> représente un groupe d'emails depuis une IP source. Si dkim=fail ou spf=fail pour une IP que vous reconnaissez, c'est un flux légitime mal configuré à corriger. Si l'IP est inconnue, c'est un potentiel spoofeur.

Cas spéciaux : ESPs, forwarding et listes de diffusion

Le forwarding d'email est le cas le plus problématique pour DMARC. Quand un serveur transfère un email, il ne re-signe pas avec DKIM et l'enveloppe SPF change. DMARC peut alors échouer pour des emails légitimes. La solution est SRS (Sender Rewriting Scheme) côté serveur de forwarding, ou se reposer uniquement sur l'alignement DKIM (qui survit au forwarding si le corps et les en-têtes ne sont pas modifiés).

Pour les listes de diffusion (Mailman, Sympa), les messages sont souvent modifiés (ajout de footer, subject prefix) ce qui casse la signature DKIM. Les solutions modernes supportent DKIM ARC (Authenticated Received Chain, RFC 8617) qui préserve la chaîne d'authentification originale à travers les intermédiaires.

Pour les ESPs (Mailchimp, Sendgrid, Brevo), la bonne pratique est d'utiliser un sous-domaine d'envoi dédié (news.votreentreprise.fr) avec sa propre paire DKIM. L'ESP publiera la clé publique dans votre DNS après vérification.

Configuration pour Microsoft 365 et Google Workspace

Microsoft 365

Microsoft 365 génère automatiquement des sélecteurs DKIM pour votre domaine (selector1 et selector2) via Exchange Online. Activez DKIM dans le portail Defender (security.microsoft.com → Email & collaboration → Policies → DKIM). Ajoutez les CNAME dans votre DNS :

selector1._domainkey.votreentreprise.fr CNAME selector1-votreentreprise-fr._domainkey.microsoft.com
selector2._domainkey.votreentreprise.fr CNAME selector2-votreentreprise-fr._domainkey.microsoft.com

Pour SPF avec Microsoft 365 : include:spf.protection.outlook.com. Notre article sur le durcissement Exchange Online et anti-phishing détaille la configuration complète des politiques Defender for Office 365.

Google Workspace

Dans la console d'administration Google (admin.google.com → Apps → Google Workspace → Gmail → Authentification email), activez DKIM et générez la clé 2048 bits. Copiez l'enregistrement TXT dans votre DNS. Pour SPF : include:_spf.google.com.

Checklist déploiement DMARC en 20 points

1. Inventaire complet de tous les flux email sortants.
2. SPF publié avec tous les serveurs autorisés.
3. SPF en -all après stabilisation.
4. Vérification de la limite 10 lookups DNS SPF.
5. DKIM 2048 bits activé sur le serveur principal.
6. DKIM activé sur chaque ESP (avec sous-domaine dédié).
7. Sélecteur DKIM documenté et rotation planifiée (12 mois).
8. DMARC publié en p=none avec adresse rua=.
9. Adresse rua= capable de recevoir des emails XML volumineux.
10. Outil d'analyse des rapports configuré (Dmarcian, Postmark, etc.).
11. Analyse des rapports pendant 2 semaines minimum.
12. Correction de toutes les sources légitimes en échec.
13. Passage à p=quarantine; pct=5.
14. Montée progressive de pct à 25, 50, 100 %.
15. Vérification Google Postmaster Tools (si applicable).
16. Passage à p=reject après 98 %+ de passage.
17. Monitoring continu des rapports DMARC.
18. Procédure documentée pour tout nouvel ESP ou service email.
19. BIMI déployé si budget VMC disponible.
20. Formation équipe IT sur la procédure de rotation DKIM.

FAQ — Questions fréquentes

Combien de temps faut-il pour que les enregistrements DNS DMARC se propagent ?

La propagation DNS dépend du TTL (Time To Live) de vos enregistrements. En pratique, comptez 1 à 48 heures pour une propagation mondiale. Pour accélérer les tests, abaissez temporairement le TTL à 300 secondes avant de publier vos enregistrements, puis remontez-le à 3600 ou 86400 secondes une fois la configuration stable. Les outils comme DMARC Analyzer ou MXToolbox affichent la propagation en temps réel depuis plusieurs résolveurs DNS mondiaux.

SPF -all versus ~all : quel impact sur la délivrabilité ?

~all (softfail) ne bloque pas les emails non autorisés, il les marque. La plupart des FAI modernes ignorent ce marquage sans DMARC. Avec DMARC en p=reject, l'impact pratique de SPF -all vs ~all est minimal car c'est DMARC qui dicte la politique finale. Cependant, utiliser -all envoie un signal d'intention clair et simplifie le débogage des rapports DMARC. Il n'y a aucun risque de délivrabilité supplémentaire à utiliser -all une fois que tous vos serveurs légitimes sont dans l'enregistrement SPF.

DMARC peut-il impacter la délivrabilité des emails légitimes ?

Oui, si le déploiement est précipité. Un passage brutal à p=reject sans phase de surveillance peut bloquer des flux email légitimes non cartographiés (campagnes marketing via ESP non configuré, notifications automatiques de systèmes internes, emails transactionnels d'un CRM). C'est précisément pourquoi la phase p=none avec analyse des rapports est indispensable. Des outils d'analyse des rapports DMARC comme dmarc.org proposent des ressources gratuites pour éviter ces erreurs. Une fois en p=reject et avec un monitoring actif, DMARC n'impacte que les emails frauduleux. Pour les attaques BEC plus sophistiquées qui usurpent des domaines proches, consultez notre analyse sur les attaques BEC et fraudes email professionnelles. La protection anti-phishing avancée est aussi couverte dans notre article sur le quishing et phishing AiTM 2026. Pour une vision complète de la sécurisation de Microsoft 365, notre livre blanc sécurité Microsoft 365 intègre DMARC dans une stratégie de défense en profondeur.