SPF, DKIM et DMARC pour le cold email : checklist de configuration

Pourquoi les cold emails échouent quand l'authentification DNS est incorrecte

L'authentification des emails est la façon dont une boîte de réception vérifie si votre message est réellement autorisé à provenir de votre domaine. Il ne s'agit pas d'écrire un meilleur texte. Il s'agit de prouver une identité.

Lorsque vous envoyez un cold email, le serveur récepteur regarde le domaine dans l'adresse From et effectue trois vérifications principales :

• SPF : un serveur autorisé a-t-il envoyé ce message ?
• DKIM : le message est-il signé par le domaine ?
• DMARC : que doit faire le récepteur si ces vérifications échouent, et les domaines sont-ils alignés ?

Les nouveaux domaines d'envoi sont jugés plus strictement car ils n'ont pas d'historique. Un domaine tout neuf avec des signaux DNS faibles ou cassés paraît risqué, même si votre intention est légitime. C'est pourquoi les erreurs d'authentification affectent l'outreach à froid plus vite que les marques établies.

Les mauvais enregistrements DNS causent généralement des problèmes de trois manières discrètes : votre email est accepté mais atterrit en spam, il est rejeté directement (hard bounces ou blocages), ou il passe parfois mais votre domaine commence à se forger une mauvaise réputation.

Les petites erreurs sont souvent la cause. Deux enregistrements TXT SPF distincts peuvent provoquer une erreur. Une clé DKIM collée avec un caractère manquant ne se vérifiera pas. Un DMARC défini sur une politique agressive avant que tout ne soit aligné peut bloquer des envois normaux.

Cette checklist se concentre sur SPF, DKIM et DMARC en termes pratiques : quoi publier, quoi éviter et comment vérifier les résultats avant de monter en volume. Elle ne couvre pas la rédaction, la qualité des listes, l'adéquation de l'offre ou la conformité locale.

Le modèle simple : ce qui est contrôlé quand vous envoyez

Quand vous envoyez un cold email, il y a généralement deux domaines impliqués, et les mélanger crée beaucoup de confusion.

Le domaine d'envoi est ce que le destinataire voit dans l'adresse From ([email protected]). Le domaine de la boîte (parfois différent) est le domaine qui envoie réellement le message en coulisses, comme un sous-domaine d'envoi dédié ou un domaine détenu par le fournisseur. Pour une bonne délivrabilité, ils doivent être cohérents ou au moins clairement connectés.

Du domaine From à la boîte : les trois vérifications

La plupart des boîtes suivent le flux de base suivant :

1. SPF vérifie le Return-Path caché (aussi appelé envelope sender) et demande si ce serveur est autorisé à envoyer pour ce domaine.
2. DKIM vérifie la signature DKIM et demande si le domaine qui signe correspond à ce qui a été envoyé.
3. DMARC regarde le domaine visible dans le From et demande si SPF et/ou DKIM sont alignés avec lui, puis applique votre politique.

Alignement, sans jargon

L'alignement, c'est simplement « est-ce que les domaines correspondent ? ». Il y a trois endroits à regarder :

• From : ce que voient les humains (exemple : @yourdomain.com)
• Return-Path : ce que SPF utilise (peut être @mail.yourdomain.com ou autre)
• DKIM d= : le domaine qui a signé le message (exemple : d=yourdomain.com)

DMARC passe quand le domaine From est aligné avec SPF (domaine du Return-Path) et/ou avec DKIM (le domaine d=). Tout n'a pas besoin d'être identique, mais cela doit être intentionnel.

Que se passe-t-il quand les vérifications échouent

Les fournisseurs ne réagissent pas tous de la même façon, mais les résultats sont prévisibles :

• p=none (surveillance) : le courrier arrive souvent encore, et vous collectez des rapports.
• p=quarantine : le courrier a plus de chances d'atterrir en spam.
• p=reject : le courrier est bloqué.

Même avant que DMARC soit strict, des échecs répétés diminuent souvent la placement en boîte de réception au fil du temps.

Exemple : vous envoyez depuis [email protected], mais SPF n'autorise qu'un domaine différent et DKIM signe en d=anotherdomain.com. Le message peut paraître « sans propriétaire », donc les filtres se montrent plus prudents.

Avant de toucher au DNS : préparer une configuration propre

La plupart des problèmes de délivrabilité commencent avant que quelqu'un ajoute un enregistrement DNS. Bien préparer rend la configuration plus rapide, plus propre et plus facile à dépanner.

Commencez par décider quel domaine apparaîtra dans l'adresse From. Beaucoup d'équipes utilisent un domaine d'envoi dédié (ou un sous-domaine) pour que leur domaine principal de l'entreprise ne soit pas exposé en premier lieu si quelque chose tourne mal.

