SPF, dKIM, dMARC : protégez vos e-mails contre l’usurpation

Votre domaine envoie peut-être des e-mails frauduleux en ce moment, et vous ne le savez pas. Pas parce que votre serveur a été piraté, mais parce qu’un attaquant a simplement copié votre adresse d’expéditeur dans le champ From d’un message qu’il a lui-même envoyé. Sans SPF, DKIM et DMARC correctement configurés, rien ne l’en empêche. Cet article vous donne les clés pour comprendre comment ces trois protocoles fonctionnent ensemble, comment les vérifier sur les principales plateformes (Microsoft 365, Gmail, OVH, Brevo), et comment passer d’une politique permissive à un rejet complet des e-mails frauduleux sans sacrifier votre délivrabilité.

Pourquoi l’usurpation d’e-mails fonctionne encore

Le protocole SMTP, qui transporte les e-mails depuis les années 1980, n’a jamais été conçu pour authentifier l’expéditeur. N’importe quel serveur peut déclarer envoyer un message au nom de votre domaine. L’adresse affichée dans le champ From — celle que voit le destinataire dans son client de messagerie — est totalement indépendante du serveur qui a réellement acheminé le message. C’est précisément cette dissociation que les attaquants exploitent.

L’usurpation d’e-mail (email spoofing) consiste à faire paraître un message comme provenant d’une personne ou d’une entreprise de confiance. Un fraudeur peut ainsi envoyer un e-mail qui affiche comptabilite@votre-entreprise.fr en expéditeur, alors que le message transite par un serveur situé à l’autre bout du monde. Le destinataire voit votre nom, votre domaine, parfois même votre logo si le fraudeur a copié votre signature HTML.

Les attaques de type Business Email Compromise (BEC) illustrent parfaitement ce mécanisme. Elles s’appuient sur l’usurpation pour abuser de la confiance : fausse facture urgente prétendument envoyée par un fournisseur, demande de virement supposée venir d’un dirigeant, demande d’aide imitant un responsable RH. Ces scénarios ne nécessitent aucune compromission technique du système de messagerie de la victime. Il suffit que le domaine cible soit mal protégé.

Les impacts sont multiples et concrets :

• Perte de réputation : vos clients reçoivent des e-mails frauduleux à votre nom, leur confiance s’érode.
• Perte de revenus : des virements sont détournés, des contrats annulés après une arnaque impliquant votre domaine.
• Implications juridiques : selon les juridictions, une entreprise peut être mise en cause si elle n’a pas pris les mesures raisonnables pour protéger son domaine.
• Blocage par les FAI et les filtres anti-spam : si votre domaine est associé à des campagnes de phishing, vos propres e-mails légitimes commencent à être rejetés ou classés en indésirables.

Ce dernier point est souvent sous-estimé. Un domaine non protégé peut être utilisé massivement pour du spam, ce qui dégrade sa réputation auprès des grands fournisseurs de messagerie. Résultat : vos factures, vos devis, vos newsletters atterrissent dans les spams de vos clients. La protection contre le spoofing n’est donc pas seulement une question de sécurité — c’est aussi une condition de délivrabilité.

La bonne nouvelle, c’est que trois protocoles complémentaires permettent de fermer cette brèche : SPF, DKIM et DMARC. Voyons ce que chacun fait précisément.

SPF, dKIM, dMARC: définitions simples et rôle de chacun

Ces trois acronymes désignent des protocoles d’authentification des e-mails qui s’appuient tous sur le DNS. Ils sont complémentaires, mais chacun répond à une question différente.

SPF — Sender Policy Framework répond à la question : quel serveur a le droit d’envoyer des e-mails au nom de ce domaine ? Concrètement, vous publiez dans votre zone DNS un enregistrement de type TXT qui liste les adresses IP et les serveurs autorisés. Quand un serveur destinataire reçoit un message prétendument envoyé depuis votre domaine, il compare l’adresse IP de l’expéditeur réel à cette liste. Si l’IP est autorisée, SPF passe. Sinon, il échoue.

