Configurer SPF, DKIM et DMARC : le guide complet pour protéger votre domaine email
Guide technique étape par étape pour configurer SPF, DKIM et DMARC sur votre domaine. Exemples concrets pour OVH, Google Workspace et Microsoft 365. Vérification et dépannage inclus.
Quelqu'un envoie un email depuis contact@votredomaine.fr. Le destinataire reçoit le message, voit votre nom, votre adresse, peut-être même votre logo. Le problème : ce n'est pas vous qui l'avez envoyé.
Sans SPF, DKIM et DMARC, n'importe qui peut envoyer un email en se faisant passer pour votre domaine. Pas besoin de pirater votre boîte mail. Pas besoin de mot de passe. Le protocole SMTP, conçu en 1982, n'intègre aucun mécanisme d'authentification de l'expéditeur. C'est exactement comme une lettre postale : n'importe qui peut écrire n'importe quelle adresse d'expéditeur sur l'enveloppe.
En 2025, 3,4 milliards d'emails de phishing sont envoyés chaque jour dans le monde (Radicati Group, 2025). La plupart utilisent des domaines usurpés. Et selon une étude Agari de 2024, 80 % des domaines d'entreprises françaises n'ont pas de politique DMARC active (p=quarantine ou p=reject). En d'autres termes, 4 entreprises sur 5 laissent la porte ouverte à l'usurpation de leur identité email.
Ce guide vous accompagne, étape par étape, dans la configuration de SPF, DKIM et DMARC. Vous n'avez pas besoin d'être expert DNS. Si vous savez ajouter un enregistrement TXT dans l'interface de votre registrar (OVH, Gandi, Cloudflare, Google Domains), vous pouvez protéger votre domaine en moins d'une heure.
Avant de commencer, testez gratuitement la configuration actuelle de votre domaine. Notre outil vérifie vos enregistrements SPF, DKIM, DMARC et BIMI en quelques secondes et vous donne un score sur 10 avec des recommandations.
Comprendre le trio SPF, DKIM, DMARC
Avant de configurer quoi que ce soit, une compréhension claire de ce que fait chaque protocole est nécessaire. Ils ne font pas la même chose, et aucun ne suffit seul.
SPF : qui a le droit d'envoyer ?
SPF (Sender Policy Framework) est un enregistrement DNS de type TXT publié à la racine de votre domaine. Il liste les adresses IP et les domaines autorisés à envoyer des emails pour votre compte.
Quand un serveur reçoit un email prétendant venir de @votredomaine.fr, il consulte le record SPF de votredomaine.fr et vérifie si l'IP du serveur expéditeur figure dans la liste. Si oui, le contrôle SPF passe. Si non, il échoue.
Exemple de record SPF :
v=spf1 include:_spf.google.com include:spf.brevo.com -all
Ce record autorise Google Workspace et Brevo à envoyer des emails pour le domaine. Tous les autres serveurs sont rejetés (-all).
Limites de SPF :
- SPF vérifie le domaine du « Return-Path » (enveloppe), pas le domaine du « From » (en-tête visible par l'utilisateur). Un attaquant peut utiliser un Return-Path légitime tout en affichant un faux From.
- SPF ne résiste pas au transfert d'email. Quand un email est transféré, l'IP du serveur intermédiaire ne figure pas dans le SPF du domaine d'origine, et le contrôle échoue.
- SPF est limité à 10 lookups DNS (résolutions récursives). Au-delà, le contrôle échoue automatiquement (résultat PermError).
DKIM : le message a-t-il été modifié ?
DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email sortant. Le serveur d'envoi signe le message avec une clé privée. La clé publique correspondante est publiée en DNS sous un enregistrement TXT.
Quand un serveur reçoit l'email, il récupère la clé publique en DNS et vérifie que la signature correspond au contenu du message. Si quelqu'un a modifié le corps ou les en-têtes de l'email en transit, la signature ne correspond plus.
Exemple de record DKIM :
google._domainkey.votredomaine.fr TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
Le sélecteur (ici « google ») identifie quelle clé utiliser. Un domaine peut avoir plusieurs sélecteurs pour différents services d'envoi.
Avantage sur SPF : DKIM survit au transfert d'email. La signature reste valide même après un acheminement via un serveur intermédiaire, car elle est attachée au message lui-même, pas à l'IP du serveur.
DMARC : la politique de décision
DMARC (Domain-based Message Authentication, Reporting & Conformance) est le chef d'orchestre. Il ne vérifie rien par lui-même. Il fait deux choses :
- Alignement : il vérifie que le domaine dans le « From » correspond au domaine validé par SPF ou DKIM. Sans DMARC, un email peut passer SPF (sur le Return-Path) tout en affichant un domaine frauduleux dans le From visible par l'utilisateur.
- Politique : il indique aux serveurs destinataires ce qu'il faut faire quand un email échoue aux vérifications :
p=none- ne rien faire (observation uniquement)p=quarantine- mettre en spamp=reject- refuser le message
Exemple de record DMARC :
_dmarc.votredomaine.fr TXT "v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine.fr; fo=1"
Ce record demande aux serveurs de rejeter tout email qui échoue aux vérifications, et d'envoyer des rapports agrégés à dmarc@votredomaine.fr.
Sans DMARC, SPF et DKIM ne servent qu'à moitié. Un attaquant peut envoyer un email avec un Return-Path sous un domaine qu'il contrôle (passe SPF sur son propre domaine) tout en affichant votre adresse dans le From. Sans DMARC, le serveur destinataire n'a aucune instruction pour bloquer ce message.
Comment les trois fonctionnent ensemble
Email reçu par le serveur destinataire
↓
1. Vérification SPF : l'IP de l'expéditeur est-elle autorisée ?
↓
2. Vérification DKIM : la signature cryptographique est-elle valide ?
↓
3. Vérification DMARC :
- Le domaine du From est-il aligné avec SPF ou DKIM ?
- Si oui → email accepté
- Si non → appliquer la politique (none/quarantine/reject)
↓
4. Rapport DMARC envoyé au propriétaire du domaine
Un email n'a besoin de passer qu'un seul des deux contrôles (SPF ou DKIM) avec un alignement valide pour être accepté par DMARC. C'est un « OU », pas un « ET ». En pratique, configurez les deux : SPF pour les cas simples, DKIM pour les cas où l'email est transféré.
Étape 1 : inventorier vos sources d'envoi
Avant de toucher au DNS, listez tous les services qui envoient des emails pour votre domaine. Oublier un service = ses emails seront bloqués quand vous activerez une politique stricte.
Sources courantes :
| Catégorie | Exemples | Mécanisme SPF typique |
|---|---|---|
| Messagerie principale | Google Workspace, Microsoft 365 | include:_spf.google.com ou include:spf.protection.outlook.com |
| Marketing / newsletter | Brevo, Mailjet, Mailchimp, HubSpot | include:spf.brevo.com, include:servers.mcsv.net |
| Transactionnel | SendGrid, Postmark, Amazon SES | include:sendgrid.net, include:amazonses.com |
| CRM | Salesforce, Pipedrive, HubSpot | include:_spf.salesforce.com |
| Support | Zendesk, Freshdesk, Intercom | include:mail.zendesk.com |
| Facturation | Stripe, QuickBooks, Pennylane | Varie selon le service |
| Serveur applicatif | VPS, serveur dédié | ip4:X.X.X.X |
Comment les trouver :
- Demandez à chaque service : « Est-ce que vous envoyez des emails pour notre domaine ? »
- Vérifiez les enregistrements SPF/DKIM existants de votre domaine (si vous en avez).
- Si vous avez déjà un record DMARC en p=none avec rua=, analysez les rapports pour découvrir les sources d'envoi que vous avez oubliées.
Étape 2 : configurer SPF
Construire le record
Le format est strict : un seul enregistrement TXT à la racine du domaine, commençant par v=spf1, suivi des mécanismes d'autorisation, terminé par une directive -all ou ~all.
Pour Google Workspace :
v=spf1 include:_spf.google.com -all
Pour Microsoft 365 :
v=spf1 include:spf.protection.outlook.com -all
Pour Google Workspace + Brevo + un serveur dédié :
v=spf1 include:_spf.google.com include:spf.brevo.com ip4:203.0.113.42 -all
Publier dans le DNS
La procédure varie selon votre registrar.
OVH :
- Connectez-vous au Manager OVH → Noms de domaine → votredomaine.fr → Zone DNS
- Cliquez « Ajouter une entrée » → Type TXT
- Sous-domaine : laissez vide (racine)
- TTL : 3600
- Valeur : votre record SPF complet
- Validez
Cloudflare :
- Dashboard → sélectionnez le domaine → DNS → Records
- Add Record → Type TXT → Name : @ → Content : votre record SPF
- Save
Google Domains / Squarespace :
- DNS → Custom Records → Manage
- Type TXT → Host name : laisser vide → Data : votre record SPF
- Save
Erreurs fréquentes
Deux records SPF. Un domaine ne doit avoir qu'un seul enregistrement SPF. Si vous avez déjà un record SPF et que vous devez ajouter un service, modifiez le record existant en ajoutant un include: supplémentaire. Ne créez pas un second record TXT commençant par v=spf1.
Dépasser 10 lookups. Chaque include: compte comme un lookup. Chaque include: peut lui-même contenir des include: imbriqués. Google Workspace seul en consomme 4. Si vous dépassez 10, le résultat est PermError et SPF est ignoré. Comptez vos lookups avec un outil de vérification. Si vous approchez de la limite, remplacez les include: par des ip4: ou ip6: directs quand c'est possible, ou utilisez un service de « SPF flattening ».
Oublier le -all final. Sans directive « all », le record est incomplet. Les serveurs destinataires ne savent pas quoi faire des expéditeurs non listés. Résultat : aucune protection.
Étape 3 : configurer DKIM
DKIM est plus complexe que SPF car il nécessite une configuration à la fois côté DNS (clé publique) et côté service d'envoi (clé privée pour signer les messages).
Google Workspace
- Admin Console → Apps → Google Workspace → Gmail → Authentifier les emails
- Sélectionnez votre domaine → « Générer un nouvel enregistrement »
- Longueur de clé : 2048 bits (recommandé)
- Sélecteur : « google » (par défaut)
- Google vous donne un enregistrement TXT à publier sous
google._domainkey.votredomaine.fr - Publiez l'enregistrement dans votre DNS
- Attendez 15 à 60 minutes, puis revenez dans la console Admin et cliquez « Démarrer l'authentification »
Record DNS à créer :
Type : TXT
Nom : google._domainkey
Valeur : v=DKIM1; k=rsa; p=MIIBIjANBg... (la clé fournie par Google)
Microsoft 365
Microsoft 365 active DKIM automatiquement pour les domaines *.onmicrosoft.com. Pour votre domaine personnalisé :
- Microsoft Defender → Stratégies & règles → Stratégies de menace → Email authentication settings → DKIM
- Sélectionnez votre domaine
- Microsoft vous donne deux enregistrements CNAME à publier :
selector1._domainkey.votredomaine.fr→selector1-votredomaine-fr._domainkey.votredomaine.onmicrosoft.comselector2._domainkey.votredomaine.fr→selector2-votredomaine-fr._domainkey.votredomaine.onmicrosoft.com
- Publiez les CNAME dans votre DNS
- Attendez la propagation, puis activez la signature DKIM dans la console
Brevo (ex-Sendinblue)
- Paramètres → Expéditeurs & IP → Domaines
- Ajoutez votre domaine
- Brevo génère un enregistrement DKIM (TXT) à publier
- Publiez-le dans votre DNS
- Cliquez « Vérifier » dans Brevo
Mailjet
- Paramètres du compte → Domaines d'envoi → Ajouter un domaine
- Mailjet fournit un record TXT DKIM
- Publiez dans votre DNS
- Validez
Vérifier que DKIM fonctionne
Envoyez un email à une adresse Gmail depuis votre domaine. Ouvrez l'email reçu → menu ⋮ → « Afficher l'original ». Cherchez la ligne dkim=pass. Si vous voyez dkim=fail ou que DKIM n'apparaît pas, la signature n'est pas active.
Vous pouvez aussi utiliser notre outil de vérification DNS qui détecte automatiquement les sélecteurs DKIM courants et vérifie que la clé est publiée.
Étape 4 : configurer DMARC
Le record de départ
Commencez avec une politique non-bloquante pour observer avant de bloquer :
_dmarc.votredomaine.fr TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@votredomaine.fr; fo=1"
Signification :
v=DMARC1- version du protocolep=none- politique : observer mais ne rien bloquer (phase de test)rua=mailto:dmarc-reports@votredomaine.fr- adresse pour recevoir les rapports agrégés (XML, envoyés quotidiennement par les serveurs destinataires)fo=1- envoyer un rapport d'échec pour chaque email qui échoue (utile pour le diagnostic)
Publier dans le DNS
Comme pour SPF, ajoutez un enregistrement TXT dans votre zone DNS :
| Type | Nom | Valeur |
|---|---|---|
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc-reports@votredomaine.fr; fo=1 |
Analyser les rapports
Les rapports DMARC sont des fichiers XML envoyés par les serveurs de messagerie (Gmail, Microsoft, Yahoo, etc.) qui traitent des emails prétendant venir de votre domaine. Ils contiennent :
- L'IP du serveur expéditeur
- Le résultat SPF (pass/fail)
- Le résultat DKIM (pass/fail)
- L'alignement DMARC (pass/fail)
- Le nombre d'emails par source
Les rapports bruts sont des fichiers XML compressés en ZIP ou GZ. Ils sont lisibles mais peu pratiques. Des outils gratuits facilitent l'analyse : DMARC Analyzer (dmarcian), Postmark DMARC, ou simplement votre client email si le volume est faible.
Ce qu'il faut chercher :
- Des lignes avec
disposition=noneetdkim=failouspf=failprovenant d'adresses IP que vous reconnaissez → un service légitime mal configuré (à corriger). - Des lignes avec des IP inconnues et
dkim=fail+spf=fail→ des tentatives d'usurpation (exactement ce que DMARC doit bloquer).
Monter progressivement la politique
Le processus recommandé :
- p=none pendant 2 à 4 semaines. Analysez les rapports. Identifiez et corrigez les sources légitimes qui échouent.
- p=quarantine; pct=25 - mettez en spam 25 % des emails qui échouent. Montez progressivement (50 %, 75 %, 100 %).
- p=reject - bloquez totalement les emails frauduleux. C'est l'objectif final.
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@votredomaine.fr; fo=1
Puis, quand vous êtes confiant :
v=DMARC1; p=reject; rua=mailto:dmarc-reports@votredomaine.fr; fo=1
Options avancées DMARC
| Paramètre | Description | Exemple |
|---|---|---|
sp= | Politique pour les sous-domaines | sp=reject |
adkim= | Alignement DKIM strict (s) ou relaxé (r) | adkim=s |
aspf= | Alignement SPF strict (s) ou relaxé (r) | aspf=r |
pct= | Pourcentage d'emails soumis à la politique | pct=50 |
ruf= | Adresse pour les rapports d'échec individuels (forensic) | ruf=mailto:... |
Recommandation : adkim=r et aspf=r (relaxé, par défaut) pour commencer. Le mode relaxé accepte les sous-domaines (ex: mail.votredomaine.fr passe l'alignement pour votredomaine.fr). Passez en strict seulement si vous avez un contrôle total sur vos sous-domaines.
Étape 5 : configurer BIMI (bonus)
BIMI (Brand Indicators for Message Identification) affiche votre logo à côté de vos emails dans les clients compatibles (Gmail, Yahoo, Apple Mail depuis iOS 16).
Prérequis :
- DMARC en p=quarantine ou p=reject (obligatoire)
- Un logo en format SVG Tiny PS (profil spécifique)
- Un certificat VMC (Verified Mark Certificate) pour Gmail - coûte environ 1 500 euros par an auprès de DigiCert ou Entrust
Record BIMI :
default._bimi.votredomaine.fr TXT "v=BIMI1; l=https://votredomaine.fr/logo.svg; a=https://votredomaine.fr/vmc.pem"
BIMI est optionnel mais renforce la confiance visuelle. Pour les PME, la priorité est SPF + DKIM + DMARC en p=reject. BIMI peut attendre.
Vérification et dépannage
Vérifier votre configuration
Après avoir publié vos enregistrements, vérifiez :
- Notre outil de test email gratuit - entrez votre domaine et obtenez un score sur 10 avec le détail de chaque protocole.
- Test d'envoi - envoyez un email à une adresse Gmail. Ouvrez l'email → menu ⋮ → « Afficher l'original ». Vous devez voir :
spf=passdkim=passdmarc=pass
Problèmes fréquents
SPF : PermError (trop de lookups)
Comptez le nombre total de lookups DNS. Chaque include:, a:, mx:, ptr: (déprécié), et exists: compte comme un lookup. Les ip4: et ip6: ne comptent pas. Si vous dépassez 10, consolidez en remplaçant les include: par des ip4: directs ou utilisez un service de SPF flattening.
DKIM : fail après transfert
Le transfert d'email ne casse pas DKIM (contrairement à SPF). Si DKIM échoue après un transfert, c'est que le serveur intermédiaire a modifié le contenu du message (ajout de disclaimer, modification des en-têtes). Vérifiez les règles de transport de votre serveur.
DMARC : alignment fail
L'alignement DMARC vérifie que le domaine dans le « From » correspond au domaine validé par SPF ou DKIM. Si votre service d'envoi utilise un domaine différent dans le Return-Path (ex: bounce.sendinblue.com), SPF passera mais l'alignement SPF échouera. Dans ce cas, assurez-vous que DKIM est configuré avec un sélecteur sous votre domaine - l'alignement DKIM compensera l'échec de l'alignement SPF.
Emails légitimes bloqués
Si vos propres emails sont bloqués après le passage en p=reject :
- Repassez temporairement à
p=quarantineoup=none - Analysez les rapports DMARC pour identifier la source
- Corrigez la configuration SPF ou DKIM pour cette source
- Remontez la politique progressivement
La couche technique ne suffit pas
SPF, DKIM et DMARC protègent contre un seul type d'attaque : l'usurpation exacte de votre domaine. Un attaquant qui envoie un email depuis contact@votredomaine.fr sera bloqué.
Mais le phishing moderne ne se limite pas à l'usurpation de domaine. En 2024, 68 % des attaques de phishing ayant abouti utilisaient des domaines légitimes (Proofpoint State of the Phish 2025) - comptes compromis, domaines sosies enregistrés pour l'occasion, ou services légitimes détournés (Google Forms, SharePoint, DocuSign).
Contre ces attaques, la couche technique est aveugle. C'est la couche humaine qui fait la différence : la capacité de vos employés à reconnaître un email suspect, même quand l'authentification technique est impeccable.
Vous avez configuré SPF, DKIM et DMARC. La couche technique est en place. Maintenant, protégez la couche humaine avec nophi.sh - simulation de phishing automatisée, micro-formation ciblée, et mesure de la progression de vos équipes.
Récapitulatif
| Protocole | Type DNS | Emplacement | Protège contre |
|---|---|---|---|
| SPF | TXT | @ (racine) | Envoi depuis des serveurs non autorisés |
| DKIM | TXT ou CNAME | selecteur._domainkey | Modification du contenu en transit |
| DMARC | TXT | _dmarc | Usurpation du domaine visible (From) |
| BIMI | TXT | default._bimi | - (affiche le logo, pas une protection) |
La configuration minimale recommandée :
@ TXT "v=spf1 include:_spf.google.com -all"
google._domainkey TXT "v=DKIM1; k=rsa; p=..."
_dmarc TXT "v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine.fr; fo=1"
Trois enregistrements. Moins d'une heure de travail. Et votre domaine passe de « n'importe qui peut usurper votre identité » à « les emails frauduleux sont rejetés automatiquement ».