Le spoofing email - l’envoi d’un message dont l’adresse d’expéditeur est usurpée - reste l’un des vecteurs les plus efficaces pour le phishing et les campagnes de malware. Pourtant, les mécanismes pour s’en protéger existent depuis des années. Le problème n’est pas technique : c’est la dispersion de la documentation et la complexité perçue qui freinent leur adoption.
Ce guide couvre la configuration complète pour un propriétaire de domaine qui utilise un hébergeur de boîtes mail et éventuellement un ou plusieurs ESP (Email Service Provider) pour des envois en nombre. Il ne couvre pas la configuration d’un serveur SMTP sortant (Postfix, OpenDKIM, etc.) : il part du principe que quelqu’un d’autre émet pour vous, et que vous devez simplement autoriser et signer correctement.
Note d’attribution : ce guide s’appuie notamment sur la série de Yanal-Yves Fargialla consacrée à SPF, DKIM, DMARC et BIMI. Il en propose une synthèse condensée, complétée par des vérifications opérationnelles, des sources normatives et quelques choix de configuration pragmatiques.
En bref#
SPF, DKIM et DMARC sont les trois mécanismes complémentaires qui protègent un domaine contre l’usurpation d’identité email. SPF autorise les serveurs d’envoi, DKIM signe cryptographiquement les messages, DMARC coordonne les deux et dicte la conduite à tenir en cas d’échec. BIMI ajoute un logo vérifié dans les boîtes aux lettres compatibles. Ensemble, ils forment la base réaliste de protection contre le spoofing, le phishing et l’usurpation de marque par email.
Ce guide vous explique comment les configurer, dans l’ordre, avec les vérifications qui comptent.
Architecture et concepts#
Avant de plonger dans les enregistrements DNS, il faut comprendre le flux d’un email et les trois acteurs impliqués.
Quand vous envoyez un email depuis contact@votre-domaine.fr :
- Votre MUA (Thunderbird, Gmail, Outlook) transmet le message à votre serveur SMTP sortant (celui de votre hébergeur)
- Ce serveur le remet au serveur SMTP destinataire (celui du destinataire)
- Le serveur destinataire vérifie l’authenticité du message avant de le déposer dans la boîte de réception
La difficulté est que l’enveloppe SMTP (le return-path, aussi appelé MAIL FROM) et l’en-tête From: visible par l’utilisateur peuvent pointer vers des domaines différents. C’est notamment le cas quand vous passez par un ESP comme Mailjet, SendGrid ou Amazon SES : le return-path est leur domaine, le From: est le vôtre.
C’est cette divergence que DMARC est censé contrôler, en imposant un alignement entre le domaine visible par l’utilisateur et au moins un mécanisme d’authentification valide.
Impact réel#
Une configuration correcte ne garantit pas que tous vos messages arriveront en boîte de réception. La délivrabilité dépend aussi de la réputation de l’IP, du domaine, du contenu, du volume d’envoi et des plaintes utilisateurs.
En revanche, SPF, DKIM et DMARC réduisent fortement deux risques concrets :
- un tiers qui envoie des messages avec votre domaine dans le
From: - un prestataire légitime mal configuré qui échoue chez Gmail, Outlook ou Yahoo
Depuis 2024, Gmail impose aussi des exigences plus strictes aux expéditeurs, surtout pour les volumes importants : authentification SPF/DKIM, DMARC, reverse DNS valide, TLS et désinscription facile pour les emails marketing. Même pour un petit domaine, ces mécanismes ne sont plus seulement des bonnes pratiques de sécurité. Ils font partie du socle minimal de délivrabilité.
FCrDNS (Forward-Confirmed reverse DNS)#
Avant même SPF, un prérequis souvent négligé est le FCrDNS : votre serveur d’envoi doit avoir un enregistrement PTR (reverse DNS) qui correspond à son nom d’hôte, et ce nom d’hôte doit résoudre vers l’IP du serveur.
C’est un mécanisme de réputation de base. Les principaux fournisseurs de boîtes mail (Gmail, Outlook, Yahoo) le vérifient. Sans FCrDNS, vos emails risquent d’être marqués comme spam, même avec SPF et DKIM valides.
Vérification :
# Reverse DNS de l'IP du serveur
dig -x 1.2.3.4 +short
# Vérifier que le nom obtenu résout bien vers l'IP
dig mail.votre-domaine.fr +shortLes deux commandes doivent former une boucle cohérente. Si votre hébergeur ne vous donne pas la main sur le PTR, demandez-lui de le positionner correctement.
SPF (Sender Policy Framework)#
SPF permet de déclarer dans le DNS quelles adresses IP sont autorisées à émettre des emails pour un domaine utilisé dans l’enveloppe SMTP. En pratique, c’est surtout le domaine du MAIL FROM, souvent visible comme return-path, qui est évalué.
L’enregistrement SPF se place sur le domaine racine (ou un sous-domaine spécifique) sous la forme d’un enregistrement TXT :
v=spf1 ip4:1.2.3.4 include:_spf.google.com ~allLes mécanismes principaux :
ip4:/ip6:- autorise une IP ou un blocinclude:- délègue à un autre domaine SPF, pratique pour les ESPa:- autorise l’IP correspondant au record A du domainemx:- autorise les IP des serveurs MX du domaineall- la règle finale :-all(fail),~all(softfail),?all(neutre)
La règle -all est recommandée à terme, mais attention : le transfert d’email (forwarding) casse souvent SPF car l’enveloppe est conservée alors que l’IP du relais change. DMARC ne répare pas SPF dans ce cas. Il permet surtout au message de rester légitime si DKIM passe encore et si la signature est alignée avec le domaine du From:. Tant que vous n’avez pas observé vos flux réels, ~all est plus prudent.
Cas des ESP#
Un point souvent mal compris : le SPF que le destinataire vérifie est celui du domaine du return-path, pas directement celui du From: visible par l’utilisateur. Or, les ESP (Mailjet, SendGrid, etc.) peuvent utiliser leur propre domaine de rebond, ou un sous-domaine personnalisé que vous déléguez.
Exemple concret : si votre message part avec From: contact@votre-domaine.fr, mais un return-path du type bounce.esp.example, SPF sera évalué sur le domaine de rebond de l’ESP. Si vous configurez un domaine de rebond personnalisé comme bounce.votre-domaine.fr, SPF redevient pertinent côté domaine. C’est aussi ce qui permet à SPF d’être aligné pour DMARC.
Ce qui compte vraiment, c’est de vérifier le return-path réel de chaque flux. Pour vos envois directs où le return-path est bien votre domaine, votre SPF doit autoriser l’infrastructure qui émet. Pour les ESP, privilégiez un domaine de rebond personnalisé et aligné, quand le prestataire le permet.
Vérification#
dig txt votre-domaine.fr +short | grep "v=spf1"DKIM (DomainKeys Identified Mail)#
DKIM ajoute une signature cryptographique dans l’en-tête du message. Le serveur destinataire vérifie cette signature en récupérant une clé publique publiée dans le DNS.
Contrairement à SPF, DKIM survit souvent au transfert d’email : la signature est portée par un en-tête DKIM-Signature et couvre le corps du message ainsi qu’une sélection d’en-têtes. Elle ne dépend pas de l’IP du relais SMTP. C’est ce qui fait sa force, même si certaines modifications du message par une liste de diffusion ou une passerelle peuvent casser la signature.
Fonctionnement#
- Le serveur d’envoi signe le message avec une clé privée
- Il ajoute un en-tête
DKIM-Signaturequi contient notamment le sélecteur et le domaine - Le serveur destinataire récupère la clé publique via
selecteur._domainkey.votre-domaine.fr - Il vérifie la signature
La configuration côté DNS :
selector1._domainkey.votre-domaine.fr IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb4... long"La clé privée reste côté serveur d’envoi. Chaque hébergeur ou ESP génère sa propre paire de clés et vous fournit l’enregistrement à publier. Si le prestataire le permet, préférez une clé DKIM de 2048 bits.
Sélecteurs multiples#
Si vous utilisez plusieurs prestataires (hébergeur de boîtes + ESP), vous aurez plusieurs sélecteurs DKIM, un par prestataire. C’est normal.
Vérification#
dig txt selector1._domainkey.votre-domaine.fr +shortLa commande doit retourner un enregistrement commençant par v=DKIM1.
DMARC (Domain-based Message Authentication, Reporting & Conformance)#
DMARC est le chef d’orchestre. Il définit :
- Quel mécanisme d’authentification utiliser (SPF, DKIM ou les deux)
- Quel alignement exiger entre le
From:et les domaines vérifiés - Que faire en cas d’échec (aucun, quarantaine, rejet)
- Où envoyer les rapports d’analyse
Politique DMARC#
L’enregistrement DMARC se place sur _dmarc.votre-domaine.fr :
_dmarc.votre-domaine.fr IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@votre-domaine.fr"Les politiques possibles :
p=none- ne rien faire, seulement collecter les rapportsp=quarantine- demander la mise en quarantaine des messages en échec, souvent en spamp=reject- demander le rejet des messages en échec, recommandé à terme
Alignement#
L’alignement DMARC peut être strict (s) ou relâché (r) :
- DKIM aligné : le domaine de la signature DKIM doit correspondre au domaine du
From: - SPF aligné : le domaine du return-path doit correspondre au domaine du
From:
Pour l’alignement strict, les domaines doivent être identiques. Pour l’alignement relâché, le sous-domaine est ignoré (ex: mail.votre-domaine.fr est aligné avec votre-domaine.fr).
La configuration recommandée pour commencer reste volontairement permissive :
v=DMARC1; p=none; adkim=r; aspf=r; pct=100; rua=mailto:dmarc-reports@votre-domaine.frLe mode relâché (r) évite de casser inutilement les flux qui utilisent des sous-domaines techniques, par exemple bounce.votre-domaine.fr. Une fois les flux stabilisés, vous pouvez durcir progressivement avec adkim=s, aspf=s, sp=quarantine, puis p=quarantine ou p=reject.
Rapports#
rua reçoit les rapports agrégés DMARC, généralement sous forme de fichiers XML envoyés périodiquement par les serveurs destinataires. Ces rapports vous permettent de savoir qui émet pour votre domaine, combien de messages passent ou échouent, et quel mécanisme a permis l’alignement.
ruf correspond aux rapports d’échec détaillés. En pratique, beaucoup d’opérateurs ne les envoient pas ou les limitent fortement pour des raisons de confidentialité. Pour un domaine classique, commencez par rua et ajoutez ruf seulement si vous savez quoi en faire.
Des outils comme dmarcian ou postmarkapp facilitent l’analyse de ces rapports sans avoir à parser le XML manuellement.
Migration progressive#
- Commencez par
p=noneet collectez les rapports pendant 1-2 semaines - Identifiez les sources légitimes qui ne passent pas l’authentification
- Corrigez SPF et DKIM pour ces sources
- Durcissez éventuellement l’alignement (
adkim=s,aspf=s) si vos flux le supportent - Passez à
p=quarantine, éventuellement avecpct=25oupct=50 - Quand tout est stable, passez à
p=reject
Ne passez pas directement à p=reject sans cette phase d’observation, sous peine de bloquer vos propres emails.
Vérification#
dig txt _dmarc.votre-domaine.fr +shortBIMI (Brand Indicators for Message Identification)#
BIMI permet d’afficher un logo vérifié à côté de vos emails dans les boîtes aux lettres qui le supportent, par exemple Apple Mail, Gmail, Yahoo ou Fastmail selon les conditions propres à chaque fournisseur.
Le principe est simple : si vos emails passent DMARC avec une politique suffisamment stricte (p=quarantine ou p=reject), vous pouvez publier un enregistrement BIMI pointant vers votre logo au format SVG Tiny P/S.
default._bimi.votre-domaine.fr IN TXT "v=BIMI1; l=https://votre-domaine.fr/logo.svg; a=https://votre-domaine.fr/logo-certificate.pem"Le a= est optionnel et correspond à un certificat VMC (Verified Mark Certificate) qui atteste de votre marque. Sans ce certificat, certains fournisseurs (notamment Gmail) n’affichent pas le logo.
Limites de BIMI#
- Nécessite DMARC en
p=quarantineoup=reject, ce qui suppose que la chaîne SPF/DKIM/DMARC est déjà maîtrisée - Le certificat VMC coûte plusieurs centaines d’euros par an et n’est pas accessible à tout le monde
- L’affichage dépend du fournisseur, de la réputation du domaine et parfois d’un certificat VMC
- C’est un signal de marque, pas un mécanisme de sécurité supplémentaire
BIMI est un bonus visuel, pas une protection. Ne le priorisez pas avant d’avoir SPF, DKIM et DMARC correctement configurés.
Vérifier son exposition#
Voici la séquence de commandes à exécuter pour vérifier l’état de votre domaine :
# 1. SPF
dig txt votre-domaine.fr +short | grep "v=spf1"
# 2. DKIM (remplacer selector1 par le sélecteur de votre prestataire)
dig txt selector1._domainkey.votre-domaine.fr +short
# 3. DMARC
dig txt _dmarc.votre-domaine.fr +short
# 4. BIMI
dig txt default._bimi.votre-domaine.fr +short
# 5. FCrDNS (remplacer 1.2.3.4 par l'IP du serveur SMTP sortant)
dig -x 1.2.3.4 +short
dig mail.votre-domaine.fr +shortCes commandes vérifient la publication DNS. Elles ne remplacent pas un test réel.
Envoyez un email depuis chaque source légitime (hébergeur mail, outil de newsletter, application métier, CRM) vers une boîte Gmail ou Outlook, puis inspectez les en-têtes complets. Cherchez notamment :
Authentication-Results:
spf=pass
dkim=pass
dmarc=passVérifiez aussi les domaines associés :
- SPF doit passer sur le domaine du
return-path - DKIM doit passer avec un
d=aligné avec le domaine duFrom:, au moins en mode relâché - DMARC doit passer grâce à SPF aligné ou DKIM aligné
Des outils en ligne comme MXToolbox ou app.dmarcanalyzer.com permettent une vérification complète sans taper de commandes.
Détection#
La détection repose surtout sur les rapports DMARC et sur les journaux de votre fournisseur d’email. Les rapports rua permettent d’identifier :
- les IP qui envoient réellement pour votre domaine
- les sources légitimes qui échouent SPF, DKIM ou DMARC
- les tentatives d’usurpation où le domaine
From:est le vôtre mais aucun mécanisme n’est aligné
Sur un serveur SMTP que vous administrez, les logs peuvent aussi confirmer les rejets ou les quarantaines côté destinataire :
journalctl -u postfix --since "24 hours ago" | grep -Ei "dmarc|dkim|spf|reject|bounce"Cette commande n’a de sens que si vous exploitez réellement le serveur sortant. Avec un hébergeur mail ou un ESP, utilisez plutôt leurs journaux d’événements et les rapports DMARC.
Correctifs et mitigations#
La correction doit rester progressive. Le bon ordre est rarement de tout durcir d’un coup.
- Publiez SPF et DKIM pour chaque source d’envoi légitime
- Activez DMARC en
p=noneavecrua - Analysez les rapports pendant quelques jours ou quelques semaines selon le volume
- Corrigez les sources qui échouent, surtout les ESP et applications métier
- Passez à
p=quarantine, éventuellement avecpct=25oupct=50 - Passez à
p=rejectquand les flux légitimes sont stables
Pour un domaine qui ne doit jamais envoyer d’email, la posture est plus simple :
v=spf1 -all_dmarc.votre-domaine.fr IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@votre-domaine.fr"Si le domaine ne reçoit pas d’email non plus, publiez un Null MX :
votre-domaine.fr. IN MX 0 .Cette configuration réduit le risque qu’un domaine dormant soit utilisé comme leurre dans une campagne de phishing.
Erreurs fréquentes#
| Erreur | Problème | Solution |
|---|---|---|
SPF avec trop de lookup | SPF est limité à 10 requêtes DNS | Utilisez un sous-domaine dédié ou fusionnez les includes redondants |
| DKIM sans sélecteur unique | Les prestataires doivent avoir leur propre sélecteur | Utilisez un sélecteur par prestataire |
DMARC en p=reject sans phase p=none | Vous bloquez vos propres emails | Passez d’abord par p=none et analysez les rapports |
| BIMI sans politique DMARC stricte | BIMI exige DMARC en quarantine ou reject | Configurez DMARC d’abord |
| Oubli du PTR | Délivrabilité réduite, spam | Vérifiez le reverse DNS auprès de votre hébergeur |
La limite des 10 lookup SPF est une contrainte bien connue. Chaque include:, a:, mx:, exists: et redirect= peut déclencher des requêtes DNS comptabilisées. Si vous dépassez cette limite, le résultat SPF doit être traité comme un permerror. Solution : passez par un sous-domaine dédié (ex: mail.votre-domaine.fr) avec un SPF simplifié, retirez les prestataires inutilisés ou demandez à l’ESP une configuration avec domaine de rebond dédié.
Conclusion#
SPF, DKIM et DMARC forment un triptyque indispensable pour tout domaine qui envoie des emails. BIMI est un bonus visuel agréable mais secondaire.
L’ordre de priorité est simple :
- FCrDNS (reverse DNS)
- SPF (
~alld’abord,-allaprès validation) - DKIM (une clé par prestataire)
- DMARC (en commençant par
p=noneet des rapportsrua) - BIMI (si DMARC est stable et le budget le permet)
Ne cherchez pas à tout faire en un jour. La phase p=none de DMARC est là pour ça : elle vous permet d’observer et de corriger sans casser votre délivrabilité.
Comme toujours en matière de sécurité email, la perfection est l’ennemie du bien. Une configuration partielle mais correcte (SPF + DKIM, avec DMARC en p=none) est déjà plus efficace que rien.
Sources#
- RFC 7208 - Sender Policy Framework (SPF)
- RFC 6376 - DomainKeys Identified Mail (DKIM)
- RFC 7489 - Domain-based Message Authentication, Reporting & Conformance (DMARC)
- RFC 5321 - Simple Mail Transfer Protocol
- RFC 7505 - A Null MX No Service Resource Record for Domains That Accept No Mail
- Yanal-Yves Fargialla - Antispoofing e-mail : SPF, DKIM, DMARC, BIMI
- Google - Email sender guidelines
- Google Workspace - Set up BIMI
- IETF - Brand Indicators for Message Identification draft
- MXToolbox - SPF/DKIM/DMARC lookup
- Cloudflare - What is email spoofing?
- Postmark - DMARC guide