Ce que SPF ne fait pas : il ne protège pas le champ From visible par l’utilisateur. Il vérifie le Return-Path (aussi appelé envelope sender), qui est l’adresse technique de rebond, différente de l’adresse affichée. Un attaquant peut donc faire passer SPF avec son propre domaine tout en affichant votre adresse dans le From.

DKIM — DomainKeys Identified Mail répond à : ce message a-t-il été signé par le domaine déclaré et son contenu est-il intact ? Le mécanisme repose sur la cryptographie asymétrique. Votre serveur d’envoi signe chaque e-mail (généralement les en-têtes) avec une clé privée. La clé publique correspondante est publiée dans un enregistrement DNS TXT, accessible via un sélecteur DKIM (par exemple selector1._domainkey.votre-domaine.fr). Le serveur destinataire récupère cette clé publique et vérifie que la signature est valide. Si le message a été altéré en transit, la signature ne correspond plus.

Ce que DKIM ne fait pas : il ne prouve pas que l’adresse From appartient au même domaine que celui qui a signé. Un expéditeur malveillant pourrait signer avec son propre domaine tout en affichant le vôtre dans le From.

DMARC — Domain-based Message Authentication, Reporting, and Conformance est la surcouche qui donne du sens aux deux précédents. Il répond à : que faire quand SPF ou DKIM échoue, et comment le domaine du From est-il aligné avec ces vérifications ? DMARC introduit la notion d’alignement : le domaine présent dans le champ From doit correspondre au domaine authentifié par SPF (via le Return-Path) et/ou par DKIM (via le domaine de signature). Sans cet alignement, même un SPF ou DKIM valide ne suffit pas à satisfaire DMARC.

L’enregistrement DMARC, également un TXT record DNS, contient une balise de politique p qui indique au serveur destinataire quoi faire des messages qui échouent :

• p=none : ne rien faire, observer seulement (mode audit).
• p=quarantine : placer le message en dossier indésirables.
• p=reject : refuser le message définitivement.

DMARC génère aussi des rapports envoyés à une adresse que vous définissez : les rapports rua (agrégés, quotidiens) indiquent quels serveurs envoient des e-mails avec votre domaine et si SPF/DKIM passent ; les rapports ruf (forensiques) contiennent les détails des messages en échec.

Ce que DMARC ne fait pas : il ne bloque pas le phishing envoyé depuis d’autres domaines, notamment les domaines similaires au vôtre (typosquattage, comme votre-entreprlse.fr). Il protège votre domaine exact, pas ses imitations.

Ces trois protocoles forment donc un système de défense en couches. Comprendre comment ils s’articulent concrètement lors du traitement d’un e-mail permet de mieux diagnostiquer les problèmes.

Comment SPF, dKIM et DMARC travaillent ensemble contre le spoofing

Imaginons qu’un e-mail arrive sur le serveur de messagerie de votre client. L’adresse affichée dans le From est contact@votre-domaine.fr. Voici ce qui se passe en coulisses, dans l’ordre.

Étape 1 — Vérification SPF. Le serveur destinataire regarde l’adresse IP de la machine qui lui a remis le message, ainsi que le domaine présent dans le Return-Path (l’enveloppe SMTP). Il interroge le DNS pour récupérer l’enregistrement SPF du domaine du Return-Path. Si l’IP est listée, le résultat est pass. Si elle n’est pas listée mais que l’enregistrement se termine par ~all (softfail), le résultat est softfail — le message est suspect mais pas bloqué. Avec -all, c’est un fail strict. Avec ?all, c’est neutral — aucune indication. Avec +all (à ne jamais utiliser), tout le monde est autorisé.

Étape 2 — Vérification DKIM. Le serveur destinataire cherche dans les en-têtes du message la signature DKIM. Cette signature contient le sélecteur et le domaine de signature (d=). Il interroge le DNS pour récupérer la clé publique correspondante (enregistrement TXT du type sélecteur._domainkey.domaine), puis vérifie la signature cryptographique. Si elle est valide et que le contenu n’a pas été altéré, le résultat est pass. Sinon, c’est un fail.

Étape 3 — Décision DMARC. Le serveur récupère l’enregistrement DMARC du domaine présent dans le From (pas du Return-Path, pas du domaine de signature DKIM — le From visible par l’utilisateur). Il vérifie l’alignement :