Ensuite, choisissez comment vous allez envoyer et récupérer les valeurs exactes d'enregistrement dont vous avez besoin. Votre fournisseur d'email vous donnera une valeur SPF spécifique, des noms de sélecteurs DKIM et des clés, et un enregistrement DMARC suggéré. Ne devinez pas et ne réutilisez pas des enregistrements d'un autre domaine.

Avant de faire des changements, confirmez quatre éléments basiques : quel domaine From exact vous utiliserez, quels fournisseur(s) enverront le mail, où le DNS est réellement géré, et qui a la permission de publier des enregistrements TXT et CNAME.

Vérifiez aussi que vous êtes dans le bon tableau de bord. Les gens achètent souvent un domaine à un endroit, hébergent le DNS ailleurs, et éditent les enregistrements au mauvais endroit. Si vous n'êtes pas sûr, vérifiez quels nameservers le domaine utilise et connectez-vous au prestataire qui les contrôle.

Un plan de changement simple aide à prévenir des éditions « utiles » qui cassent l'email existant. Typiquement, vous mettrez à jour SPF (avec précaution, surtout si un enregistrement existe déjà), ajouterez DKIM, et publierez DMARC en mode surveillance. Laissez MX, A et enregistrements web non liés tranquilles sauf si vous savez pourquoi vous les modifiez.

SPF : ajouter les bons expéditeurs et éviter les limites de recherches

SPF est un enregistrement TXT DNS qui indique aux fournisseurs quelles machines sont autorisées à envoyer du courrier pour votre domaine. Dans l'outreach à froid, SPF est l'une des premières vérifications qui décide si votre message paraît normal ou suspect.

Un bon enregistrement SPF est une petite liste blanche couvrant chaque endroit pouvant envoyer au nom de votre domaine : votre solution cold email, Google Workspace ou Microsoft 365 (si vous les utilisez), et tout outil support/CRM qui envoie des mails pour votre compte.

Que mettre dans votre enregistrement SPF

La plupart des nouveaux domaines n'ont besoin que de quelques éléments :

• include: quand un fournisseur vous dit d'inclure son SPF. Gardez les includes au minimum car ils coûtent des recherches DNS.
• ip4:/ip6:: quand vous avez une IP d'envoi fixe. Cela évite des recherches, mais ne fonctionne que si les IP sont vraiment stables.
• a et mx : seulement si le serveur propre de votre domaine ou l'échangeur de mail envoie directement (beaucoup de setups cold email n'en ont pas besoin).

Voici une forme d'exemple propre (vos valeurs seront différentes) :

v=spf1 include:YOUR-SENDER-SPF ip4:203.0.113.10 ~all

Choisir la bonne terminaison : -all vs ~all

La dernière partie est votre règle par défaut pour tout ce qui n'est pas listé.

~all (soft fail) est un démarrage plus sûr pendant que vous testez et pourriez avoir oublié un expéditeur. -all (hard fail) est meilleur une fois que vous êtes confiant, car il indique clairement aux fournisseurs de rejeter les expéditeurs non autorisés.

Pour les nouveaux domaines outbound, commencez avec ~all pendant la configuration et les premiers envois, puis passez à -all après avoir vérifié qu'aucun expéditeur légitime ne tombe en échec.

Rester sous la limite de 10 recherches

SPF a une limite stricte de 10 recherches DNS. Trop d'includes peuvent casser SPF et nuire discrètement à la délivrabilité.

Pour rester en dessous de la limite, maintenez peu d'includes, évitez les chaînes d'includes imbriquées, supprimez les outils anciens dont vous n'envoyez plus, et assurez-vous de publier un seul enregistrement SPF TXT par domaine. Plusieurs enregistrements SPF peuvent provoquer une permerror.

DKIM : publier les clés correctement et garder des sélecteurs propres

DKIM ajoute une signature numérique à chaque email que vous envoyez. Les serveurs récepteurs utilisent la clé publique dans votre DNS pour vérifier que le message n'a pas été modifié et que votre domaine est autorisé à signer le courrier. DKIM est souvent ce qui donne à un nouveau domaine une apparence consistante dans le temps.

Comment fonctionnent les sélecteurs (et pourquoi les noms comptent)

Un sélecteur DKIM est une étiquette qui pointe vers une clé publique spécifique. Votre système d'envoi signe les emails avec ce sélecteur, et le récepteur consulte un enregistrement DNS à :

selector._domainkey.yourdomain.com

Les sélecteurs permettent de faire une rotation des clés sans casser le courrier, mais ils peuvent aussi créer de la confusion. Si vous réutilisez le même sélecteur pour toujours, les rotations deviennent risquées. Si vous créez constamment de nouveaux sélecteurs, votre DNS devient en désordre.

