SPF, DKIM, DMARC : le guide complet pour configurer votre email (2026)

SPF, DKIM et DMARC : si vous envoyez des emails et particulièrement des emails de prospection vous avez forcément croisé ces trois acronymes. Et probablement déjà soufflé un peu de désespoir devant la doc technique. En 2026, ces trois protocoles d’authentification email ne sont plus optionnels : depuis février 2024, Google et Yahoo rejettent les emails non authentifiés des expéditeurs en masse, et Microsoft a suivi en mai 2025. Pour les équipes qui font du cold email B2B, c’est devenu la condition minimale pour atteindre la boîte de réception. Dans ce guide complet, on vous explique exactement ce que sont SPF, DKIM et DMARC, comment ils fonctionnent ensemble, et surtout comment les configurer correctement sur votre domaine. Avec des exemples concrets d’enregistrements DNS, les erreurs courantes à éviter et une FAQ pour répondre à toutes vos questions.

SPF, DKIM et DMARC sont trois protocoles d’authentification email complémentaires. Chacun joue un rôle différent et précis dans la vérification qu’un email envoyé depuis votre domaine est bien légitime.

• SPF (Sender Policy Framework) : déclare quels serveurs sont autorisés à envoyer des emails depuis votre domaine.

• DKIM (DomainKeys Identified Mail) : ajoute une signature cryptographique à chaque email pour prouver qu’il n’a pas été altéré.

• DMARC (Domain-based Message Authentication, Reporting and Conformance) : indique aux serveurs destinataires quoi faire si SPF ou DKIM échouent, et envoie des rapports de monitoring.

Configurer les trois correctement, c’est la condition minimale pour atteindre la boîte de réception en 2026. Manquer un seul des trois, et vos emails risquent d’atterrir en spam ou pire, d’être rejetés purement et simplement par Gmail, Outlook ou Yahoo.

SPF est le plus ancien des trois protocoles (apparu officiellement en 2006 avec la RFC 4408, mis à jour en 2014 avec la RFC 7208). Son principe est simple : vous publiez dans votre DNS la liste des serveurs autorisés à envoyer des emails au nom de votre domaine. Quand un serveur reçoit un email prétendant venir de votre domaine, il vérifie que l’adresse IP de l’expéditeur figure bien dans cette liste.

SPF s’implémente via un enregistrement TXT dans votre zone DNS, à la racine de votre domaine. Voici un exemple type :

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Cet enregistrement dit : « Les emails depuis ce domaine peuvent être envoyés par les serveurs de Google Workspace ou Microsoft 365. Tout autre serveur doit être considéré comme suspect (~all = soft fail). »

Si votre entreprise utilise plusieurs services d’envoi (Google Workspace pour les emails internes, un outil de cold email comme Emelia, et un outil transactionnel comme SendGrid), votre SPF doit tous les inclure :

v=spf1 include:_spf.google.com include:_spf.emelia.io include:sendgrid.net ~all

SPF impose une contrainte technique souvent oubliée : un enregistrement SPF ne peut pas générer plus de 10 lookups DNS. Chaque mécanisme include: déclenche un lookup supplémentaire, et certains services (comme Microsoft 365) en consomment plusieurs à eux seuls. Au-delà de 10, l’ensemble du SPF retourne une erreur PermError et la vérification échoue. Si vous avez beaucoup de services à autoriser, vous devez « aplatir » votre SPF (SPF flattening) avec un outil dédié.

Le mécanisme final de votre SPF détermine comment les serveurs traitent un email qui échoue à la vérification.

• ~all (soft fail) : l’email échoue à SPF mais peut quand même être livré, généralement marqué comme suspect. Recommandé pendant la phase d’installation et la plupart du temps en 2026.

• -all (hard fail) : l’email est rejeté par les serveurs strict. À utiliser uniquement après avoir validé que tous vos services d’envoi légitimes sont bien dans le SPF.

En 2026, la pratique recommandée est de commencer en ~all puis, après validation via les rapports DMARC que tout est propre, basculer en -all si vous voulez du strict.

DKIM (RFC 6376) ajoute une signature cryptographique à chaque email sortant. Cette signature, calculée avec une clé privée, est vérifiée par le serveur destinataire grâce à une clé publique publiée dans votre DNS. DKIM prouve deux choses : que le message vient bien de votre domaine, et qu’il n’a pas été modifié en transit.

Quand votre serveur d’envoi envoie un email, il calcule une empreinte cryptographique du contenu (en-tête + corps) et la chiffre avec une clé privée. Cette signature est ajoutée dans l’en-tête DKIM-Signature de l’email. Le serveur destinataire récupère la clé publique correspondante dans votre DNS, déchiffre la signature et vérifie qu’elle correspond bien à l’email reçu. Si une seule virgule a été modifiée en route, la vérification échoue.

Un enregistrement DKIM est un TXT publié à un sélecteur précis dans votre DNS. Le sélecteur (selector) permet d’avoir plusieurs clés DKIM en parallèle, ce qui est utile pour la rotation. Format type :