• Alignement SPF : le domaine du Return-Path correspond-il au domaine du From ? En mode relaxed (par défaut), les sous-domaines sont acceptés. En mode strict, le domaine doit être identique.
• Alignement DKIM : le domaine de la signature DKIM (d=) correspond-il au domaine du From ? Mêmes règles relaxed/strict.

DMARC passe si au moins un des deux alignements réussit (SPF aligné ou DKIM aligné). Si les deux échouent, la politique p s’applique.

Voici un tableau récapitulatif des combinaisons possibles :

Ce tableau illustre un point critique souvent mal compris : SPF et DKIM peuvent tous les deux passer, et DMARC échouer quand même si les domaines ne sont pas alignés avec le From. C’est typiquement ce qui arrive quand vous utilisez un outil tiers (Brevo, Mailchimp, etc.) qui envoie avec son propre Return-Path et sa propre signature DKIM sans que vous ayez configuré l’alignement.

Le résultat de toutes ces vérifications est consigné dans l’en-tête Authentication-Results du message reçu, que vous pouvez inspecter dans n’importe quel client de messagerie. C’est votre premier outil de diagnostic. Voyons maintenant comment procéder méthodiquement.

Comment vérifier vos enregistrements SPF, dKIM et DMARC

La vérification se fait à deux niveaux : dans le DNS (ce que vous avez publié) et dans les en-têtes d’un e-mail réel (ce que les serveurs destinataires voient). Les deux sont nécessaires, car un enregistrement DNS peut sembler correct mais produire des résultats inattendus en situation réelle.

Vérifier dans le DNS. Pour chaque protocole, vous cherchez un enregistrement TXT dans votre zone DNS :

• SPF : enregistrement TXT à la racine de votre domaine, commençant par v=spf1. Exemple : v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all.
• DKIM : enregistrement TXT au format sélecteur._domainkey.votre-domaine.fr, contenant v=DKIM1; k=rsa; p=clé_publique. Attention : vous devez connaître le sélecteur utilisé par votre plateforme d’envoi.
• DMARC : enregistrement TXT à l’adresse _dmarc.votre-domaine.fr, commençant par v=DMARC1.

Pour interroger le DNS directement, vous pouvez utiliser la commande dig sous Linux/macOS ou nslookup sous Windows. Exemples :

• dig TXT votre-domaine.fr (pour SPF)
• dig TXT selector1._domainkey.votre-domaine.fr (pour DKIM avec le sélecteur selector1)
• dig TXT _dmarc.votre-domaine.fr (pour DMARC)

Vérifier dans les en-têtes d’un e-mail. Envoyez un e-mail test depuis votre domaine vers une adresse Gmail ou Outlook personnelle. Dans Gmail, cliquez sur les trois points à droite du message puis Afficher l’original. Dans Outlook, ouvrez les propriétés du message. Cherchez l’en-tête Authentication-Results. Vous verrez quelque chose comme :

spf=pass smtp.mailfrom=votre-domaine.fr; dkim=pass header.d=votre-domaine.fr; dmarc=pass action=none header.from=votre-domaine.fr

Si vous voyez fail, softfail ou none pour l’un des protocoles, vous avez identifié un problème à corriger.

Outils de vérification SPF DKIM DMARC en ligne. Plusieurs outils gratuits permettent d’automatiser ces vérifications :

• MXToolbox : vérification SPF, DKIM (avec saisie du sélecteur), DMARC, et analyse des en-têtes.
• Mail-tester.com : envoyez un e-mail à une adresse générée, obtenez un score et le détail des vérifications.
• Google Admin Toolbox (Dig) : interface web pour interroger le DNS.
• DMARC Analyzer / Dmarcian : visualisation des rapports rua et détection des sources d’envoi inconnues.

Interpréter un DMARC check. Quand un outil de vérification DMARC indique un problème d’alignement, il précise généralement quel domaine est en cause. Par exemple : « DKIM alignment failed: d=mailprovider.com, header.from=votre-domaine.fr ». Cela signifie que votre outil d’envoi signe avec son propre domaine, pas le vôtre. La solution est de configurer un domaine d’envoi personnalisé chez ce prestataire.

