SPF, DKIM, DMARC : Le Guide Complet 2025 pour PME
SPF, DKIM, DMARC : Le Guide Complet 2025 pour PME Link to heading
Vos commerciaux envoient depuis leur Gmail personnel parce que les emails @votreentreprise.fr finissent en spam. Vos clients vous disent “je n’ai jamais reçu votre email”. Vos campagnes marketing floppent avec des taux d’ouverture en chute libre.
Si vous reconnaissez l’un de ces symptômes, ce guide est pour vous.
Pourquoi vos emails finissent en spam (et ce que ça vous coûte) Link to heading
Chaque jour, plus de 300 milliards d’emails sont envoyés dans le monde. Plus de la moitié sont du spam ou des tentatives de phishing. Pour se protéger, les fournisseurs de messagerie (Gmail, Outlook, Yahoo) ont déployé des systèmes de vérification de plus en plus stricts.
Le problème : sans configuration correcte de votre côté, vos emails légitimes sont traités comme suspects et finissent dans le dossier spam de vos destinataires.
Le coût réel pour votre entreprise Link to heading
Les conséquences d’une mauvaise délivrabilité vont bien au-delà d’un simple inconvénient technique :
Deals perdus : Vos propositions commerciales n’arrivent jamais. Le prospect pense que vous n’avez pas donné suite. J’ai vu des startups perdre des contrats à 6 chiffres parce que leur email de suivi était tombé en spam. Le commercial pensait avoir fait son travail, le prospect attendait une réponse qui n’est jamais venue.
Clients frustrés : Factures, confirmations de commande, emails de support disparaissent dans le vide. Le client appelle furieux : “Je n’ai jamais reçu ma facture !” Vous perdez du temps à renvoyer, à vous justifier, et parfois vous perdez le client qui doute de votre professionnalisme.
Réputation dégradée : Plus vous envoyez des emails non authentifiés, plus votre domaine est considéré comme suspect par les algorithmes de réputation. C’est un cercle vicieux qui s’aggrave avec le temps et qui devient de plus en plus difficile à inverser.
Équipe qui contourne : Vos collaborateurs utilisent leur Gmail personnel pour “être sûrs que ça arrive”. Résultat : vous perdez la traçabilité des échanges, vous créez des risques RGPD (données clients sur des comptes personnels), et vous projetez une image peu professionnelle quand un client reçoit un email de [email protected] au lieu de [email protected].
Les chiffres qui font mal Link to heading
Selon les études du secteur, environ 20% des emails B2B légitimes n’atteignent jamais la boîte de réception de leur destinataire. Sur 100 prospects contactés, 20 ne verront jamais votre message. C’est un commercial sur cinq qui travaille dans le vide.
Pour une équipe commerciale de 5 personnes qui envoie 50 emails de prospection par jour, cela représente 50 opportunités perdues chaque jour. Sur un an, des milliers de contacts qui n’ont jamais vu votre message.
Les 3 protocoles expliqués simplement Link to heading
L’authentification email repose sur trois protocoles complémentaires : SPF, DKIM et DMARC. Ces trois lettres mystérieuses effraient souvent les non-techniciens, mais le concept est simple à comprendre. Chacun joue un rôle spécifique dans la chaîne de confiance.
Pensez à ces protocoles comme les trois couches de sécurité d’une banque : l’identité du visiteur (SPF), la signature sur le chèque (DKIM), et les instructions en cas de fraude (DMARC).
SPF : Qui a le droit d’envoyer en votre nom ? Link to heading
SPF (Sender Policy Framework) est une liste blanche de serveurs autorisés à envoyer des emails pour votre domaine.
Concrètement, vous publiez dans votre DNS un enregistrement qui dit : “Seuls ces serveurs ont le droit d’envoyer des emails @mondomaine.fr”. C’est comme donner une liste de personnes autorisées à retirer du courrier en votre nom à la Poste.
Quand un serveur de réception reçoit un email de votre domaine, il vérifie si l’IP d’envoi figure dans cette liste. Si non, l’email est suspect.
Exemple d’enregistrement SPF :
v=spf1 include:_spf.google.com include:spf.sendinblue.com -all
Décryptage :
v=spf1: Version du protocole SPFinclude:_spf.google.com: Autorise les serveurs de Google Workspaceinclude:spf.sendinblue.com: Autorise les serveurs de Brevo (ex-Sendinblue)-all: Rejette tous les autres serveurs (hard fail)
Vous pouvez aussi utiliser ~all (soft fail) qui est moins strict et marque les emails comme suspects sans les rejeter. C’est utile en phase de transition.
DKIM : Le message est-il authentique ? Link to heading
DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email envoyé. C’est l’équivalent numérique d’une signature manuscrite sur un document officiel.
Le principe : votre serveur d’envoi signe chaque message avec une clé privée (gardée secrète). La clé publique correspondante est publiée dans votre DNS. Le serveur de réception peut ainsi vérifier que le message n’a pas été altéré en transit et qu’il provient bien d’un expéditeur autorisé.
Si quelqu’un intercepte l’email et modifie son contenu, la signature ne correspondra plus et le serveur de destination le saura.
Exemple d’enregistrement DKIM :
google._domainkey.mondomaine.fr IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Le sélecteur (google dans cet exemple) identifie quelle clé utiliser parmi plusieurs possibles. Chaque service email utilise généralement son propre sélecteur : google pour Google Workspace, selector1 et selector2 pour Microsoft 365, k1 pour Mailchimp, etc.
DMARC : Que faire en cas d’échec ? Link to heading
DMARC (Domain-based Message Authentication, Reporting and Conformance) est le chef d’orchestre. Il définit la politique à appliquer quand un email échoue aux vérifications SPF ou DKIM.
Sans DMARC, chaque fournisseur applique sa propre politique. Avec DMARC, c’est vous qui décidez. C’est comme donner des instructions à votre banque : “Si quelqu’un présente un chèque douteux en mon nom, voici ce que vous devez faire.”
DMARC permet de répondre à deux questions essentielles :
- Que doivent faire les serveurs destinataires avec les emails suspects ? (rien, quarantaine, rejet)
- Où envoyer les rapports d’authentification pour que vous puissiez surveiller ce qui se passe ?
Exemple d’enregistrement DMARC :
_dmarc.mondomaine.fr IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Décryptage :
v=DMARC1: Version du protocolep=quarantine: Politique = mettre en quarantaine (spam) les emails qui échouentrua=mailto:[email protected]: Adresse pour recevoir les rapports agrégés
Le flux d’authentification complet Link to heading
Voici ce qui se passe quand vous envoyez un email :
Pour qu’un email passe DMARC, il doit réussir soit SPF soit DKIM (avec alignement du domaine). Les deux ne sont pas obligatoirement requis, mais avoir les deux maximise vos chances et offre une redondance si l’un des deux échoue.
L’alignement signifie que le domaine visible dans le “From:” doit correspondre au domaine authentifié par SPF ou DKIM. Sans alignement, même si SPF et DKIM passent techniquement, DMARC peut échouer.
Tester votre configuration en 2 minutes Link to heading
Avant de corriger quoi que ce soit, commencez par diagnostiquer l’état actuel de votre configuration. Inutile de réparer ce qui fonctionne déjà.
Méthode 1 : Utiliser un outil en ligne (recommandé) Link to heading
Le plus simple est d’utiliser un outil d’analyse automatique. J’ai créé MailAuthCheck précisément pour ça : entrez votre domaine et obtenez un diagnostic complet en quelques secondes.
L’outil vérifie :
- La présence et la validité de votre enregistrement SPF
- La configuration DKIM (si détectable publiquement)
- La politique DMARC en place
- Les erreurs courantes et leur gravité
- Des recommandations personnalisées
Méthode 2 : Commandes dig manuelles Link to heading
Si vous préférez vérifier vous-même ou si vous êtes à l’aise avec le terminal, voici les commandes à exécuter :
Vérifier SPF :
dig +short TXT mondomaine.fr | grep spf
Résultat attendu : un enregistrement commençant par v=spf1
Vérifier DKIM :
dig +short TXT selecteur._domainkey.mondomaine.fr
Remplacez selecteur par le sélecteur utilisé (souvent google, default, s1, selector1, etc.). Le sélecteur dépend de votre fournisseur email.
Résultat attendu : un enregistrement commençant par v=DKIM1
Vérifier DMARC :
dig +short TXT _dmarc.mondomaine.fr
Résultat attendu : un enregistrement commençant par v=DMARC1
Méthode 3 : Analyser les en-têtes d’un email Link to heading
Envoyez un email depuis votre domaine vers une adresse Gmail personnelle, puis affichez les en-têtes complets du message. Dans Gmail : ouvrez le message, cliquez sur le menu ⋮ (trois points verticaux), puis “Afficher l’original”.
Cherchez la section Authentication-Results. Vous y trouverez quelque chose comme :
Authentication-Results: mx.google.com;
dkim=pass header.i=@mondomaine.fr header.s=google;
spf=pass (google.com: domain of [email protected] designates xxx.xxx.xxx.xxx as permitted sender);
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE)
Ce que vous voulez voir : dkim=pass, spf=pass, dmarc=pass. Si vous voyez fail ou none quelque part, il y a un problème à corriger.
Les erreurs courantes (et comment les corriger) Link to heading
Après avoir analysé des millions de domaines avec MailAuthCheck, voici les erreurs que je rencontre le plus souvent. Bonne nouvelle : la plupart se corrigent en quelques minutes une fois identifiées.
Erreur #1 : SPF avec trop de lookups DNS Link to heading
Le problème : SPF est limité à 10 requêtes DNS (lookups). Chaque include: compte pour un lookup, et les includes peuvent en chaîner d’autres de manière récursive. Si vous dépassez cette limite, votre SPF est complètement invalide et tous vos emails échouent.
Symptôme : permerror dans les résultats SPF
Comment ça arrive : Vous accumulez les services email au fil du temps sans jamais faire le ménage. Google Workspace (1-2 lookups) + HubSpot (2-3 lookups) + Mailchimp (2-3 lookups) + SendGrid (1-2 lookups) + Intercom (1-2 lookups) + Zendesk (1-2 lookups) = facilement plus de 10 lookups.
La solution :
Option 1 : Auditer et nettoyer. Supprimez les services que vous n’utilisez plus. Cette newsletter Mailchimp que personne n’envoie depuis 2 ans ? Ce compte SendGrid de test ? Virez-les.
Option 2 : SPF flattening. Des services comme AutoSPF ou SPF Maestro “aplatissent” vos includes en IP statiques, réduisant drastiquement le nombre de lookups. Attention : ces IP peuvent changer, il faut une solution qui se met à jour automatiquement.
Option 3 : Sous-domaines dédiés. Utilisez
marketing.mondomaine.frpour Mailchimp,support.mondomaine.frpour Zendesk. Chaque sous-domaine a son propre SPF avec sa propre limite de 10 lookups.
Vérification : Utilisez MXToolbox SPF Record Lookup pour compter vos lookups actuels.
Erreur #2 : DKIM absent ou mal configuré Link to heading
Le problème : Pas de signature DKIM sur vos emails, ou clé mal publiée dans le DNS.
Symptôme : dkim=none ou dkim=fail dans les en-têtes
Comment ça arrive : DKIM nécessite une configuration côté serveur d’envoi (qui signe) ET côté DNS (qui publie la clé publique). Si l’un des deux manque, ça ne fonctionne pas. L’erreur classique : on active DKIM côté service email mais on oublie de publier l’enregistrement DNS, ou on fait une erreur de copier-coller.
La solution :
- Générez une paire de clés DKIM dans votre service email (l’interface vous guidera)
- Publiez la clé publique dans votre DNS exactement comme indiqué (attention aux espaces et retours à la ligne)
- Vérifiez que le sélecteur correspond entre la config du service et l’enregistrement DNS
- Attendez la propagation DNS (généralement 1-4 heures, parfois jusqu’à 48h)
Points d’attention :
- La clé doit faire au minimum 1024 bits (2048 bits recommandé pour la sécurité)
- Vérifiez l’absence d’espaces ou caractères parasites lors du copier-coller
- Chaque service email a besoin de son propre enregistrement DKIM avec son propre sélecteur
Erreur #3 : DMARC en mode “none” depuis des mois Link to heading
Le problème : Vous avez configuré DMARC avec p=none, ce qui signifie “ne rien faire en cas d’échec”. C’est un bon point de départ pour collecter des rapports et identifier les problèmes, mais rester à ce niveau indéfiniment ne protège pas votre domaine.
Symptôme : DMARC techniquement valide, mais aucune protection réelle contre l’usurpation. Des attaquants peuvent envoyer des emails en votre nom et ils arrivent quand même.
La solution : Progresser vers une politique plus stricte selon un calendrier défini :
# Étape 1 : Monitoring (2-4 semaines)
v=DMARC1; p=none; rua=mailto:[email protected]
# Étape 2 : Quarantaine partielle (2-4 semaines)
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
# Étape 3 : Quarantaine totale (2-4 semaines)
v=DMARC1; p=quarantine; rua=mailto:[email protected]
# Étape 4 : Rejet (objectif final)
v=DMARC1; p=reject; rua=mailto:[email protected]
Le paramètre pct=25 permet d’appliquer la politique à seulement 25% des emails, pour tester progressivement.
Important : Ne passez à p=reject qu’après avoir vérifié dans les rapports que tous vos services légitimes sont correctement authentifiés. Sinon, vous bloquerez vos propres emails.
Erreur #4 : Services email non déclarés Link to heading
Le problème : Votre marketing utilise Mailchimp, votre CRM envoie depuis HubSpot, votre support utilise Intercom… mais seul Google Workspace est déclaré dans votre SPF.
Symptôme : Certains emails passent, d’autres non. Vos commerciaux n’ont pas de problème mais l’équipe marketing se plaint que les newsletters arrivent en spam.
Comment ça arrive : Chaque équipe souscrit ses outils sans penser à la configuration DNS. Le marketing active Mailchimp un lundi matin pour une campagne urgente, et personne ne prévient l’IT. Trois mois plus tard, on se demande pourquoi les taux d’ouverture sont catastrophiques.
La solution : Faites un inventaire exhaustif de TOUS les services qui envoient au nom de votre domaine :
- Suite email (Google Workspace, Microsoft 365)
- CRM (HubSpot, Salesforce, Pipedrive, Zoho)
- Marketing automation (Mailchimp, Brevo, ActiveCampaign, Klaviyo)
- Support client (Intercom, Zendesk, Freshdesk, Crisp)
- Email transactionnel (SendGrid, Mailgun, Postmark, Amazon SES)
- Facturation (Stripe, PayPal, QuickBooks, Pennylane)
- Gestion de projet (Notion, Asana, Monday si ils envoient des notifications)
- Autres SaaS qui envoient des notifications en votre nom
Pour chacun, ajoutez l’entrée SPF correspondante et configurez DKIM si disponible. Documentez cette liste pour la maintenir à jour.
Erreur #5 : Enregistrements multiples Link to heading
Le problème : Plusieurs enregistrements SPF ou DMARC pour le même domaine. C’est souvent le résultat de plusieurs personnes qui ont ajouté des enregistrements sans vérifier ce qui existait déjà.
Symptôme : permerror ou comportement imprévisible
La règle : Un seul enregistrement SPF. Un seul enregistrement DMARC. (Plusieurs DKIM sont possibles et même souhaités, avec des sélecteurs différents pour chaque service.)
La solution : Fusionnez vos enregistrements SPF en un seul :
# Incorrect (2 enregistrements = invalide)
v=spf1 include:_spf.google.com -all
v=spf1 include:spf.hubspot.com -all
# Correct (1 enregistrement fusionné)
v=spf1 include:_spf.google.com include:spf.hubspot.com -all
Erreur #6 : Mauvais terminateur SPF Link to heading
Le problème : L’enregistrement SPF ne se termine pas correctement, ou pire, utilise +all.
Symptôme : SPF techniquement valide mais inefficace ou dangereux
Les options et leur signification :
-all(hard fail) : “Rejeter tout ce qui n’est pas dans la liste.” Recommandé.~all(soft fail) : “Marquer comme suspect mais accepter.” Acceptable en transition.?all(neutral) : “Je n’ai pas d’avis.” Inutile, autant ne pas avoir de SPF.+all: “Tout autoriser.” DANGEREUX : n’importe qui sur Internet peut envoyer en votre nom et c’est considéré comme légitime.
La solution : Utilisez -all en production, ou ~all si vous êtes encore en phase de configuration.
Erreur #7 : DKIM avec clé trop courte Link to heading
Le problème : Clé DKIM de 512 bits ou 768 bits, considérée comme cryptographiquement faible et parfois rejetée par les fournisseurs modernes.
Symptôme : dkim=fail avec mention de “weak key” ou signature rejetée
La solution : Régénérez une clé de 2048 bits (standard actuel recommandé) ou 1024 bits minimum. La plupart des services email modernes génèrent des clés 2048 bits par défaut.
Configuration par hébergeur Link to heading
Voici comment configurer SPF, DKIM et DMARC chez les principaux fournisseurs. Les interfaces changent régulièrement, mais les principes restent les mêmes.
Google Workspace Link to heading
SPF :
v=spf1 include:_spf.google.com ~all
DKIM :
- Console d’administration (admin.google.com) > Applications > Google Workspace > Gmail
- Authentifier les emails > Configurer DKIM
- Sélectionnez votre domaine, générez la clé (choisissez 2048 bits)
- Copiez l’enregistrement TXT et ajoutez-le dans votre DNS
- Attendez la propagation (quelques heures)
- Revenez dans la console et cliquez “Démarrer l’authentification”
DMARC :
Ajoutez cet enregistrement TXT à _dmarc.votredomaine.fr :
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Microsoft 365 Link to heading
SPF :
v=spf1 include:spf.protection.outlook.com ~all
DKIM :
- Centre d’administration Microsoft 365 (admin.microsoft.com)
- Paramètres > Domaines > Sélectionnez votre domaine
- Allez dans Sécurité > Email & collaboration > Stratégies et règles > DKIM
- Activez DKIM pour votre domaine
- Ajoutez les deux enregistrements CNAME indiqués (selector1 et selector2)
DMARC :
Même principe que pour Google, ajoutez l’enregistrement TXT à _dmarc.votredomaine.fr.
OVH (MX Plan / Exchange) Link to heading
SPF :
v=spf1 include:mx.ovh.com ~all
DKIM :
- Espace client OVH > Web Cloud > Emails > Votre domaine > DKIM
- Activez DKIM, OVH génère automatiquement les enregistrements
- Patientez quelques minutes pour l’activation
DMARC :
Ajoutez manuellement l’enregistrement TXT dans la zone DNS via l’espace client.
Infomaniak Link to heading
SPF :
v=spf1 include:_spf.infomaniak.ch ~all
DKIM :
- Manager Infomaniak > Mail > Votre hébergement > Sécurité
- Activez DKIM, l’enregistrement est créé automatiquement dans la zone DNS Infomaniak
Gandi Link to heading
SPF :
Si vous utilisez le mail Gandi :
v=spf1 include:_mailcust.gandi.net ~all
DKIM :
Gandi active DKIM automatiquement pour ses services mail. Vérifiez dans l’interface de gestion DNS que l’enregistrement est présent (il commence par un sélecteur type gm1._domainkey).
Cloudflare (DNS uniquement) Link to heading
Cloudflare ne fournit pas de service email, mais c’est un excellent gestionnaire DNS. Vous pouvez configurer vos enregistrements SPF/DKIM/DMARC dans leur interface. Ajoutez simplement les enregistrements TXT fournis par votre service email réel.
Attention : désactivez le proxy orange (passez en “DNS only” / nuage gris) pour les enregistrements MX. Le proxy Cloudflare n’est pas compatible avec le trafic email.
Cas particuliers Link to heading
Sous-domaines Link to heading
Par défaut, la politique DMARC du domaine principal s’applique aux sous-domaines. Vous pouvez définir une politique différente pour les sous-domaines avec le tag sp= (subdomain policy) :
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]
Ici, le domaine principal rejette les emails non authentifiés, mais les sous-domaines les mettent seulement en quarantaine. Utile si vous avez des sous-domaines gérés par des équipes qui n’ont pas encore finalisé leur configuration.
Chaque sous-domaine peut aussi avoir son propre enregistrement DMARC pour une politique spécifique :
_dmarc.marketing.mondomaine.fr IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Multi-domaines Link to heading
Si votre entreprise possède plusieurs domaines (marques différentes, domaines pays, domaines historiques après acquisition), chaque domaine nécessite sa propre configuration SPF, DKIM et DMARC.
Bonne pratique : Centralisez les rapports DMARC sur une seule adresse pour avoir une vue consolidée :
# Pour domaine1.fr
v=DMARC1; p=reject; rua=mailto:[email protected]
# Pour domaine2.fr
v=DMARC1; p=reject; rua=mailto:[email protected]
Attention : Le domaine qui reçoit les rapports pour un autre domaine doit autoriser explicitement cette réception. Ajoutez un enregistrement TXT d’autorisation :
domaine1.fr._report._dmarc.domaine-principal.fr IN TXT "v=DMARC1"
Domaines qui n’envoient pas d’email Link to heading
Vous avez des domaines “parking”, des domaines défensifs (pour protéger votre marque), ou des anciens domaines qui ne servent plus ? Protégez-les quand même pour éviter qu’ils soient utilisés pour du phishing contre vos clients ou partenaires :
# SPF : personne n'est autorisé à envoyer
v=spf1 -all
# DMARC : rejet total de tout email
v=DMARC1; p=reject; rua=mailto:[email protected]
# Optionnel : MX null pour indiquer qu'aucun email ne doit être reçu
@ IN MX 0 .
Comprendre les rapports DMARC Link to heading
Une fois DMARC configuré avec une adresse de rapport (rua=mailto:...), vous recevrez des fichiers XML quotidiens des principaux fournisseurs qui ont reçu des emails se prétendant de votre domaine.
Les deux types de rapports Link to heading
Rapports agrégés (RUA) : Résumés quotidiens en XML compressé (gzip). Ils montrent les volumes d’emails par IP source, les résultats d’authentification (pass/fail pour SPF et DKIM), et les actions appliquées. C’est le standard, configuré avec rua=mailto:.... Vous en recevrez de Google, Microsoft, Yahoo, et d’autres fournisseurs majeurs.
Rapports forensiques (RUF) : Copies des emails individuels qui ont échoué, avec les en-têtes complets. Plus détaillés mais soulèvent des questions de confidentialité car ils peuvent contenir des informations sensibles. Configurés avec ruf=mailto:.... La plupart des fournisseurs majeurs (Google notamment) ne les envoient plus pour des raisons de vie privée.
Ce qu’il faut surveiller dans les rapports Link to heading
Emails légitimes qui échouent : Si vous voyez des IP que vous reconnaissez (serveurs de vos fournisseurs email) avec spf=fail ou dkim=fail, votre configuration est incomplète. C’est le premier problème à corriger.
Tentatives d’usurpation : Des IP inconnues qui envoient au nom de votre domaine. Avec p=reject, ces emails frauduleux seront bloqués. C’est exactement ce que vous voulez.
Volume inattendu : Un pic soudain d’envois depuis des IP inconnues peut indiquer une campagne de phishing active utilisant votre domaine. Passez rapidement à p=reject si ce n’est pas déjà fait.
Outils pour analyser les rapports Link to heading
Les rapports XML bruts sont illisibles pour un humain normal. Utilisez un outil d’agrégation qui les transforme en tableaux de bord visuels :
- Postmark DMARC — Gratuit, simple, suffisant pour la plupart des PME
- DMARC Analyzer — Version gratuite disponible, plus de fonctionnalités
- dmarcian — Plus complet, payant, pour les entreprises avec des besoins avancés
- URIports — Alternative européenne, hébergement EU
Exigences Gmail et Yahoo 2024 Link to heading
Depuis février 2024, Gmail et Yahoo ont significativement durci leurs exigences pour les expéditeurs d’emails. Ces règles s’appliquent particulièrement aux “gros expéditeurs” (plus de 5000 emails/jour vers leurs utilisateurs), mais les bonnes pratiques concernent tout le monde.
Ce qui est désormais obligatoire Link to heading
Pour tous les expéditeurs :
- SPF ou DKIM configuré et valide
- Enregistrement DNS inverse (PTR) valide pour l’IP d’envoi
- Taux de spam signalé par les utilisateurs < 0.3% (idéalement < 0.1%)
- Format des messages conforme aux standards (RFC 5322)
Pour les gros expéditeurs (5000+ emails/jour vers Gmail/Yahoo) :
- SPF et DKIM configurés (les deux, pas l’un ou l’autre)
- DMARC publié (même avec
p=nonepour commencer) - Alignement du domaine (le From: correspond au domaine authentifié)
- Lien de désinscription en un clic dans l’en-tête (List-Unsubscribe)
- Désinscription honorée sous 2 jours ouvrés
Conséquences si vous ne respectez pas ces règles Link to heading
Vos emails seront progressivement :
- Ralentis (throttling) — moins d’emails acceptés par heure
- Mis en spam — même s’ils passent techniquement
- Rejetés complètement — erreur 550 au niveau SMTP
Ce n’est plus optionnel ni “nice to have”. C’est une exigence technique pour atteindre les boîtes de réception Gmail et Yahoo, qui représentent une part massive des adresses email professionnelles et personnelles.
Que faire si ça ne marche toujours pas ? Link to heading
Vous avez configuré SPF, DKIM et DMARC correctement, tout passe “pass” dans les en-têtes, mais vos emails arrivent encore en spam ? L’authentification n’est qu’une partie de l’équation. Voici les autres facteurs qui influencent la délivrabilité.
Réputation du domaine et de l’IP Link to heading
Un domaine qui a envoyé du spam dans le passé (volontairement ou non, peut-être par un ancien employé ou une compromission) met du temps à récupérer sa réputation. Les algorithmes ont de la mémoire.
Vérifiez votre réputation :
- Google Postmaster Tools — Créez un compte et vérifiez votre domaine pour voir votre réputation chez Google
- Vérifiez si votre IP ou domaine est sur des blacklists : Spamhaus, Barracuda, SURBL, etc.
Solutions si votre réputation est mauvaise :
- Réduisez temporairement le volume d’envoi
- Envoyez uniquement à des contacts engagés (qui ouvrent et cliquent)
- Attendez : la réputation se reconstruit progressivement sur plusieurs semaines/mois
- En dernier recours : changez d’IP d’envoi ou utilisez un sous-domaine dédié
Contenu des emails Link to heading
Même avec une authentification parfaite, certains éléments dans vos emails déclenchent les filtres anti-spam :
- Trop de liens (surtout vers des domaines différents)
- Pièces jointes suspectes (.exe, .zip avec mot de passe)
- Mots-clés “spammy” : gratuit, urgent, gagnez, offre limitée, cliquez ici
- Ratio texte/image déséquilibré (trop d’images, pas assez de texte)
- Liens raccourcis (bit.ly, etc.) — les spammeurs les utilisent pour masquer les vraies destinations
- HTML mal formaté ou trop complexe
Hygiène de liste email Link to heading
Si vous envoyez des emails marketing ou des newsletters :
- Supprimez les hard bounces : Une adresse qui n’existe plus doit être retirée immédiatement
- Gérez les soft bounces : Après plusieurs échecs, retirez l’adresse
- Respectez les désinscriptions : Immédiatement et sans discussion
- Ne rachetez jamais de listes email : Ces listes sont des pièges à spam
- Utilisez le double opt-in : Confirmation par email avant d’ajouter quelqu’un à votre liste
Configuration technique du serveur Link to heading
- Reverse DNS (PTR record) : L’IP de votre serveur doit avoir un enregistrement PTR qui correspond à votre domaine
- Blacklists : Vérifiez que votre IP d’envoi n’est pas sur une blacklist
- TLS : Utilisez des connexions SMTP chiffrées (la plupart des services modernes le font automatiquement)
- Volume progressif : Si vous envoyez soudainement 10x plus d’emails que d’habitude, ça déclenche des alertes
FAQ : Questions fréquentes Link to heading
Combien de temps pour voir les résultats ? Link to heading
La propagation DNS prend généralement 1-4 heures, parfois jusqu’à 48h pour les changements DKIM. Les effets sur la délivrabilité sont progressifs : comptez 2-4 semaines pour voir une amélioration significative si votre domaine avait une mauvaise réputation. Les algorithmes de réputation évoluent lentement.
SPF ou DKIM : lequel est le plus important ? Link to heading
Les deux sont importants et complémentaires. SPF vérifie que l’IP d’envoi est autorisée. DKIM vérifie l’intégrité et l’authenticité du message. Pour une protection complète et une délivrabilité optimale, configurez les deux. Gmail et Yahoo l’exigent maintenant pour les gros expéditeurs.
DMARC p=none sert à quelque chose ? Link to heading
Oui, pour la phase de monitoring initiale. Vous recevez des rapports détaillés sur ce qui passe et ce qui échoue, sans impacter la délivrance de vos emails. C’est l’étape indispensable pour identifier tous vos services email avant de passer à quarantine ou reject. Mais rester en p=none indéfiniment ne protège pas votre domaine contre l’usurpation.
Puis-je configurer DMARC sans SPF ni DKIM ? Link to heading
Techniquement oui, l’enregistrement sera valide. Mais c’est inutile. DMARC s’appuie sur SPF et DKIM pour prendre ses décisions. Sans eux, DMARC n’a rien à vérifier et tous vos emails échoueront le test DMARC.
Mon hébergeur gère-t-il automatiquement tout ça ? Link to heading
Rarement de manière complète. La plupart des hébergeurs (OVH, Gandi, Infomaniak) configurent SPF et DKIM pour leurs propres serveurs email, mais pas pour vos services tiers (CRM, marketing automation, support client, etc.). Et DMARC est presque toujours à configurer manuellement. Vérifiez systématiquement.
Que signifie “alignement” en DMARC ? Link to heading
L’alignement vérifie que le domaine visible par le destinataire (le champ From:) correspond au domaine authentifié par SPF ou DKIM. Si vous envoyez depuis [email protected] mais que SPF valide serveur.autredomaine.fr, il n’y a pas alignement et DMARC peut échouer même si SPF passe techniquement.
Les sous-domaines héritent-ils de la config du domaine principal ? Link to heading
Pour DMARC, oui par défaut (configurable avec sp=). Pour SPF et DKIM, non : chaque sous-domaine doit avoir ses propres enregistrements si vous envoyez des emails depuis ce sous-domaine.
Comment savoir si quelqu’un usurpe mon domaine ? Link to heading
Les rapports DMARC vous le montrent. Configurez rua=mailto:... et analysez les rapports avec un outil comme Postmark DMARC. Vous verrez toutes les IP qui envoient au nom de votre domaine et si elles passent ou échouent l’authentification. Les IP que vous ne reconnaissez pas avec des échecs sont probablement des tentatives d’usurpation.
Mes emails internes (entre collègues) sont-ils concernés ? Link to heading
Si vous utilisez Google Workspace ou Microsoft 365, les emails internes restent sur leurs serveurs et ne passent pas par les vérifications SPF/DKIM/DMARC de la même manière. Mais dès qu’un email sort vers un destinataire externe, toutes les vérifications s’appliquent.
Dois-je configurer tout ça pour chaque adresse email ? Link to heading
Non. SPF, DKIM et DMARC se configurent au niveau du domaine, pas de l’adresse email individuelle. Une fois configuré pour mondomaine.fr, ça s’applique à [email protected], [email protected], [email protected], etc.
Checklist de configuration Link to heading
Utilisez cette checklist pour vérifier que votre configuration est complète.
SPF Link to heading
- Un seul enregistrement SPF existe (pas de doublons)
- Tous les services email légitimes sont inclus
- Le nombre de lookups DNS est inférieur à 10
- L’enregistrement se termine par
-allou~all
DKIM Link to heading
- DKIM est activé pour chaque service email
- Les clés publiques sont publiées dans le DNS
- Les sélecteurs correspondent entre service et DNS
- Les clés font au minimum 1024 bits (2048 recommandé)
DMARC Link to heading
- Un enregistrement DMARC existe à
_dmarc.mondomaine.fr - Une adresse de rapport est configurée (
rua=mailto:...) - La politique progresse vers
p=rejectselon un calendrier défini
Validation finale Link to heading
- Envoi test vers Gmail :
dkim=pass,spf=pass,dmarc=pass - Envoi test vers Outlook : mêmes vérifications
- Score sur MailAuthCheck satisfaisant
- Rapports DMARC analysés régulièrement
Besoin d’aide ? Link to heading
La configuration email peut être complexe, surtout quand vous utilisez plusieurs services qui envoient au nom de votre domaine et que chaque équipe a ajouté ses outils sans coordination.
Testez gratuitement votre domaine Link to heading
MailAuthCheck analyse votre configuration SPF, DKIM et DMARC en quelques secondes. C’est gratuit, sans inscription, et vous obtenez un diagnostic clair avec des recommandations.
4,5+ millions de domaines analysés à ce jour.
Audit personnalisé Link to heading
Si votre situation est complexe (multi-domaines, migration en cours, historique de problèmes de délivrabilité, usurpation active de votre domaine), je propose un audit complet avec :
- Diagnostic de tous vos flux email (qui envoie quoi, depuis où)
- Identification des sources de problèmes
- Plan de remédiation priorisé
- Accompagnement jusqu’à
p=reject
Prendre RDV pour un diagnostic