SPF, DKIM, DMARC : la configuration à faire avant le premier envoi

Un commercial nous a écrit un jour : « on envoie 30 emails par jour à des prospects qualifiés et la moitié atterrit en spam ». En creusant, aucun des trois enregistrements DNS n'était en place. Ce guide couvre la configuration SPF DKIM DMARC pas à pas sur Google Workspace et Microsoft 365, avant de lancer le moindre email de prospection ciblée — ce n'est pas une astuce marketing, c'est un prérequis technique au même titre qu'un nom de domaine qui résout.

Pourquoi ces trois enregistrements avant d'envoyer quoi que ce soit

SPF, DKIM et DMARC répondent à une seule question posée par les serveurs de réception (Gmail, Outlook, Yahoo, et tous les filtres anti-spam d'entreprise) : est-ce que l'expéditeur qui prétend envoyer depuis votre-entreprise.fr est vraiment autorisé à le faire ? Sans réponse claire, la boîte réceptrice applique le principe de précaution et pousse le message en spam, voire le rejette.

Pour une prospection B2B adressée — des emails personnalisés envoyés en petit volume à des décideurs identifiés, pas une newsletter de masse — l'enjeu est encore plus direct : un seul email mal authentifié qui finit en spam, c'est un décideur qui ne verra jamais votre message, sans même savoir qu'il a existé.

Ces trois briques ne sont pas une option de confort. Depuis les nouvelles exigences de Google et Yahoo sur l'authentification des expéditeurs, l'absence de SPF, DKIM ou DMARC peut suffire à faire tomber vos emails en dessous du seuil de délivrabilité, quel que soit le soin apporté au contenu.

SPF : autoriser vos serveurs d'envoi

SPF (Sender Policy Framework) est un enregistrement TXT posé sur le DNS de votre domaine qui liste les serveurs autorisés à envoyer des emails en votre nom. Le serveur qui reçoit consulte ce enregistrement et compare l'IP d'origine du message à la liste déclarée.

Sur Google Workspace, l'enregistrement type ressemble à v=spf1 include:_spf.google.com ~all. Sur Microsoft 365, ce sera v=spf1 include:spf.protection.outlook.com -all. Le point important : si vous envoyez aussi depuis un outil tiers (CRM, plateforme de prospection, outil de facturation qui envoie des relances), il faut l'ajouter dans le même enregistrement SPF — un domaine ne peut avoir qu'un seul enregistrement SPF actif, sinon les vérifications échouent silencieusement.

Le qualificateur final compte : ~all (softfail) signale un envoi suspect sans le bloquer, -all (fail) le rejette. Pour un domaine de prospection actif, ~all pendant la mise en place puis un passage prudent vers -all une fois tous les émetteurs légitimes recensés est l'approche la plus sûre.

• Recenser tous les services qui envoient des emails au nom du domaine avant de toucher au SPF
• Un seul enregistrement TXT SPF par domaine — fusionner les include, jamais en créer deux
• Limite technique à connaître : 10 lookups DNS maximum dans la chaîne SPF, au-delà l'enregistrement est invalide
• Vérifier après chaque modification, la propagation DNS peut prendre jusqu'à 24 à 48 heures

DKIM : signer chaque email envoyé

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email sortant, vérifiable via une clé publique publiée dans le DNS. Contrairement à SPF, DKIM ne dépend pas de l'IP d'envoi : la signature reste valide même si l'email transite par un serveur relais, ce qui la rend plus robuste.

Sur Google Workspace, l'activation se fait dans la console d'administration, sous Applications > Google Workspace > Gmail > Authentification par e-mail : Google génère la paire de clés, vous copiez l'enregistrement TXT (nom du type google._domainkey) dans votre DNS, puis vous revenez activer DKIM dans la console une fois la propagation confirmée.

Sur Microsoft 365, la logique est identique mais passe par le Centre d'administration Exchange (Flux de courrier > DKIM) : deux enregistrements CNAME sont fournis, à ajouter au DNS, puis DKIM se bascule sur « activé » depuis la même interface. Dans les deux cas, poser uniquement l'enregistrement DNS sans activer DKIM côté plateforme ne sert à rien — les deux étapes sont obligatoires.

DMARC : dire aux boîtes de réception quoi faire en cas d'échec

DMARC (Domain-based Message Authentication, Reporting and Conformance) s'appuie sur SPF et DKIM pour indiquer au serveur receveur la politique à appliquer quand un email échoue aux deux vérifications : ne rien faire (none), le mettre en quarantaine/spam (quarantine), ou le rejeter (reject). C'est aussi le seul des trois qui vous renvoie des rapports — utiles pour repérer une usurpation de votre domaine.

L'enregistrement se pose en TXT sur _dmarc.votre-entreprise.fr, par exemple v=DMARC1; p=none; rua=mailto:dmarc-reports@votre-entreprise.fr. Ce format est identique sur Google Workspace et Microsoft 365 puisque DMARC est un standard indépendant des deux plateformes.

La progression recommandée : commencer en p=none pendant deux à trois semaines pour lire les rapports et confirmer qu'aucun envoi légitime n'échoue, puis basculer en p=quarantine, et enfin en p=reject une fois confiant. Sauter directement à reject sans étape d'observation est la façon la plus sûre de bloquer par erreur ses propres emails de prospection.

Erreurs fréquentes qui cassent la configuration

La plus courante : deux enregistrements SPF sur le même domaine, souvent parce qu'un ancien prestataire d'emailing en avait posé un et que le nouveau outil en a ajouté un second sans vérifier. Résultat, les deux sont invalidés et SPF échoue systématiquement.

Deuxième piège : activer DKIM côté DNS mais oublier le bouton d'activation dans la console Google Workspace ou le Centre d'administration Exchange. L'enregistrement existe, mais les emails partent sans signature.

• Deux enregistrements SPF simultanés sur le même domaine
• DKIM posé en DNS mais jamais activé côté plateforme d'envoi
• DMARC en p=reject dès le premier jour, sans phase d'observation en p=none
• Oublier un sous-domaine d'envoi (ex: mail.votre-entreprise.fr) qui n'hérite pas automatiquement du SPF du domaine racine
• Adresse d'expédition sur un domaine grand public (gmail.com, outlook.com) où aucun de ces trois réglages n'est possible côté expéditeur

Ce qu'on vérifie chez LDM avant chaque campagne

Avant d'activer une campagne de prospection B2B sur un nouveau domaine ou une nouvelle adresse, on vérifie systématiquement les trois enregistrements dans cet ordre : SPF valide et unique, DKIM actif et signature confirmée sur un email test, DMARC présent au minimum en p=none avec une adresse de rapport surveillée. Un domaine qui ne coche pas ces trois cases n'est pas prêt pour un envoi ciblé, quelle que soit la qualité du message ou de la liste de contacts.

Ce socle technique protège aussi votre réputation de domaine sur la durée : un domaine mal authentifié qui envoie des emails de prospection, même en petit volume et bien ciblés, finit par être marqué comme suspect par les fournisseurs de messagerie, ce qui pénalise ensuite tous vos envois futurs, y compris les emails internes.

Questions fréquentes