Tester la délivrabilité email : le guide complet avant l'envoi

⚡TL;DR

• Un email sur cinq n'atteint jamais la boîte de réception, principalement à cause d'une authentification SPF, DKIM ou DMARC absente ou mal configurée
• Score de délivrabilité : SPF (+25), DKIM (+25), DMARC (+20), MX/PTR (+15), en-têtes (+15) = 100 points possibles
• Depuis 2024 : Gmail et Yahoo exigent SPF + DKIM obligatoires, et DMARC pour les expéditeurs de masse (> 5 000 emails/jour)
• Correction prioritaire : un test de 30 secondes identifie les problèmes exacts, ce guide détaille comment les corriger un par un

Vous venez de lancer une campagne email. Tout est prêt : le contenu est soigné, le design est impeccable, la liste de destinataires est propre. Trois jours plus tard, les statistiques tombent : 22 % de vos emails n'ont jamais atteint la boîte de réception. Pas de bounces. Pas d'erreurs visibles. Vos messages ont simplement disparu dans un dossier spam ou ont été silencieusement rejetés par le serveur de réception.

Ce scénario n'est pas un cas extrême. Selon les données de Validity (Sender Score), un email sur cinq envoyé dans le monde n'atteint jamais la boîte de réception de son destinataire. Pour les entreprises, le coût est direct : factures ignorées, confirmations de commande perdues, prospects marketing gaspillés, et une réputation de domaine qui se dégrade silencieusement.

La bonne nouvelle : la majorité de ces problèmes sont détectables avant l'envoi. Un test de délivrabilité analyse votre configuration DNS (SPF, DKIM, DMARC), vérifie la réputation de votre IP, contrôle vos en-têtes email et produit un score global sur 100. En 30 secondes, vous savez exactement ce qui fonctionne et ce qui bloque vos emails.

Ce guide couvre le processus complet : pourquoi tester, comment fonctionne un test de délivrabilité, comment interpréter chaque section du score, et surtout comment corriger les problèmes identifiés pour passer de 40/100 à 100/100. Que vous soyez administrateur système, développeur ou responsable marketing, chaque section contient des actions concrètes.

Pourquoi tester la délivrabilité avant chaque envoi ?

Le problème invisible

La délivrabilité email est un problème silencieux. Contrairement à un site web en panne (visible immédiatement), un email qui atterrit en spam ne génère aucune alerte. L'expéditeur pense que le message a été livré. Le destinataire ne sait pas qu'un email l'attend dans son dossier spam. Personne ne se plaint parce que personne ne sait.

Les fournisseurs de messagerie (Gmail, Outlook, Yahoo, Apple Mail) prennent des décisions de filtrage en quelques millisecondes, basées sur des centaines de signaux. Et ces signaux évoluent constamment. Un domaine qui passait tous les contrôles il y a six mois peut échouer aujourd'hui parce qu'un prestataire a ajouté un include SPF supplémentaire, ou parce que la rotation de clé DKIM n'a pas été effectuée.

Les 5 contrôles d'un test de délivrabilité

Un test complet vérifie cinq catégories distinctes, chacune contribuant au score global :

Catégorie	Points	Ce qui est vérifié
SPF	25/100	Enregistrement DNS TXT valide, IP de l'expéditeur autorisée, nombre de lookups
DKIM	25/100	Signature cryptographique valide, clé publique DNS accessible, alignement du domaine
DMARC	20/100	Politique publiée, alignement SPF/DKIM, adresse de rapport configurée
MX / PTR	15/100	Enregistrements MX présents, reverse DNS configuré, IP non blacklistée
En-têtes	15/100	From/Reply-To cohérents, Message-ID valide, pas de champs suspects

Un score inférieur à 70/100 signifie que vos emails ont une probabilité significative d'être classés en spam. En dessous de 50/100, la majorité des fournisseurs rejettera ou filtrera vos messages.

Les exigences Gmail et Yahoo 2024

Depuis février 2024, Gmail et Yahoo ont rendu obligatoires des contrôles qui étaient auparavant optionnels. Ces exigences s'appliquent à tous les expéditeurs, avec des règles supplémentaires pour les envois en masse :

Pour tous les expéditeurs :

• SPF ou DKIM valide (au minimum un des deux)
• Enregistrement DNS de type PTR (reverse DNS) configuré pour l'IP d'envoi
• Taux de spam déclaré dans Google Postmaster Tools inférieur à 0,3 %

Pour les expéditeurs de masse (> 5 000 emails/jour vers Gmail) :

• SPF et DKIM valides (les deux obligatoires)
• DMARC publié avec au minimum p=none
• Alignement du domaine From avec SPF ou DKIM
• En-tête List-Unsubscribe avec désabonnement en un clic (RFC 8058)
• Formatage conforme à la RFC 5322