Une approche simple est d'utiliser un sélecteur stable et descriptif comme s1, mail, ou 2026q1, puis de faire des rotations intentionnelles quand nécessaire.

TXT vs CNAME : ce que vous verrez dans le DNS

Certains fournisseurs publient DKIM en tant qu'enregistrement TXT contenant la clé complète. D'autres vous donnent un CNAME qui pointe vers un enregistrement de clé hébergé. Les deux fonctionnent si (et seulement si) vous publiez exactement ce que votre fournisseur attend.

Les problèmes DKIM les plus courants sont simples : mauvais type d'enregistrement (TXT vs CNAME), guillemets supplémentaires ou retours à la ligne cachés, coller seulement une partie de la clé, mettre l'enregistrement sur le domaine racine au lieu de selector._domainkey, ou laisser d'anciens sélecteurs actifs avec des enregistrements conflictuels.

Si la vérification DKIM échoue, ne devinez pas. Recopiez la valeur depuis le fournisseur, republiez-la proprement, puis retestez après la mise à jour DNS.

DMARC : commencer par la surveillance, puis durcir la politique

DMARC est la couche « que doivent faire les récepteurs en cas d'échec ? ». SPF et DKIM indiquent à Gmail ou Outlook quoi vérifier. DMARC ajoute une politique claire (none, quarantine, reject) et exige l'alignement avec le domaine visible dans le From.

Une manière pratique de commencer est la surveillance. Publiez DMARC avec p=none afin de voir ce qui passe et ce qui échoue sans risquer de chutes de délivrabilité dues à une politique trop stricte. Laissez-le tourner quelques jours pendant que vous envoyez de faibles volumes, puis durcissez par étapes.

Voici un modèle d'enregistrement de départ sûr (ajustez les emails et le domaine) :

_dmarc.example.com TXT \"v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100; fo=1\"

Gardez les options simples. L'alignement strict (adkim=s et aspf=s) est un bon paramètre par défaut pour des domaines outbound dédiés que vous contrôlez. pct=100 maintient un comportement cohérent. fo=1 est un réglage raisonnable pour recevoir un rapport lorsqu'une vérification échoue.

Attention aux adresses de rapport. Les rapports agrégés (rua) peuvent être utiles, mais seulement si quelqu'un les consulte. Les rapports judiciaires (ruf) sont souvent bloqués et peuvent poser des problèmes de confidentialité et de bruit, il vaut donc généralement mieux éviter ruf.

Pas à pas : authentifier un domaine d'envoi tout neuf

Traitez un domaine frais comme une pièce blanche. Vos enregistrements DNS doivent correspondre à votre expéditeur réel, donc décidez à l'avance d'où vous allez envoyer.

1) Nettoyez d'abord la zone DNS

Dans votre hébergeur DNS, recherchez des enregistrements TXT existants qui mentionnent SPF, DKIM ou DMARC. Les nouveaux domaines ont parfois des enregistrements de démarrage, d'anciens tests ou des doublons d'une tentative précédente. Supprimez ce que vous ne reconnaissez pas, et assurez-vous de n'avoir qu'un seul enregistrement SPF TXT pour le domaine racine.

2) Ajoutez l'authentification dans un ordre sûr

Ajoutez un type d'enregistrement à la fois, puis confirmez qu'il est visible avant de passer au suivant :

1. SPF : publiez un unique enregistrement SPF TXT qui n'inclut que les services qui vont envoyer pour ce domaine.
2. DKIM : ajoutez les enregistrements DKIM fournis par votre expéditeur (souvent des CNAME, parfois un TXT). Assurez-vous que le sélecteur correspond aux paramètres de signature de votre expéditeur.
3. DMARC : publiez un enregistrement DMARC TXT sur _dmarc.yourdomain avec p=none au départ.

3) Attendez, puis revérifiez les valeurs exactes

Les changements DNS ne sont pas toujours instantanés. Après avoir publié les enregistrements, revérifiez ce qui est réellement en ligne. Confirmez qu'il n'y a qu'un seul enregistrement SPF, que DKIM correspond exactement, et que DMARC est bien sur le sous-domaine _dmarc.

4) Envoyez de vrais emails et vérifiez les "pass" dans les en-têtes