selector1._domainkey.votredomaine.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Concrètement, votre fournisseur d’email (Google Workspace, Microsoft 365, ou un outil comme Emelia) génère la paire de clés et vous donne le contenu exact à coller dans votre zone DNS.

Voici pourquoi DKIM est si important : contrairement à SPF, DKIM survit au transfert d’email. Quand un destinataire transfère votre message à quelqu’un d’autre, l’adresse IP de l’expéditeur change (ce n’est plus votre serveur, c’est le serveur de la personne qui transfère). Du coup, SPF échoue mécaniquement. Mais la signature DKIM, elle, reste intacte tant que le contenu n’est pas modifié. C’est pour ça qu’en 2026, DKIM est devenu la pierre angulaire de l’authentification email.

Les clés DKIM existent historiquement en 1024 bits ou 2048 bits. En 2026, la recommandation claire de l’industrie est d’utiliser du 2048 bits. Les clés 1024 sont encore acceptées mais de plus en plus pénalisées par les filtres anti-spam. Idéalement, faites tourner vos clés DKIM tous les 6 à 12 mois pour limiter la fenêtre de risque en cas de fuite de la clé privée.

DMARC (RFC 7489) ne remplace ni SPF ni DKIM. Il vient s’ajouter par-dessus pour répondre à deux questions : « Que doit faire le serveur destinataire si SPF ou DKIM échouent ? » et « Comment je sais qui essaie d’envoyer des emails au nom de mon domaine ? ».

DMARC s’appuie sur un concept appelé alignement. Pour qu’un email passe DMARC, il faut que SPF ou DKIM réussisse ET que le domaine vérifié par l’un des deux corresponde au domaine visible dans le champ « From » de l’email (celui que voit le destinataire). Sans cet alignement, un attaquant pourrait passer SPF avec son propre domaine tout en se faisant passer pour vous dans le From ce qui est exactement la technique d’usurpation que DMARC empêche.

DMARC se publie comme un TXT à _dmarc.votredomaine.com :

_dmarc.votredomaine.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@votredomaine.com; pct=100; aspf=r; adkim=r"

La balise p= définit ce que les serveurs doivent faire en cas d’échec :

• p=none : monitoring uniquement, l’email est livré normalement. C’est le mode de démarrage recommandé pour collecter des rapports sans rien casser.

• p=quarantine : les emails non authentifiés vont en spam. Étape intermédiaire après quelques semaines de monitoring propre.

• p=reject : les emails non authentifiés sont rejetés purement et simplement. C’est le mode cible final, qui offre la meilleure protection contre l’usurpation.

La progression normale en 2026 : démarrer en p=none pendant 4-6 semaines, analyser les rapports DMARC, corriger toutes les sources d’email légitimes qui échouent, puis passer à p=quarantine pendant 2-4 semaines, puis enfin p=reject.

Les balises aspf= et adkim= contrôlent le niveau d’alignement requis entre les domaines.

• Mode relaxed (r) : les sous-domaines sont acceptés. Si votre From est « contact@votredomaine.com » et que SPF passe avec « mail.votredomaine.com », l’alignement est OK. C’est le mode recommandé pour la plupart des organisations.

• Mode strict (s) : il faut une correspondance exacte. « contact@votredomaine.com » et « mail.votredomaine.com » ne sont plus alignés. À utiliser uniquement si vous avez un contrôle total sur tous vos sous-domaines d’envoi.

C’est sans doute le bénéfice le plus sous-estimé de DMARC. Avec rua=mailto:dmarc@votredomaine.com, vous recevez quotidiennement des rapports XML agrégés détaillant qui essaie d’envoyer des emails au nom de votre domaine, depuis quelles IP, et avec quel taux de réussite SPF/DKIM. Ces rapports révèlent les services oubliés (qui envoient pour vous sans authentification), les tentatives d’usurpation, et les erreurs de configuration. Plusieurs outils gratuits ou payants comme dmarcian, Postmark DMARC ou URIports parsent ces XML en tableaux de bord lisibles.

Chaque protocole couvre un trou que les autres ne comblent pas :

• SPF seul ne suffit pas : il vérifie l’IP du serveur d’envoi (Return-Path), pas le From visible. Un attaquant peut passer SPF avec son propre domaine tout en spoofant le vôtre dans le From.

• DKIM seul ne suffit pas : il prouve que le message n’a pas été altéré, mais il n’indique pas au serveur destinataire quoi faire en cas d’échec. Et tous les expéditeurs ne signent pas avec DKIM.

• DMARC seul est sans effet : il s’appuie sur SPF ou DKIM pour fonctionner. Sans eux, DMARC n’a rien à évaluer.

Ensemble, les trois forment un système complet : SPF vérifie l’IP, DKIM vérifie l’intégrité du contenu, DMARC applique la politique et offre la visibilité. C’est exactement pour ça que Google, Yahoo, Outlook et Apple exigent désormais les trois pour les expéditeurs en masse.

L’ordre logique d’implémentation est : SPF d’abord (le plus rapide), DKIM ensuite (nécessite la génération d’une paire de clés), DMARC en dernier (dépend des deux autres). Voici la marche à suivre.