Ne pas respecter ces exigences entraîne un rejet progressif. Gmail ne bloque pas 100 % des emails du jour au lendemain : il commence par différer 4 % des messages (code 4xx), puis augmente le pourcentage jusqu'au rejet permanent (code 5xx) si le problème n'est pas corrigé.

Comment fonctionne un test de délivrabilité ?

Un test de délivrabilité reproduit le processus exact qu'un serveur de réception exécute quand il reçoit votre email. Voici les quatre étapes, dans l'ordre.

Étape 1 : Résolution DNS et vérification SPF

Le test commence par interroger le DNS de votre domaine pour récupérer l'enregistrement SPF.

# Récupérer l'enregistrement SPF de captaindns.com
dig TXT captaindns.com +short | grep "v=spf1"

L'enregistrement SPF est un enregistrement DNS de type TXT qui commence par v=spf1. Il liste les serveurs autorisés à envoyer des emails pour votre domaine. Voici un exemple réel :

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Le serveur de réception compare l'IP du serveur qui a envoyé l'email avec les IP autorisées par votre SPF. Le processus est récursif : chaque include: déclenche une nouvelle requête DNS pour récupérer les IP du sous-domaine référencé.

Point critique : la RFC 7208 limite à 10 le nombre de requêtes DNS (lookups) pendant l'évaluation SPF. Les mécanismes include, a, mx, redirect et exists comptent chacun comme un lookup. Les mécanismes ip4 et ip6 ne comptent pas (ce sont des valeurs directes). Au 11e lookup, le serveur retourne permerror et votre SPF est considéré invalide.

# Vérifier combien de lookups génère votre SPF
# Chaque include génère au moins 1 lookup
dig TXT _spf.google.com +short
# Résultat : "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ..."
# Chaque sous-include compte aussi !

Étape 2 : Vérification de la signature DKIM

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email. Le serveur d'envoi signe le message avec une clé privée. Le serveur de réception vérifie cette signature en récupérant la clé publique correspondante dans le DNS.

La signature DKIM est présente dans l'en-tête DKIM-Signature de l'email :

DKIM-Signature: v=1; a=rsa-sha256; d=captaindns.com; s=google;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

Les champs clés :

• d= : le domaine qui revendique la signature (doit correspondre au domaine From pour DMARC)
• s= : le sélecteur, qui identifie quelle clé publique utiliser
• a= : l'algorithme de signature (rsa-sha256 ou ed25519-sha256)
• bh= : le hash du corps du message
• b= : la signature elle-même

Le test récupère la clé publique via le DNS :

# Récupérer la clé publique DKIM
# Format : selecteur._domainkey.domaine
dig TXT google._domainkey.captaindns.com +short

La réponse contient un enregistrement TXT avec la clé publique :

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Le serveur de réception utilise cette clé publique pour vérifier la signature. Si le corps du message ou les en-têtes signés ont été modifiés après la signature, la vérification échoue.

RSA vs Ed25519 : la plupart des serveurs utilisent RSA-SHA256 avec des clés de 2048 bits. Ed25519 est plus rapide et génère des signatures plus courtes, mais le support côté réception n'est pas encore universel. Google Workspace et Microsoft 365 ne supportent que RSA pour la signature DKIM sortante en mars 2026.

Étape 3 : Évaluation DMARC et alignement

DMARC (Domain-based Message Authentication, Reporting, and Conformance) vérifie que SPF et DKIM sont non seulement valides, mais aussi alignés avec le domaine visible dans le champ From de l'email.

# Récupérer la politique DMARC
dig TXT _dmarc.captaindns.com +short

Résultat typique :

"v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"

Décortiquons chaque balise :