Envoyez quelques emails simples (pas de pièces jointes, pas d'HTML lourd) vers des comptes que vous contrôlez, comme Gmail et Outlook. Ouvrez les détails du message et cherchez Authentication-Results. Vous voulez voir spf=pass, dkim=pass et dmarc=pass.

Si SPF échoue, c'est généralement un include erroné ou plusieurs enregistrements SPF. Si DKIM échoue, c'est souvent un décalage de sélecteur ou une faute de frappe dans la valeur DNS.

Une fois que vous obtenez des passes cohérents, passez au warm-up et augmentez progressivement le volume.

Erreurs DNS courantes qui nuisent discrètement à la délivrabilité

La plupart des problèmes avec un nouveau domaine ne sont pas des échecs dramatiques. Ce sont des détails DNS mineurs qui laissent quand même passer le courrier, mais font que les récepteurs vous font moins confiance.

Deux problèmes reviennent constamment :

D'abord, publier deux enregistrements SPF sur le même domaine. Un domaine ne doit avoir qu'un seul enregistrement TXT SPF. Si vous avez besoin de Google plus un outil d'envoi, fusionnez tout dans un seul enregistrement v=spf1 et conservez une seule terminaison (~all ou -all).

Ensuite, atteindre une permerror SPF à cause de trop de recherches. Les includes ajoutent des recherches, et les includes imbriqués en ajoutent encore plus. Épurez les outils non utilisés, gardez l'enregistrement court, et évitez d'empiler des prestataires « au cas où ».

Côté DKIM, l'échec le plus fréquent est le décalage de selector. Votre fournisseur signe avec un sélecteur spécifique (comme s1 ou default). Si votre DNS publie un autre sélecteur, les récepteurs ne peuvent pas vérifier DKIM même si un enregistrement existe.

Les échecs DMARC confondent souvent parce que SPF peut passer alors que DMARC échoue. DMARC exige l'alignement avec le domaine From visible. Si vous envoyez depuis [email protected] mais que le Return-Path est brand-mail.com et que DKIM signe en d=brand-mail.com, vous pouvez obtenir SPF pass mais DMARC fail.

Checklist rapide : vérification finale en 10 minutes

Avant d'envoyer en volume, faites un rapide passage pour vous assurer que les enregistrements sont propres et que vos messages s'authentifient réellement.

Confirmez qu'il y a exactement un enregistrement SPF TXT sur le domaine racine. Confirmez que DKIM est publié pour le domaine que vous utilisez en From et que le sélecteur correspond à ce que votre outil d'envoi utilise. Confirmez qu'il y a exactement un enregistrement DMARC sur _dmarc.example.com, et commencez avec p=none.

Si vous venez de changer des enregistrements, patientez un peu. Beaucoup de « ça échoue encore » viennent du cache DNS.

Ensuite, envoyez un test réel à une boîte que vous pouvez inspecter et vérifiez Authentication-Results. Vous cherchez SPF=pass, DKIM=pass et DMARC=pass.

Corrections rapides quand quelque chose échoue :

• SPF échoue : include incorrect, mauvais domaine (racine vs sous-domaine), ou deux enregistrements SPF.
• DKIM échoue : décalage de selector, espaces/guillemets en trop, ou signature désactivée.
• DMARC échoue : enregistrement DMARC manquant, publié sur le domaine racine au lieu de _dmarc, ou SPF/DKIM non alignés avec le domaine From.

Exemple et prochaines étapes pour un nouveau domaine cold email

Une configuration simple ressemble à ceci : vous achetez un domaine neuf juste pour l'outbound et créez quelques boîtes (alex@, sam@, info@). Vous gardez votre domaine principal séparé pour qu'une erreur ne contamine pas l'email du quotidien.

Un calendrier réaliste :

• Jour 0 : Publier SPF, DKIM et DMARC en mode surveillance (p=none).
• Jour 1 : Envoyer des tests et vérifier SPF/DKIM/DMARC passent. Corriger fautes et noms d'hôte erronés.
• Jours 2-3 : Commencer un très faible volume pendant le warm-up.
• Fin de la semaine 1 : Revoir les rapports DMARC et les bounces, puis corriger tout ce qui est désaligné.
• Semaine 2+ : Si tout est stable, passer à p=quarantine, puis plus tard à p=reject.

Si vous voyez SPF passer mais DMARC échouer, cela signifie généralement que l'alignement est cassé, pas que le DNS est complètement faux. La correction la plus rapide est souvent de s'assurer que DKIM est activé et signe avec votre domaine d'envoi, car l'alignement DKIM est généralement plus stable que SPF quand les outils changent.

Après que l'authentification est correcte, les résultats viennent du comportement, pas des seuls enregistrements. Warm-up lentement, gardez un volume initial bas, documentez les changements DNS, évitez de changer de prestataire dans le premier mois, et surveillez bounces et désinscriptions de près.

Si vous voulez réduire le nombre d'outils impliqués, LeadTrain (leadtrain.app) combine la configuration de domaine, SPF/DKIM/DMARC, le warm-up, les séquences multi-étapes et la classification des réponses sur une même plateforme, ce qui peut simplifier le maintien d'un alignement cohérent lorsque vous ajoutez des domaines et des boîtes.