Listez tous les services qui envoient des emails au nom de votre domaine : votre fournisseur de messagerie (Google Workspace, Microsoft 365), vos outils de cold email, vos services transactionnels, vos newsletters. Demandez à chacun la valeur d’include: à utiliser. Combinez-les dans un seul enregistrement TXT à la racine de votre domaine. Démarrez en ~all (soft fail). Vérifiez ensuite via un outil comme MXToolbox que l’enregistrement est bien syntaxiquement correct et reste sous la limite des 10 lookups.

Pour chaque service d’envoi, suivez la procédure de génération de clé DKIM dans son interface (Google Workspace : Apps → Gmail → Authentifier l’email → Générer un nouveau record en 2048 bits). Copiez le TXT fourni et publiez-le dans votre DNS au sélecteur indiqué. Attendez la propagation DNS (5 à 60 minutes), puis activez l’authentification dans l’interface du fournisseur. Répétez pour chaque outil d’envoi.

Démarrez avec une politique permissive pour collecter des rapports sans risquer de bloquer du trafic légitime :

v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com; pct=100; aspf=r; adkim=r

Pendant 4 à 6 semaines, lisez les rapports quotidiens et identifiez toutes les sources d’email légitimes qui échouent. Corrigez-les (ajoutez l’include SPF manquant, activez DKIM sur le service oublié, etc.). Une fois que vos rapports sont propres, passez à p=quarantine pour 2-4 semaines, puis p=reject.

Plusieurs outils gratuits permettent de tester votre configuration :

• MXToolbox : vérification SPF, DKIM, DMARC et diagnostic complet du domaine.

• Google Admin Toolbox : diagnostic spécifique pour les domaines Google Workspace.

• dmarcian : analyse des rapports DMARC en tableau de bord lisible.

• Commande dig en local : « dig TXT votredomaine.com » pour SPF, « dig TXT _dmarc.votredomaine.com » pour DMARC.

Même avec les meilleures intentions, certaines erreurs reviennent constamment dans les configurations SPF, DKIM et DMARC.

• Dépasser la limite des 10 lookups DNS sur SPF : votre enregistrement renvoie une erreur PermError et tout échoue. Aplatissez votre SPF si nécessaire.

• Publier plusieurs enregistrements SPF distincts : vous ne pouvez avoir qu’un seul TXT SPF par domaine. Plusieurs enregistrements = échec automatique.

• Oublier d’aligner le domaine d’envoi : si DMARC est en mode strict et que votre From est sur le domaine racine alors que SPF passe avec un sous-domaine, l’alignement échoue.

• Ne pas surveiller les rapports DMARC : publier un DMARC en p=none sans jamais lire les rapports, c’est inutile. C’est précisément le moment où on identifie les problèmes.

• Utiliser une clé DKIM trop courte (1024 bits) : de plus en plus pénalisée par les filtres modernes. Privilégiez 2048 bits.

• Passer à p=reject trop vite : sans monitoring préalable, vous bloquez vos propres emails légitimes. Comptez minimum 6 semaines avant l’enforcement.

Si vous faites du cold email B2B en 2026, configurer correctement SPF, DKIM et DMARC n’est pas une option c’est la condition de survie de vos campagnes. Les seuils de tolérance des filtres anti-spam ont radicalement durci depuis 2024 : Gmail, Outlook et Yahoo rejettent désormais les emails non authentifiés au lieu de simplement les classer en spam comme avant. Concrètement, un cold email envoyé depuis un domaine sans SPF/DKIM/DMARC propres a une chance proche de zéro d’atteindre la boîte de réception.

L’autre point critique : votre réputation de domaine se construit sur l’ensemble des emails envoyés. Si une partie de vos envois est mal authentifiée, c’est tout votre domaine qui en pâtit. C’est pourquoi les pros du cold email utilisent souvent des domaines dédiés à la prospection (par exemple « entreprise-contact.com » plutôt que le domaine principal « entreprise.com »), avec leur propre SPF/DKIM/DMARC, pour isoler leur réputation.

Chez Emelia, l’authentification SPF/DKIM/DMARC est gérée automatiquement quand vous connectez vos boîtes mail à la plateforme. La configuration DNS reste de votre côté (vous gardez le contrôle de votre domaine), mais l’outil vous guide pas à pas et vérifie la validité de votre setup avant chaque envoi de campagne.

SPF, DKIM et DMARC ne sont plus une option en 2026 : ils sont la fondation technique sur laquelle repose la délivrabilité de vos emails. Que vous fassiez du cold email, des newsletters, des emails transactionnels ou simplement de la communication interne, ces trois protocoles déterminent si vos messages atteignent la boîte de réception ou disparaissent dans les spams.

La bonne nouvelle : la mise en place est un investissement ponctuel qui rapporte sur la durée. Une fois configurés correctement et passés en p=reject, vous protégez votre domaine contre l’usurpation, vous boostez significativement votre délivrabilité, et vous gagnez la visibilité offerte par les rapports DMARC. Si vous démarrez aujourd’hui une stratégie de prospection email B2B, commencez par là avant même de réfléchir au copywriting ou à la séquence.