Une fois que vous avez un diagnostic clair, vous pouvez passer à la mise en place ou à l’ajustement de votre politique DMARC.

Mettre en place DMARC: politiques, alignement et montée en charge sans casse

La principale raison pour laquelle des entreprises hésitent à activer DMARC en mode reject, c’est la peur de bloquer leurs propres e-mails légitimes. Cette peur est justifiée si la mise en place est précipitée. La méthode progressive élimine ce risque.

Phase 1 — Inventaire des expéditeurs. Avant de toucher à quoi que ce soit, listez tous les systèmes qui envoient des e-mails avec votre domaine : serveur de messagerie principal, CRM, outil de newsletter, plateforme transactionnelle, outil de support client, formulaires de contact, ERP… Chaque source doit être couverte par SPF et/ou DKIM avant de passer en mode restrictif.

Phase 2 — Démarrer avec p=none. Publiez un enregistrement DMARC minimal avec la politique none et une adresse de rapport rua :

v=DMARC1; p=none; rua=mailto:dmarc-rapports@votre-domaine.fr; ruf=mailto:dmarc-forensics@votre-domaine.fr; fo=1

Cette politique ne bloque rien. Elle vous envoie des rapports quotidiens sur tous les e-mails envoyés avec votre domaine, qu’ils passent ou non SPF/DKIM. Analysez ces rapports pendant au moins deux à quatre semaines. Vous découvrirez peut-être des sources d’envoi que vous aviez oubliées.

Phase 3 — Corriger SPF et DKIM pour toutes les sources. Pour chaque source identifiée dans les rapports qui échoue SPF ou DKIM ou dont l’alignement est cassé : ajoutez son IP ou son include dans votre enregistrement SPF, configurez DKIM avec un domaine aligné sur votre From.

Phase 4 — Passer à p=quarantine avec un pourcentage faible. La balise pct permet d’appliquer la politique à un pourcentage seulement des messages en échec. Commencez par :

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-rapports@votre-domaine.fr

Seulement 10 % des messages qui échouent DMARC seront mis en quarantaine. Les 90 % restants seront traités comme si la politique était none. Augmentez progressivement : 25 %, 50 %, 100 %. À chaque palier, vérifiez que vos e-mails légitimes ne sont pas affectés.

Phase 5 — Passer à p=reject. Une fois que vous êtes certain que tous vos expéditeurs légitimes passent DMARC, appliquez le rejet complet :

v=DMARC1; p=reject; rua=mailto:dmarc-rapports@votre-domaine.fr

À partir de ce moment, tout e-mail envoyé avec votre domaine qui ne passe pas DMARC est refusé par les serveurs destinataires compatibles. C’est la protection maximale contre le spoofing.

Alignement strict ou relaxed ? Par défaut, l’alignement est relaxed (adkim=r; aspf=r), ce qui signifie que les sous-domaines sont acceptés. En mode strict (adkim=s; aspf=s), le domaine doit correspondre exactement. L’alignement strict est recommandé pour les domaines qui n’utilisent pas de sous-domaines pour l’envoi, car il ferme une porte supplémentaire. Mais il peut casser des configurations où des sous-domaines sont utilisés comme Return-Path.

Cette méthode progressive permet de passer de zéro protection à p=reject sans jamais bloquer un e-mail légitime, à condition de suivre chaque étape. Les erreurs surviennent quand on brûle des étapes — voyons lesquelles sont les plus fréquentes.

Erreurs fréquentes et correctifs rapides (SPF, dKIM, dMARC)

Erreur 1 — Dépasser la limite des 10 lookups DNS pour SPF. Le protocole SPF limite à 10 le nombre de requêtes DNS supplémentaires (lookups) générées lors de l’évaluation de votre enregistrement. Chaque include:, a:, mx: ou redirect= compte. Si vous avez ajouté au fil du temps des includes pour Microsoft 365, Google Workspace, Brevo, OVH, Salesforce, Zendesk… vous avez probablement dépassé cette limite. Le résultat : SPF PermError, qui est traité comme un échec SPF.

Correctif : utilisez un outil de comptage de lookups SPF (MXToolbox ou kitterman.com/spf). Consolidez les IP dans un enregistrement dédié, ou utilisez un service de flattening SPF qui remplace les includes par leurs IPs résolues.