Balise	Valeur	Signification
v=DMARC1	obligatoire	Identifie l'enregistrement comme DMARC
p=	none, quarantine, reject	Politique appliquée aux emails qui échouent
rua=	adresse email	Destination des rapports agrégés (statistiques quotidiennes)
ruf=	adresse email	Destination des rapports forensiques (échantillons d'échecs)
adkim=	r (relaxed) ou s (strict)	Mode d'alignement DKIM
aspf=	r (relaxed) ou s (strict)	Mode d'alignement SPF
pct=	0-100	Pourcentage d'emails soumis à la politique

Alignement relaxed vs strict : en mode relaxed (adkim=r), le domaine de la signature DKIM (d=) doit partager le même domaine organisationnel que le From. Exemple : une signature d=mail.captaindns.com est alignée avec un From contact@captaindns.com. En mode strict (adkim=s), les domaines doivent correspondre exactement.

L'évaluation DMARC suit cette logique :

1. SPF passe et est aligné avec le From ? DMARC passe.
2. DKIM passe et est aligné avec le From ? DMARC passe.
3. Si aucun des deux n'est aligné : DMARC échoue, et la politique (p=) s'applique.

Un point souvent mal compris : DMARC passe si au moins un des deux mécanismes (SPF ou DKIM) passe avec alignement. Il n'est pas nécessaire que les deux réussissent.

Étape 4 : Contrôles complémentaires (MX, PTR, en-têtes, blacklists)

Le test vérifie ensuite des éléments techniques supplémentaires :

Enregistrements MX : le domaine doit avoir des enregistrements MX valides pointant vers des serveurs de messagerie actifs. Un domaine sans MX signale un domaine qui n'est pas configuré pour recevoir du courrier, ce qui est suspect pour un expéditeur.

dig MX captaindns.com +short
# 10 mx1.captaindns.com.
# 20 mx2.captaindns.com.

Reverse DNS (PTR) : l'IP du serveur d'envoi doit avoir un enregistrement PTR qui résout vers un nom d'hôte, et ce nom d'hôte doit résoudre en retour vers la même IP. C'est la vérification FCrDNS (Forward-confirmed reverse DNS).

# Vérifier le reverse DNS d'une IP
dig -x 203.0.113.10 +short
# mail.captaindns.com.

# Vérifier que le forward correspond
dig A mail.captaindns.com +short
# 203.0.113.10

Blacklists : l'IP d'envoi est vérifiée contre les principales listes noires (Spamhaus ZEN, Barracuda, SORBS, SpamCop). Une présence sur une seule blacklist majeure peut suffire à faire rejeter vos emails par la plupart des fournisseurs.

En-têtes email : le test vérifie la cohérence des en-têtes From, Reply-To, Message-ID, Date et la présence de champs obligatoires selon la RFC 5322.

Interpréter les résultats section par section

Une fois le test exécuté, le rapport affiche un score global et un détail par catégorie. Voici comment lire chaque section et identifier les actions prioritaires.

Section SPF (25 points)

Résultat	Points	Signification	Action
pass	25/25	L'IP d'envoi est autorisée par votre SPF	Aucune action
softfail	10/25	L'IP n'est pas explicitement autorisée (~all)	Passer à -all après vérification
fail	0/25	L'IP est explicitement rejetée par votre SPF	Ajouter l'IP ou l'include manquant
permerror	0/25	L'enregistrement SPF est invalide	Corriger la syntaxe ou réduire les lookups
none	0/25	Aucun enregistrement SPF trouvé	Créer un enregistrement SPF

Erreur fréquente : un résultat softfail donne l'impression que "ça passe quand même". En réalité, les serveurs modernes traitent le softfail presque comme un fail, surtout en combinaison avec un DMARC en mode quarantine ou reject. Le softfail ne devrait être qu'une phase transitoire pendant le déploiement initial du SPF.

Section DKIM (25 points)

Résultat	Points	Signification	Action
pass	25/25	Signature valide et clé publique trouvée	Aucune action
fail	0/25	Signature invalide (corps modifié, clé incorrecte)	Diagnostiquer la cause exacte
none	0/25	Aucune signature DKIM dans l'email	Configurer DKIM sur le serveur d'envoi
permerror	0/25	Clé publique malformée ou inaccessible	Vérifier l'enregistrement DNS du sélecteur

Le résultat dkim=fail est le plus complexe à diagnostiquer car les causes sont multiples : hash du body altéré par un relais intermédiaire, clé publique absente du DNS, signature expirée (balise x= dépassée), ou mauvais algorithme de canonicalisation. Consultez le guide de diagnostic DKIM fail pour un arbre de décision complet.

Section DMARC (20 points)

Résultat	Points	Signification	Action
pass	20/20	SPF ou DKIM aligné et valide	Aucune action
fail (p=none)	5/20	Échec mais pas de conséquence (mode surveillance)	Progresser vers quarantine puis reject
fail (p=quarantine)	0/20	Emails mis en spam	Corriger l'alignement SPF/DKIM
fail (p=reject)	0/20	Emails rejetés	Corriger l'alignement SPF/DKIM
none	0/20	Pas d'enregistrement DMARC	Créer un enregistrement DMARC

Le piège de p=none : cette politique est indispensable pendant la phase de déploiement, car elle permet de collecter des rapports sans impacter la livraison. Mais rester en p=none indéfiniment revient à ne pas avoir de DMARC du tout en termes de protection. Les fournisseurs de messagerie accordent un crédit de confiance aux domaines qui publient p=quarantine ou p=reject.

Section MX / PTR (15 points)

Vérification	Points	Critère
MX valides	5/15	Au moins un enregistrement MX résolvant vers une IP active
PTR configuré	5/15	Reverse DNS de l'IP d'envoi résolvant vers un nom d'hôte
FCrDNS	3/15	Forward-confirmed reverse DNS (aller-retour IP/nom d'hôte)
Pas de blacklist	2/15	IP absente des blacklists majeures

Le reverse DNS (PTR) est souvent négligé car il dépend du propriétaire de la plage IP, pas du propriétaire du domaine. Si vous utilisez un VPS ou un serveur dédié, le PTR se configure via le panneau de votre hébergeur. Si vous utilisez un service d'envoi (SendGrid, Mailgun, Brevo), le PTR est normalement géré par le prestataire sur ses IP dédiées.

Section En-têtes (15 points)

Vérification	Points	Critère
From valide	4/15	Adresse email syntaxiquement correcte avec domaine résolvant
Message-ID	3/15	Présent et au format RFC 5322
Date	3/15	Présente et dans un intervalle raisonnable (pas dans le futur, pas > 7 jours)
Reply-To cohérent	3/15	Même domaine que From ou domaine de confiance
Pas de X-Mailer suspect	2/15	Pas de logiciel de spam connu dans les en-têtes

Un en-tête Message-ID manquant ou malformé est un signal fort de spam pour les filtres. Chaque email doit avoir un Message-ID unique au format <identifiant@domaine>. Les serveurs de messagerie correctement configurés le génèrent automatiquement, mais certains scripts PHP ou bibliothèques d'envoi personnalisées l'omettent.

De 40/100 à 100/100 : les corrections pas à pas

Vous avez exécuté le test et le score n'est pas bon. Voici l'ordre exact des corrections, classées par impact sur le score.

Priorité 1 : Créer ou corriger SPF (+25 points)

Si votre SPF est absent ou invalide, c'est la correction qui apporte le plus de points immédiatement.

Cas 1 : Aucun enregistrement SPF

Créez un enregistrement DNS TXT sur votre domaine racine :

captaindns.com.  IN  TXT  "v=spf1 include:_spf.google.com -all"

Adaptez les mécanismes à vos services d'envoi :

Service	Include à ajouter
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com
SendGrid	include:sendgrid.net
Mailgun	include:mailgun.org
Brevo (ex-Sendinblue)	include:sendinblue.com
Amazon SES	include:amazonses.com
OVHcloud	include:mx.ovh.com

Cas 2 : SPF PermError (trop de lookups)

La limite de 10 lookups est la cause la plus fréquente du PermError. Chaque include: compte comme au moins 1 lookup, et les includes imbriqués s'additionnent. Google Workspace à lui seul consomme 4 lookups.

Pour diagnostiquer le problème :

# Compter les lookups de votre SPF
dig TXT captaindns.com +short | grep "v=spf1"
# Puis suivre chaque include récursivement
dig TXT _spf.google.com +short
# "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
# = 3 lookups supplémentaires pour ce seul include

Solutions de réduction :

• Remplacer les include: par des ip4: et ip6: directs quand les IP sont stables (SPF flattening)
• Utiliser les macros SPF (%{i} et exists:) pour les cas avancés
• Supprimer les includes de services que vous n'utilisez plus

Pour un guide détaillé sur le PermError, consultez le guide SPF PermError.

Cas 3 : Deux enregistrements SPF sur le même domaine

La RFC 7208 interdit strictement la présence de plusieurs enregistrements TXT commençant par v=spf1 sur le même domaine. Si vous en avez deux, le serveur retourne immédiatement permerror.

# Vérifier s'il y a des doublons
dig TXT captaindns.com +short | grep "v=spf1"
# Si deux lignes apparaissent : fusionner en un seul enregistrement

Fusionnez les deux enregistrements en un seul qui contient tous les mécanismes.

Priorité 2 : Configurer DKIM (+25 points)

DKIM nécessite deux éléments : une clé privée installée sur le serveur d'envoi (qui signe les messages) et une clé publique publiée dans le DNS (qui permet la vérification).

Configuration avec Google Workspace :

1. Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email
2. Sélectionnez votre domaine et cliquez "Generate new record"
3. Choisissez une longueur de clé de 2048 bits
4. Copiez l'enregistrement DNS CNAME ou TXT fourni
5. Publiez-le dans votre zone DNS au format google._domainkey.captaindns.com
6. Retournez dans la console et cliquez "Start authentication"

Configuration avec Microsoft 365 :

Microsoft 365 utilise deux enregistrements CNAME par domaine :

selector1._domainkey.captaindns.com  CNAME  selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com
selector2._domainkey.captaindns.com  CNAME  selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com

Vérification post-configuration :

# Vérifier que la clé publique est accessible
dig TXT google._domainkey.captaindns.com +short
# Devrait retourner un enregistrement contenant "v=DKIM1; k=rsa; p=MII..."

Si la commande ne retourne rien, le problème est DNS : soit l'enregistrement n'a pas encore propagé (attendre 24-48h), soit il y a une erreur de nommage dans le sélecteur.

Longueur de clé : utilisez 2048 bits minimum. Les clés 1024 bits sont considérées faibles depuis 2020. Certains fournisseurs rejettent déjà les signatures basées sur des clés RSA de moins de 1024 bits.

Priorité 3 : Publier et durcir DMARC (+20 points)

La mise en place de DMARC suit un cycle en trois phases.

Phase 1 : Surveillance (2 à 4 semaines)

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@captaindns.com; pct=100"

Pendant cette phase, aucun email n'est bloqué. Les rapports agrégés (rua=) arrivent quotidiennement au format XML et contiennent les statistiques d'authentification de tous les serveurs qui ont envoyé des emails pour votre domaine.

Analysez les rapports pour identifier :

• Les sources légitimes qui échouent (serveur de facturation, CRM, outil marketing)
• Les sources illégitimes (tentatives d'usurpation)
• Le taux d'alignement SPF et DKIM

Phase 2 : Quarantaine (4 à 8 semaines)

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@captaindns.com; pct=25"

Le pct=25 applique la politique de quarantaine à seulement 25 % des emails qui échouent. C'est un filet de sécurité : si une source légitime n'a pas encore été corrigée, 75 % de ses emails passent encore. Augmentez progressivement : 25 %, 50 %, 75 %, 100 %.

Phase 3 : Rejet

_dmarc.captaindns.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"

À ce stade, tout email qui échoue l'alignement DMARC est rejeté par le serveur de réception. C'est la configuration la plus sécurisée et celle qui apporte le plus de crédit de confiance auprès des fournisseurs.

Priorité 4 : Configurer le reverse DNS (+15 points MX/PTR)

Enregistrements MX : si votre domaine n'a pas d'enregistrement MX, ajoutez-en un pointant vers votre serveur de réception :

captaindns.com.  IN  MX  10  mx1.captaindns.com.
captaindns.com.  IN  MX  20  mx2.captaindns.com.

Reverse DNS : connectez-vous au panneau d'administration de votre hébergeur et configurez le PTR de votre IP d'envoi pour qu'il pointe vers le FQDN de votre serveur mail :

# Après configuration, vérifiez :
dig -x 203.0.113.10 +short
# Attendu : mail.captaindns.com.

Blacklists : si votre IP apparaît sur une blacklist, la procédure de retrait dépend de la liste :

Blacklist	Procédure	Délai
Spamhaus	Formulaire de retrait sur spamhaus.org	24-48h après correction
Barracuda	Formulaire sur barracudacentral.org	12-24h
SORBS	Retrait automatique après 48h sans spam	48h
SpamCop	Expiration automatique en 24h	24h

Priorité 5 : Nettoyer les en-têtes (+15 points)

Les problèmes d'en-têtes sont souvent causés par des scripts d'envoi personnalisés ou des bibliothèques mal configurées.

Liste de contrôle des en-têtes :

• Le champ From utilise une adresse avec votre domaine, pas un domaine générique
• Le Message-ID est présent et au format <unique-id@captaindns.com>
• Le champ Date est présent et correct (fuseau horaire inclus)
• Le Reply-To, s'il est présent, utilise un domaine cohérent avec le From
• Aucun en-tête X-Mailer référençant un outil de spam connu
• Le Content-Type spécifie le charset (UTF-8 recommandé)

Si vous utilisez PHP mail(), passez à une bibliothèque comme PHPMailer ou SwiftMailer qui génère des en-têtes conformes. Si vous utilisez un framework (Laravel, Django, Rails), les en-têtes sont généralement corrects par défaut.

Les erreurs les plus fréquentes

SPF PermError : la limite de 10 lookups

C'est l'erreur la plus répandue. Un domaine qui utilise Google Workspace (4 lookups), SendGrid (2 lookups), Mailchimp (2 lookups) et un serveur interne (1 lookup avec un a:) atteint déjà 9 lookups. L'ajout d'un seul service supplémentaire provoque le PermError.

Le diagnostic est simple :

dig TXT captaindns.com +short | grep "v=spf1"
# Comptez chaque include, a, mx, redirect, exists
# Suivez les includes imbriqués récursivement

Le correctif dépend de votre situation :

• Supprimez les services inutilisés : vérifiez si chaque include correspond à un service actif
• Utilisez le SPF flattening : remplacez les includes par les IP finales (attention à la maintenance)
• Dédiez un sous-domaine : envoyez le marketing depuis news.captaindns.com avec son propre SPF

Si malgré ces corrections vos emails finissent toujours en spam, le problème dépasse le SPF. Consultez le guide diagnostic complet du spam pour analyser les autres causes (réputation, contenu, engagement).

DKIM fail : body hash did not verify

Cette erreur signifie que le contenu de l'email a été modifié après la signature. Les causes les plus courantes :

1. Relais intermédiaire : un serveur entre l'envoi et la réception a ajouté un pied de page, réécrit des URL ou injecté un pixel de suivi
2. Antivirus ou DLP : un logiciel de sécurité a modifié le corps du message
3. Liste de diffusion : les serveurs de listes (Listserv, Sympa) ajoutent souvent un pied de page de désabonnement qui casse la signature

Le correctif consiste à identifier quel composant de votre chaîne d'envoi modifie le message après la signature DKIM, puis à reconfigurer l'ordre des opérations pour que la modification se fasse avant la signature.

Pour les listes de diffusion, le protocole ARC (Authenticated Received Chain) permet de préserver les résultats d'authentification à travers les relais. Gmail et Microsoft supportent ARC depuis 2019.

DMARC fail : défaut d'alignement

L'erreur la plus subtile. SPF passe, DKIM passe, mais DMARC échoue quand même. La cause : aucun des deux n'est aligné avec le domaine du champ From.

Scénario typique : vous envoyez depuis contact@captaindns.com, mais votre prestataire d'envoi signe avec d=sendgrid.net (DKIM non aligné) et l'enveloppe SMTP utilise bounces@sendgrid.net (SPF non aligné). Résultat : les deux authentifications passent techniquement, mais aucune n'est alignée avec captaindns.com.

Correctif :

• Configurez votre prestataire pour signer avec d=captaindns.com (DKIM aligné)
• Configurez le return-path (enveloppe SMTP) pour utiliser un sous-domaine de votre domaine (SPF aligné)

La plupart des prestataires d'envoi (SendGrid, Mailgun, Brevo, Postmark) proposent une option "Domain Authentication" ou "Sender Authentication" qui configure automatiquement l'alignement DKIM et SPF.

IP sur une blacklist

Votre score MX/PTR chute à cause d'une IP blacklistée. Les causes principales :

• IP partagée : si vous êtes sur une IP partagée avec d'autres clients de votre hébergeur, le spam d'un autre client peut vous affecter
• Compromission : un script sur votre serveur envoie du spam à votre insu (formulaire de contact exploité, compte email compromis)
• Historique de l'IP : l'IP que vous venez de recevoir était précédemment utilisée par un spammeur

La vérification est immédiate :

# Vérifier Spamhaus
dig +short 10.113.0.203.zen.spamhaus.org
# Si une réponse 127.0.0.x apparaît, l'IP est listée

Notez que l'IP est inversée dans la requête DNS (203.0.113.10 devient 10.113.0.203).

Quand tester ? Les 5 situations critiques

Un test de délivrabilité n'est pas un contrôle ponctuel. Voici les cinq moments où un test est indispensable.

1. Avant le lancement d'une campagne email

Chaque campagne marketing devrait être précédée d'un test. Un problème d'authentification sur un envoi de 50 000 emails signifie 50 000 emails potentiellement perdus. Le test prend 30 secondes et peut sauver une campagne entière.

Envoyez un email de test à l'adresse fournie par le mail tester, consultez le rapport et corrigez les problèmes avant l'envoi en masse.

2. Après un changement de prestataire d'envoi

La migration d'un service d'envoi à un autre est le moment le plus risqué pour la délivrabilité. Il faut mettre à jour le SPF (remplacer l'ancien include par le nouveau), reconfigurer DKIM (nouveau sélecteur, nouvelle clé), et vérifier l'alignement DMARC.

Liste de contrôle pour la migration :

• Mettre à jour le SPF : supprimer l'ancien include, ajouter le nouveau
• Configurer DKIM chez le nouveau prestataire et publier la clé dans le DNS
• Vérifier l'alignement DMARC avec le nouveau prestataire
• Tester la délivrabilité avant de basculer le trafic
• Conserver l'ancien SPF include pendant 48h (emails en transit)

3. Après une modification DNS

Toute modification de votre zone DNS peut impacter la délivrabilité : changement de TTL, mise à jour d'un enregistrement TXT, migration de registrar, activation de DNSSEC. Les erreurs de copier-coller dans les enregistrements DNS sont fréquentes et le résultat est un SPF ou DKIM cassé sans aucun message d'erreur visible.

4. Quand les taux d'ouverture chutent

Une baisse soudaine des taux d'ouverture (plus de 10 % de variation sur une semaine) peut indiquer un problème de délivrabilité. Avant de chercher la cause dans le contenu ou l'objet des emails, testez votre authentification. Un SPF qui dépasse soudainement les 10 lookups (parce qu'un prestataire a ajouté un include imbriqué) peut provoquer une chute brutale.

5. Sur un rythme mensuel, en prévention

Les configurations DNS changent, les prestataires mettent à jour leurs enregistrements, les clés DKIM doivent être renouvelées. Un test mensuel détecte les régressions avant qu'elles n'impactent vos envois. Programmez un rappel mensuel et vérifiez que votre score reste à 100/100.

Plan d'action recommandé

1. Exécutez un test de délivrabilité sur le mail tester de CaptainDNS. Envoyez un email de test et récupérez votre score détaillé section par section.

2. Corrigez les problèmes par ordre d'impact : SPF d'abord (25 points), puis DKIM (25 points), puis DMARC (20 points). Chaque correction augmente immédiatement votre score et votre taux de délivrabilité.

3. Vérifiez vos corrections en relançant le test après chaque modification DNS. Attendez la propagation DNS (5 à 60 minutes selon le TTL) avant de retester.

4. Mettez en place le monitoring DMARC : les rapports agrégés (rua=) vous alertent automatiquement quand un problème d'authentification apparaît. Analysez-les au moins une fois par semaine pendant la phase de montée en charge, puis mensuellement.

5. Planifiez un test mensuel pour détecter les régressions. Les configurations DNS évoluent silencieusement (prestataire qui modifie ses includes, clé DKIM qui expire, IP qui change de blacklist). Un test mensuel coûte 30 secondes et peut éviter des semaines de délivrabilité dégradée.

FAQ

Qu'est-ce qu'un mail tester et comment fonctionne-t-il ?

Un mail tester est un outil qui analyse la délivrabilité de vos emails en vérifiant votre configuration DNS (SPF, DKIM, DMARC), la réputation de votre IP d'envoi, vos en-têtes email et la présence éventuelle de votre IP sur des blacklists. Vous envoyez un email de test à une adresse fournie par l'outil, et celui-ci produit un rapport détaillé avec un score sur 100 et les corrections à appliquer.

Quel score de délivrabilité faut-il viser ?

Visez un score de 100/100. Un score supérieur à 80/100 est acceptable pour la plupart des envois transactionnels. En dessous de 70/100, vos emails ont une probabilité significative d'être classés en spam. En dessous de 50/100, la majorité des fournisseurs (Gmail, Outlook, Yahoo) rejettera ou filtrera vos messages.

SPF, DKIM et DMARC sont-ils tous obligatoires ?

Depuis février 2024, Gmail et Yahoo exigent au minimum SPF ou DKIM pour tous les expéditeurs. Pour les expéditeurs de masse (plus de 5 000 emails par jour vers Gmail), les trois sont obligatoires : SPF et DKIM valides, plus un enregistrement DMARC publié. En pratique, configurer les trois est recommandé pour tous les domaines, quelle que soit la volumétrie.

Qu'est-ce que la limite de 10 DNS lookups SPF ?

La RFC 7208 limite à 10 le nombre de requêtes DNS récursives pendant l'évaluation d'un enregistrement SPF. Les mécanismes include, a, mx, redirect et exists comptent chacun comme un lookup. Les includes imbriqués s'additionnent : un include qui contient lui-même 3 includes consomme 4 lookups au total. Au-delà de 10, le serveur retourne un PermError et votre SPF est considéré invalide.

Pourquoi mon DMARC échoue alors que SPF et DKIM passent ?

DMARC vérifie non seulement que SPF et DKIM passent, mais aussi qu'ils sont alignés avec le domaine du champ From de l'email. Si votre prestataire d'envoi signe avec son propre domaine DKIM et utilise sa propre adresse en enveloppe SMTP, ni SPF ni DKIM ne sont alignés avec votre domaine From. Configurez votre prestataire pour utiliser votre domaine (Domain Authentication) afin de résoudre ce problème.

Combien de temps faut-il pour que les corrections DNS prennent effet ?

Le délai dépend du TTL (Time To Live) de vos enregistrements DNS. Un TTL de 300 secondes (5 minutes) signifie que les serveurs de réception verront votre modification en moins de 5 minutes. Un TTL de 86400 (24 heures) peut nécessiter jusqu'à 24 heures. Avant de modifier un enregistrement critique, réduisez d'abord le TTL à 300, attendez la propagation de ce nouveau TTL, puis effectuez la modification.

Comment savoir si mon IP est sur une blacklist ?

Interrogez les principales blacklists via une requête DNS inversée. Par exemple, pour vérifier l'IP 203.0.113.10 sur Spamhaus : dig +short 10.113.0.203.zen.spamhaus.org. Si une réponse de type 127.0.0.x est retournée, l'IP est listée. Un outil de vérification de blacklist automatise cette vérification sur plusieurs dizaines de listes simultanément.

Faut-il tester à chaque envoi de campagne ?

Oui, pour les campagnes marketing en masse. Un test prend moins d'une minute et peut éviter de gaspiller un envoi entier. Pour les emails transactionnels (confirmations, factures), un test mensuel est suffisant, sauf après un changement de configuration DNS ou de prestataire d'envoi. L'objectif est de détecter les régressions avant qu'elles n'impactent la délivrabilité.

Quelle est la différence entre alignement relaxed et strict en DMARC ?

En mode relaxed (adkim=r, aspf=r), le domaine de la signature DKIM ou de l'enveloppe SPF doit partager le même domaine organisationnel que le From. Exemple : une signature d=mail.captaindns.com est alignée avec un From @captaindns.com. En mode strict (adkim=s, aspf=s), les domaines doivent correspondre exactement. Le mode relaxed est recommandé pour la plupart des déploiements car il tolère l'utilisation de sous-domaines.

Que faire si mon score ne monte pas malgré les corrections ?

Vérifiez que la propagation DNS est terminée (attendez au moins le TTL de vos enregistrements). Testez chaque composant individuellement : SPF seul (dig TXT captaindns.com), DKIM seul (dig TXT selecteur._domainkey.captaindns.com), DMARC seul (dig TXT _dmarc.captaindns.com). Si les enregistrements DNS sont corrects mais le score ne change pas, le problème peut venir de la réputation de l'IP (blacklist) ou du contenu de l'email de test.

Glossaire

• SPF (Sender Policy Framework) : protocole d'authentification email défini par la RFC 7208 qui liste les serveurs autorisés à envoyer des emails pour un domaine via un enregistrement DNS TXT commençant par v=spf1.
• DKIM (DomainKeys Identified Mail) : protocole d'authentification email défini par la RFC 6376 qui ajoute une signature cryptographique à chaque email, vérifiable via une clé publique publiée dans le DNS.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) : protocole défini par la RFC 7489 qui vérifie l'alignement SPF et DKIM avec le domaine From et définit la politique de traitement des échecs (none, quarantine, reject).
• Alignement : en contexte DMARC, correspondance entre le domaine utilisé par SPF ou DKIM et le domaine visible dans le champ From de l'email. Peut être relaxed (même domaine organisationnel) ou strict (correspondance exacte).
• PermError : erreur permanente retournée quand un enregistrement SPF est structurellement invalide (trop de lookups, syntaxe incorrecte, doublons). L'enregistrement ne peut pas être évalué.
• PTR (Pointer Record) : enregistrement DNS qui associe une adresse IP à un nom d'hôte (reverse DNS). Utilisé par les serveurs de réception pour vérifier l'identité du serveur d'envoi.
• FCrDNS (Forward-confirmed reverse DNS) : vérification en deux étapes. Le reverse DNS de l'IP donne un nom d'hôte, et la résolution de ce nom d'hôte doit retourner l'IP d'origine.
• Blacklist (DNSBL) : liste de blocage basée sur le DNS qui répertorie les adresses IP connues pour envoyer du spam. Les principales sont Spamhaus, Barracuda, SORBS et SpamCop.
• Sélecteur DKIM : identifiant (chaîne de caractères) qui permet de localiser la clé publique DKIM dans le DNS. L'enregistrement est publié sur selecteur._domainkey.captaindns.com.
• RFC 7208 : spécification officielle du protocole SPF qui définit la syntaxe des enregistrements, la limite de 10 lookups, les void lookups et les résultats possibles.
• ARC (Authenticated Received Chain) : protocole qui préserve les résultats d'authentification email à travers les relais intermédiaires (listes de diffusion, transferts). Supporté par Gmail et Microsoft.
• RFC 8058 : spécification du mécanisme de désabonnement en un clic (One-Click Unsubscribe) via l'en-tête List-Unsubscribe-Post, requis par Gmail pour les expéditeurs de masse depuis 2024.

---

Testez votre délivrabilité maintenant : utilisez le mail tester de CaptainDNS pour obtenir votre score sur 100 et la liste exacte des corrections à appliquer. Un test prend 30 secondes et peut transformer vos taux de livraison.

---

Sources

• RFC 7208 - Sender Policy Framework (SPF)
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Google - Email sender guidelines (2024)
• Yahoo - Sender best practices and requirements
• Validity - 2025 Email Deliverability Benchmark Report