Comment vérifier SPF, DKIM et DMARC pour n’importe quel domaine (guide gratuit 2026)
Si vos e-mails atterrissent en spam, sont rejetés ou affichent des avertissements « expéditeur non vérifié », la première chose à vérifier, c’est votre configuration d’authentification e-mail.
Cela revient à valider trois enregistrements clés :
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
- DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Ces enregistrements DNS disent aux fournisseurs de messagerie comme Gmail, Outlook ou Yahoo si votre domaine est réellement autorisé à envoyer des e-mails. Si l’un d’eux manque, est cassé ou trop faible, vos messages perdent vite la confiance.
Dans ce guide gratuit 2026, vous allez apprendre :
- comment vérifier un enregistrement SPF
- comment vérifier un enregistrement DKIM
- comment vérifier un enregistrement DMARC
- pourquoi des e-mails partent encore en spam même quand les enregistrements existent
- les erreurs d’authentification les plus courantes
- la manière la plus rapide de tester un domaine pour des soucis de délivrabilité
Si vous gérez un domaine professionnel, une newsletter, une boîte support, une campagne d’outreach, un produit SaaS ou un setup de cold email, c’est l’une des vérifications techniques les plus importantes que vous puissiez faire.
Réponse rapide : comment vérifier SPF, DKIM et DMARC sur un domaine ?
Pour vérifier SPF, DKIM et DMARC sur un domaine :
- Consultez les enregistrements DNS TXT du domaine
- Vérifiez qu’un SPF existe et qu’il est valide
- Vérifiez qu’un sélecteur DKIM résout vers une clé publique valide
- Cherchez une politique DMARC à
_dmarc.votredomaine.com - Confirmez que les enregistrements ne sont pas seulement présents, mais aussi bien configurés
- Si les e-mails partent quand même en spam, analysez les en-têtes d’un e-mail réel pour voir ce qui passe ou échoue vraiment
La méthode la plus rapide et la plus accessible aux débutants : commencer par un scan complet du domaine via Email Health Checker, puis creuser sur chaque enregistrement si quelque chose paraît bancal.
Pourquoi SPF, DKIM et DMARC comptent en 2026
Les fournisseurs de messagerie sont plus stricts que jamais.
Les boîtes modernes ne regardent plus seulement le contenu — elles regardent si votre domaine a une configuration d’envoi fiable.
Une bonne config SPF, DKIM et DMARC vous aide à :
- améliorer le placement en boîte de réception
- réduire le risque de spoofing
- empêcher l’utilisation de votre domaine à des fins de phishing
- diminuer les chances d’atterrir en spam
- gagner en confiance auprès de Gmail, Outlook, Yahoo et des passerelles e-mail pro
- construire une réputation expéditeur plus saine sur la durée
Si vous envoyez :
- des e-mails transactionnels
- des codes de vérification
- des newsletters
- du cold outreach
- des réponses support
- des e-mails de réinitialisation
- des notifications SaaS
…l’authentification e-mail n’est plus optionnelle.
Qu’est-ce que SPF, DKIM et DMARC ? (en clair)
Avant de vérifier les enregistrements, ça aide de comprendre ce que chacun fait.
SPF : qui a le droit d’envoyer du courrier au nom de votre domaine
SPF est un enregistrement DNS TXT qui liste les serveurs ou services autorisés à envoyer pour votre domaine.
Par exemple, si vous utilisez :
- Google Workspace
- Microsoft 365
- Mailgun
- SendGrid
- Amazon SES
- Brevo
- Zoho Mail
…ces services doivent en général être inclus dans votre SPF.
Ce contre quoi SPF protège : les expéditeurs non autorisés qui se font passer pour votre domaine.
Ce que SPF ne garantit pas : que l’adresse visible dans le « From » s’aligne d’une manière acceptée par DMARC.
DKIM : prouve que l’e-mail a été signé
DKIM ajoute une signature cryptographique à votre courrier sortant.
Quand le serveur du destinataire reçoit le message, il consulte une clé publique stockée dans le DNS pour confirmer :
- que l’e-mail a été signé par un expéditeur autorisé
- que le message n’a pas été altéré en route
Ce contre quoi DKIM protège : l’altération du message et les courriers falsifiés sans signature valide.
Important : un enregistrement DKIM présent dans le DNS ne signifie pas automatiquement que DKIM fonctionne correctement sur les vrais envois.
DMARC : dit aux fournisseurs quoi faire si SPF ou DKIM échoue
DMARC s’appuie sur SPF et DKIM.
Il indique au serveur receveur :
- si le courrier en échec doit être surveillé, mis en quarantaine ou rejeté
- où envoyer les rapports agrégés
- si le domaine authentifié s’aligne avec le domaine du « From » visible
Valeurs de politique DMARC :
p=none→ simple surveillancep=quarantine→ le courrier suspect peut aller en spamp=reject→ le courrier en échec doit être rejeté
Ce contre quoi DMARC protège : le spoofing de domaine, l’usurpation et l’absence d’application réelle de l’authentification.
Comment vérifier SPF, DKIM et DMARC sur un domaine
Voici le workflow le plus simple et le plus pratique.
Étape 1 : commencer par un scan global d’authentification
Au lieu de vérifier les enregistrements un à un manuellement, commencez par un scan large à l’échelle du domaine.
Utilisez Email Health Checker pour avoir un aperçu rapide de :
- l’état de SPF
- la présence de DKIM
- la présence de DMARC
- la configuration MX
- la santé d’authentification de base
- les signaux de risque courants
C’est la meilleure première étape : ça vous dit tout de suite si le domaine a un trou évident avant d’aller creuser.
Pourquoi c’est utile : beaucoup de domaines plantent à cause de petites choses : pas de DMARC, pas de DKIM, MX manquant, SPF mal structuré.
Étape 2 : comment vérifier un enregistrement SPF
Si vous voulez savoir comment vérifier un SPF correctement, ne demandez pas seulement « est-ce qu’il existe ? » — demandez s’il est valide, propre et dans les limites.
À quoi ressemble un SPF valide
Un SPF commence en général comme ceci :
v=spf1 include:_spf.google.com ~all
Ce qu’il faut regarder
- il commence par
v=spf1 - il y a un seul enregistrement TXT SPF pour le domaine
- il inclut vos fournisseurs d’envoi actuels
- il finit par une politique cohérente comme :
~all(soft fail)-all(hard fail)
- il ne dépasse pas la limite de 10 lookups DNS
Erreurs SPF courantes
- publier plusieurs enregistrements SPF
- laisser des
include:d’anciens fournisseurs - utiliser une règle trop permissive comme
+all - dépasser la limite de 10 lookups
- oublier de mettre à jour SPF après un changement d’ESP
Le grand piège SPF en 2026 : la limite des 10 lookups
C’est l’un des « tueurs silencieux » de la délivrabilité les plus fréquents.
Si votre SPF imbrique trop de fournisseurs, services de forward ou outils SaaS, il peut dépasser la limite autorisée et échouer en silence.
Si votre SPF est complexe, SPF Flattening Tool peut aider à aplatir les chaînes d’include en IPs explicites pour rester dans les clous.
Étape 3 : comment vérifier un enregistrement DKIM
Si vous cherchez comment vérifier un DKIM, l’essentiel à savoir, c’est :
DKIM fonctionne par sélecteur.
Il vous faut donc en général :
- le domaine
- le sélecteur utilisé par la plateforme d’envoi
Un enregistrement DKIM se trouve souvent à un emplacement comme :
selector1._domainkey.example.com
Ce qu’il faut regarder
- le sélecteur résout correctement
- un enregistrement TXT existe
- la clé publique (
p=) est présente - le format est correct
- la clé est suffisamment forte
- la plateforme signe vraiment les e-mails sortants
Erreurs DKIM courantes
- mauvais sélecteur
- enregistrement publié mais DKIM jamais activé chez le fournisseur
- formatage TXT cassé en DNS
- clés faibles ou obsolètes
- mauvaise rotation des clés
- supposer que « l’enregistrement existe » signifie « DKIM passe »
Pour une inspection technique plus poussée de l’enregistrement lui-même, utilisez DKIM Analyzer afin de regarder la solidité de la clé, la structure de l’enregistrement et les éventuels problèmes de configuration DKIM.
Étape 4 : comment vérifier un enregistrement DMARC
Si vous voulez savoir comment vérifier l’état d’un DMARC correctement, cherchez un TXT à :
_dmarc.example.com
Un DMARC simple ressemble à :
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Ce qu’il faut regarder
- il commence par
v=DMARC1 - il a une politique :
p=nonep=quarantinep=reject
- idéalement, une adresse de reporting :
rua=mailto:...
- éventuellement du forensic reporting :
ruf=mailto:...
- des paramètres d’alignement peuvent être présents :
adkim=aspf=
- déploiement progressif optionnel :
pct=
Erreurs DMARC courantes
- pas d’enregistrement DMARC du tout
- rester en
p=noneindéfiniment - pas de boîte de reporting configurée
- syntaxe cassée
- ignorer les échecs d’alignement
- copier-coller un enregistrement générique sans le comprendre
Pour valider rapidement et voir si vous êtes en surveillance ou en application réelle, utilisez DMARC Checker.
Pourquoi des e-mails partent encore en spam même quand SPF, DKIM et DMARC existent
C’est l’un des aspects les plus mal compris de la délivrabilité.
Un domaine peut avoir des enregistrements SPF, DKIM et DMARC et voir quand même ses e-mails atterrir en spam.
Pourquoi ?
Parce que présence ne veut pas dire bonne configuration.
Causes courantes :
- SPF existe mais dépasse la limite des 10 lookups
- SPF passe mais l’alignement échoue
- enregistrement DKIM présent mais signature en échec sur les envois réels
- DKIM cassé après un forwarding ou une réécriture
- DMARC publié mais resté en
p=none - mauvaise réputation de domaine
- mauvaise réputation d’IP
- contenu qui déclenche les filtres anti-spam
- liens qui paraissent suspects
- taux de rebond élevé
- taux de plaintes élevé
- reverse DNS manquant ou faible
- changement brutal des volumes d’envoi
Vérité importante
SPF + DKIM + DMARC sont la fondation, pas tout le système de délivrabilité.
Ils aident les fournisseurs à vous faire confiance, mais ne compensent pas une mauvaise réputation ou un comportement spammy.
Comment savoir pourquoi un e-mail est parti en spam
Si vos enregistrements DNS ont l’air corrects mais qu’un e-mail réel atterrit quand même en spam, arrêtez de regarder uniquement le DNS.
Il faut inspecter les en-têtes bruts du message.
C’est là que vous voyez ce que le serveur receveur a réellement constaté.
Utilisez Email Header Analyser pour examiner :
- SPF pass/fail
- DKIM pass/fail
- DMARC pass/fail
- Authentication-Results
- les sauts mail / chemin de relais
- les indices d’alignement
- les indices de routage spam
C’est essentiel parce que beaucoup de gens vérifient seulement les enregistrements DNS et ne testent jamais le vrai message livré, là où les soucis cachés apparaissent.
Le meilleur workflow pour vérifier l’authentification e-mail (le plus rapide)
Pour le workflow le plus simple et pratique en 2026, suivez cet ordre :
- Lancez un scan global avec Email Health Checker
- Vérifiez la politique DMARC et son niveau d’application avec DMARC Checker
- Inspectez la qualité du DKIM et la validité du sélecteur avec DKIM Analyzer
- Examinez la structure SPF et le nombre de lookups avec SPF Flattening Tool
- Analysez les en-têtes réels avec Email Header Analyser si la livraison continue à échouer
Cela vous donne :
- une vue DNS
- une vue politique
- une vue message réel
Cette combinaison est bien plus utile qu’un simple lookup TXT.
Erreurs SPF, DKIM et DMARC à éviter
Ces erreurs reviennent en boucle sur les domaines pro, les apps SaaS et les setups de cold email.
Erreurs SPF
- plusieurs TXT SPF
- trop d’
include: - anciens fournisseurs encore listés
+allou politique trop permissive- pas de mise à jour après changement de fournisseur
Erreurs DKIM
- mauvais sélecteur
- enregistrement publié mais signature désactivée
- formatage TXT cassé
- clés faibles
- pas de test sur un vrai message envoyé
Erreurs DMARC
- pas d’enregistrement DMARC
p=noneéternel- pas d’adresse
rua= - alignement ignoré
- syntaxe cassée
- aucune progression vers l’application
Bonnes pratiques SPF, DKIM et DMARC pour 2026
Pour mieux placer en inbox cette année, visez cette base :
- publier un seul SPF propre
- garder SPF sous la limite de 10 lookups
- enlever les anciens fournisseurs inutilisés du SPF
- utiliser des clés DKIM solides
- vérifier que DKIM signe les vrais e-mails sortants
- publier DMARC sur tout domaine d’envoi actif
- commencer en surveillance, puis aller vers l’application
- collecter les rapports DMARC
- surveiller l’alignement, pas seulement le pass/fail
- retester après tout changement DNS ou ESP
- regarder les en-têtes quand quelque chose cloche
- surveiller la réputation et les tendances de bounces
À qui s’adresse cette checklist ?
Ce guide est utile si vous gérez :
- un site pro
- un produit SaaS
- une boîte support
- un système de newsletter
- de l’e-mail transactionnel
- des campagnes de cold outreach
- des domaines clients gérés en agence
- un forwarding e-mail sur domaine perso
- des notifications e-commerce
- des systèmes de réinitialisation / vérification
Si l’e-mail compte pour votre activité, l’authentification compte aussi. Et si vous utilisez de l’e-mail jetable pour tester, comprendre l’authentification vous aide à choisir des fournisseurs qui livrent vraiment.
En conclusion
Si vous envoyez du courrier depuis votre domaine, savoir comment vérifier SPF, DKIM et DMARC est l’une des compétences techniques au plus fort ROI que vous puissiez acquérir.
Cela vous aide à :
- améliorer le placement en boîte de réception
- réduire le risque de spoofing
- diagnostiquer pourquoi des e-mails partent en spam
- attraper les erreurs DNS cachées
- construire la confiance avec les fournisseurs
Et la chose la plus importante à retenir :
Avoir des enregistrements SPF, DKIM et DMARC ne suffit pas — ils doivent être valides, alignés et testés contre le comportement réel de l’e-mail.
Un domaine peut sembler « configuré » à première vue et planter en production.
C’est pour ça que la meilleure approche, c’est :
- vérifier le domaine
- inspecter les enregistrements
- valider la politique
- tester le message réel
Faites-le régulièrement, et vous attraperez la plupart des problèmes d’authentification avant qu’ils ne nuisent à la délivrabilité.
FAQ
Comment je vérifie SPF pour un domaine ?
Pour vérifier SPF, cherchez un TXT qui commence par v=spf1. Assurez-vous qu’il y a un seul enregistrement SPF, qu’il inclut vos fournisseurs actifs et qu’il ne dépasse pas la limite de 10 lookups DNS.
Comment je vérifie DKIM pour un domaine ?
Pour vérifier DKIM, il faut le domaine et en général le sélecteur utilisé par la plateforme d’envoi. Le TXT DKIM doit contenir une clé publique valide et un format correct, mais il faut aussi confirmer que les e-mails sortants réels sont bien signés.
Comment je vérifie DMARC pour un domaine ?
Pour vérifier DMARC, cherchez un TXT à _dmarc.votredomaine.com. Il doit commencer par v=DMARC1 et inclure une politique comme p=none, p=quarantine ou p=reject. Une adresse rua= est aussi vivement recommandée.
Quel est le meilleur vérificateur SPF / DKIM / DMARC ?
Le meilleur workflow n’est pas un outil unique — c’est une combinaison de :
- scan d’authentification au niveau du domaine
- validation directe DMARC
- inspection de l’enregistrement DKIM
- revue de la structure SPF
- analyse des en-têtes réels
Ça vous donne à la fois la vue DNS et la vue message réel.
Pourquoi des e-mails partent en spam même avec SPF, DKIM et DMARC ?
Parce que la présence des enregistrements ne garantit pas la mise en boîte de réception. Les e-mails peuvent quand même partir en spam à cause :
- d’échecs d’alignement
- de signatures DKIM cassées
- d’une structure SPF faible
- d’une mauvaise réputation domaine ou IP
- de contenu déclencheur de filtres
- de taux de plaintes ou rebonds élevés
- de DMARC sans application réelle
DMARC nécessite-t-il SPF et DKIM ?
DMARC fonctionne mieux quand SPF et DKIM sont tous deux bien configurés. Techniquement, DMARC peut passer si soit SPF soit DKIM passe avec un alignement correct, mais s’appuyer sur les deux est bien plus solide et recommandé.
C’est quoi la limite de 10 lookups SPF ?
L’évaluation SPF ne peut effectuer que 10 lookups DNS au maximum. Si votre SPF la dépasse à cause de trop de mécanismes include:, il peut échouer et plomber la délivrabilité.
p=none ou p=reject en DMARC ?
Si vous démarrez, p=none est utile pour surveiller. Mais à long terme, rester en p=none affaiblit la protection. Une fois que votre authentification est stable, la plupart des domaines devraient viser p=quarantine ou p=reject.
SPF, DKIM et DMARC suffisent-ils à la délivrabilité ?
Non. Ces enregistrements sont essentiels, mais la délivrabilité dépend aussi :
- de la réputation du domaine
- de la réputation d’IP
- de la qualité du contenu
- des taux de plaintes
- des taux de rebonds
- du comportement d’envoi
- de l’hygiène de la liste
- de la qualité de l’infrastructure
L’authentification est la fondation, pas l’ensemble du système.
À lire ensuite
- Temp mail qui ne reçoit pas l’OTP ? Réparez ça vite — la mauvaise authentification est la première cause d’OTP raté en temp mail
- Qu’est-ce qu’un e-mail jetable ? Le guide complet — comment fonctionne l’e-mail temporaire et quand l’utiliser
- Comment l’e-mail temporaire protège votre vie privée en ligne — les bénéfices côté vie privée
- Comment éviter le spam : 7 stratégies éprouvées — l’authentification est une couche, pas la solution complète
- Comment l’e-mail anonyme vous protège du phishing — le phishing repose sur le fait d’avoir votre vraie adresse
- E-mail jetable, burner email et temp mail comparés — trois termes, trois outils
- Le guide complet de la confidentialité des e-mails — la photo d’ensemble
Your temp mail is ready right now
No signup, no password. A disposable inbox waiting the moment you open the page.
Get My Free Temp Mail →