Erreur 2 — Plusieurs enregistrements SPF sur le même domaine. Il ne doit exister qu’un seul enregistrement TXT commençant par v=spf1 pour un domaine. Si vous en avez deux (souvent à cause d’une migration), le résultat est PermError. Fusionnez-les en un seul.

Erreur 3 — Absence de DKIM sur un outil marketing ou transactionnel. Vous avez configuré DKIM pour votre serveur principal, mais vous avez ajouté Brevo ou un autre outil sans configurer le DKIM correspondant. Ces e-mails passent peut-être SPF (si vous avez ajouté l’include), mais échouent DKIM. Si l’alignement SPF est aussi cassé (Return-Path du prestataire), DMARC échoue. Correctif : dans l’interface de chaque outil d’envoi, activez l’authentification DKIM avec votre domaine et publiez le sélecteur DKIM fourni dans votre DNS.

Erreur 4 — Sélecteur DKIM mal publié ou inexistant. Le sélecteur DKIM doit correspondre exactement à ce que le serveur d’envoi indique dans la signature (s=). Une faute de frappe dans le nom du sous-domaine DNS, ou un enregistrement publié sans propagation suffisante, provoque un échec DKIM. Vérifiez avec dig TXT sélecteur._domainkey.votre-domaine.fr que l’enregistrement existe et contient bien la clé publique.

Erreur 5 — Mauvais domaine dans le Return-Path (alignement SPF cassé). Quand un outil tiers envoie en votre nom, son Return-Path utilise souvent son propre domaine (bounce.prestataire.com). SPF passe pour ce domaine, mais l’alignement avec votre From échoue. Correctif : configurez un sous-domaine personnalisé pour les bounces chez votre prestataire (par exemple bounce.votre-domaine.fr) et déléguez-le ou ajoutez l’enregistrement SPF approprié.

Erreur 6 — DMARC sans rapports rua. Un enregistrement DMARC sans adresse rua vous prive de toute visibilité. Vous ne savez pas qui envoie avec votre domaine, ni si vos corrections ont fonctionné. Ajoutez toujours une adresse de rapport, même en phase de production.

Erreur 7 — Passer directement à p=reject sans audit préalable. C’est l’erreur la plus coûteuse. Sans avoir analysé les rapports rua, vous risquez de bloquer des e-mails légitimes (alertes automatiques, notifications ERP, e-mails de partenaires utilisant votre domaine en sous-traitance). Respectez la montée en charge décrite dans la section précédente.

Ces erreurs couvrent la grande majorité des cas rencontrés en pratique. Passons maintenant aux spécificités des principales plateformes.

Outils et cas pratiques: microsoft 365, gmail, oVH, brevo

Microsoft 365. Microsoft publie automatiquement un enregistrement SPF pour votre domaine lors de la configuration : include:spf.protection.outlook.com. Pour DKIM, il faut l’activer manuellement dans le portail Microsoft Defender (anciennement Security & Compliance Center), section Email & collaboration > Policies & rules > Threat policies > Email authentication settings. Microsoft génère deux sélecteurs (selector1 et selector2) et vous fournit les enregistrements CNAME à publier dans votre DNS. Ces CNAME pointent vers les enregistrements DKIM de Microsoft, qui gère la rotation des clés. Une fois activé, vérifiez avec dig TXT selector1._domainkey.votre-domaine.fr. Pour DMARC, Microsoft 365 ne le configure pas automatiquement — c’est à vous de publier l’enregistrement _dmarc.

Gmail / Google Workspace. Dans la console d’administration Google (Apps > Google Workspace > Gmail > Authentifier les e-mails), vous générez une clé DKIM et obtenez l’enregistrement TXT à publier avec le sélecteur google. L’enregistrement SPF à inclure est include:_spf.google.com. Google propose aussi un assistant de vérification SPF et DKIM directement dans la console. Pour les rapports DMARC, Gmail les envoie correctement si vous avez configuré l’adresse rua — les rapports agrégés de Google sont bien structurés et faciles à analyser.

OVH. OVH propose une interface DNS intégrée dans son espace client. Pour les domaines hébergés chez OVH avec un service e-mail OVH (MXplan, Exchange), des enregistrements SPF sont parfois préconfigurés. Vérifiez qu’ils correspondent à votre configuration réelle. Pour DKIM, OVH Exchange permet d’activer la signature DKIM depuis l’espace client. Pour les domaines OVH utilisés avec d’autres fournisseurs de messagerie, vous ajoutez manuellement les enregistrements TXT via le gestionnaire de zone DNS. Attention aux TTL courts lors des modifications pour accélérer la propagation.

Brevo (ex-Sendinblue). Brevo est une plateforme d’envoi transactionnel et marketing. Pour l’authentification, Brevo fournit dans ses paramètres de domaine (Expéditeurs > Domaines) les enregistrements TXT à publier pour SPF (un include spécifique à Brevo) et pour DKIM (un sélecteur propre à Brevo). Publiez ces enregistrements dans votre DNS, puis validez dans l’interface Brevo. Le Return-Path des e-mails Brevo utilise un sous-domaine Brevo par défaut, ce qui casse l’alignement SPF. Pour corriger cela, Brevo permet de configurer un sous-domaine personnalisé pour les bounces — activez cette option et déléguez le sous-domaine à Brevo. Résultat : alignement SPF et DKIM corrects, DMARC passe.

Outils de visualisation des rapports DMARC. Les rapports rua arrivent en XML brut, illisibles directement. Utilisez :

• Dmarcian : interface claire, plan gratuit disponible, détection des sources inconnues.
• DMARC Analyzer : visualisation par source d’envoi, alertes sur les nouvelles sources.
• Postmark DMARC : service gratuit pour les petits volumes, rapports hebdomadaires par e-mail.
• Google Postmaster Tools : si vos destinataires sont majoritairement sur Gmail, cet outil donne la réputation de votre domaine et de vos IPs d’envoi.

Ces outils permettent de détecter rapidement si une source inconnue envoie avec votre domaine — signe possible d’une tentative de spoofing en cours ou d’un outil oublié dans votre inventaire.

FAQ

C’est quoi SPF DKIM DMARC ?

SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting, and Conformance) sont trois protocoles d’authentification des e-mails qui fonctionnent ensemble. SPF liste les serveurs autorisés à envoyer en votre nom, DKIM signe cryptographiquement chaque message pour garantir son intégrité, et DMARC définit la politique à appliquer quand SPF ou DKIM échoue, en vérifiant l’alignement avec l’adresse From visible par le destinataire.

Que sont SPF, dKIM et DMARC ?

Ce sont des standards publiés dans des enregistrements DNS de type TXT qui permettent aux serveurs de messagerie destinataires de vérifier qu’un e-mail provient bien du domaine qu’il prétend représenter. Ensemble, ils protègent contre l’usurpation d’e-mail (spoofing) et le phishing, et améliorent la délivrabilité des e-mails légitimes.

Quels outils permettent de bloquer les mails phishing ?

DMARC avec la politique p=reject est le mécanisme le plus efficace pour bloquer les e-mails de phishing usurpant votre domaine exact. Pour la détection et la visualisation, des outils comme MXToolbox, Dmarcian, DMARC Analyzer et Google Postmaster Tools permettent d’identifier les sources d’envoi suspectes. Les filtres anti-spam des fournisseurs (Microsoft Defender, Google Workspace) utilisent aussi ces signaux d’authentification pour classer les messages.

Comment puis-je vérifier mon SPF, dKIM et DMARC ?

Trois méthodes complémentaires : interrogez votre DNS avec dig TXT pour vérifier l’existence et le contenu des enregistrements ; envoyez un e-mail test et inspectez l’en-tête Authentication-Results dans le message reçu ; utilisez des outils en ligne comme MXToolbox ou Mail-tester.com pour une analyse automatisée avec interprétation des résultats et détection des problèmes d’alignement.

SPF, DKIM et DMARC ne sont pas des options réservées aux grandes entreprises. Tout domaine qui envoie des e-mails professionnels est une cible potentielle d’usurpation. La mise en place prend quelques heures, la montée en charge quelques semaines — et le résultat est une protection durable de votre réputation, de vos clients et de votre délivrabilité.