SPF, DKIM, DMARC : configuration pas à pas pour la prospection par e-mail

Si vous envoyez des e-mails de prospection depuis votre propre domaine, trois enregistrements DNS déterminent si les serveurs de réception croient que le message vient vraiment de vous : SPF, DKIM et DMARC. Sans eux, même un premier e-mail bien rédigé peut être filtré avant que quiconque le lise.

Ce guide s’adresse aux fondateurs et aux équipes commerciales qui envoient leurs messages de prospection depuis une adresse comme you@yourcompany.com, généralement via Google Workspace. Nous (Outreach) passons en revue chaque enregistrement dans l’ordre où il faut le configurer, présentons les formats d’enregistrement exactement tels que les publient les pages d’aide de Google et les RFC, et signalons les erreurs qui font qu’un enregistrement semble correct alors qu’il échoue en silence.

Vous n’avez pas besoin d’être expert en DNS. Il vous faut un accès aux paramètres DNS de votre domaine (chez votre bureau d’enregistrement ou votre hébergeur DNS) et, pour DKIM, un accès administrateur à Google Workspace.

Que sont SPF, DKIM et DMARC, en une phrase chacun ?

SPF liste les serveurs autorisés à envoyer des e-mails pour votre domaine, DKIM ajoute une signature cryptographique qui prouve qu’un message n’a été ni falsifié ni modifié, et DMARC indique aux destinataires quoi faire lorsqu’un message échoue à ces vérifications. Les trois sont publiés sous forme d’enregistrements TXT dans le DNS de votre domaine.

Enregistrement	Où il se trouve	À quelle question il répond
SPF	`yourcompany.com` (hôte `@`)	« Ce serveur est-il autorisé à envoyer des e-mails pour ce domaine ?»
DKIM	`google._domainkey.yourcompany.com`	« Ce message a-t-il été signé par le domaine, et est-il resté intact ?»
DMARC	`_dmarc.yourcompany.com`	« En cas d’échec d’une vérification, que souhaite le propriétaire du domaine ?»

Ils fonctionnent ensemble. SPF et DKIM prouvent chacun quelque chose de précis ; DMARC relie ces preuves à l’adresse que les gens voient réellement dans l’en-tête From.

Ces enregistrements sont-ils réellement obligatoires pour la prospection par e-mail ?

Oui — au moins SPF ou DKIM est exigé de tout expéditeur vers Gmail et Yahoo, et les expéditeurs en masse ont besoin des trois. Il ne s’agit pas d’une simple bonne pratique ; cela figure dans les règles publiées par les deux fournisseurs à l’intention des expéditeurs.

Les consignes de Google pour les expéditeurs d’e-mails indiquent que tous les expéditeurs doivent « configurer l’authentification des e-mails SPF ou DKIM pour vos domaines d’envoi.» Les expéditeurs de « plus de 5 000 messages par jour à des comptes Gmail » doivent aussi « configurer l’authentification des e-mails SPF et DKIM » ainsi que « l’authentification des e-mails DMARC pour votre domaine d’envoi », et le domaine From doit être aligné sur le domaine SPF ou DKIM. Ces règles sont entrées en vigueur le 1er février 2024.

Les bonnes pratiques du Sender Hub de Yahoo concordent : chaque expéditeur doit « mettre en place SPF ou DKIM au minimum », et les expéditeurs en masse doivent « mettre en place à la fois SPF et DKIM » et « publier une politique DMARC valide avec au moins p=none.»

Un petit programme de prospection par e-mail n’atteindra peut-être jamais 5 000 messages par jour. Configurez quand même les trois : cela ne coûte rien, cela prend un après-midi, et vous n’aurez jamais à découvrir où se situe la limite.

Comment configurer SPF ?

Ajoutez un enregistrement TXT à la racine de votre domaine, qui commence par v=spf1, énumère chaque service qui envoie des e-mails pour vous et se termine par ~all. Pour un domaine qui n’envoie que via Google Workspace, la page de configuration SPF de Google donne exactement cet enregistrement :

v=spf1 include:_spf.google.com ~all

Étapes :

Connectez-vous aux paramètres DNS de votre hébergeur de domaine.
Créez un enregistrement TXT. Dans le champ hôte ou nom, Google indique de saisir @ si vous l’ajoutez au domaine racine plutôt qu’à un sous-domaine.
Collez l’enregistrement comme valeur, puis enregistrez.
Patientez. Google précise : « Un délai maximal de 48 heures peut ensuite être nécessaire pour que l’authentification SPF fonctionne.»

Si d’autres services envoient aussi des e-mails depuis votre domaine — outil de newsletter, CRM, service d’e-mails transactionnels — chacun a besoin de son propre include: dans le même enregistrement. La page de Google donne ces exemples combinés :

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

Utilisez la valeur include que chaque service d’envoi documente pour lui-même ; ne la devinez pas.

L’enregistrement SPF doit-il se terminer par ~all ou -all ?

Le guide de configuration de Google utilise ~all, et c’est la valeur par défaut la plus sûre tant que vous n’avez pas encore identifié tous les services qui envoient des e-mails pour vous. Les deux terminaisons n’ont pas le même sens dans la RFC 7208, la norme SPF :

~all (softfail) est « une déclaration faible de l’ADMD qui publie, selon laquelle l’hôte n’est probablement pas autorisé.»
-all (fail) est « une déclaration explicite selon laquelle le client n’est pas autorisé à utiliser le domaine dans l’identité donnée.»

Avec -all, un service d’envoi que vous avez oublié d’inclure subit un échec définitif. Une fois DMARC en place et ses rapports montrant que chaque source légitime est validée, la terminaison SPF compte moins, car c’est la politique de DMARC qui devient l’instruction suivie par les destinataires.

Pourquoi SPF cesse-t-il de fonctionner quand il y a trop d’include ?

Parce qu’une vérification SPF ne peut déclencher que 10 requêtes DNS au maximum ; au-delà, le résultat entier devient une erreur. La RFC 7208, section 4.6.4 précise que les implémentations « DOIVENT limiter à 10 le nombre total de ces termes pendant l’évaluation SPF » et que « si cette limite est dépassée, l’implémentation DOIT renvoyer “permerror”.»

Les termes comptabilisés sont include, a, mx, ptr, exists et le modificateur redirect. Point essentiel : le décompte porte sur toute l’évaluation — un include: qui en contient lui-même d’autres consomme donc plusieurs de vos 10. La page de Google le formule ainsi : « Un enregistrement SPF peut comporter jusqu’à 10 tags include » ; la RFC en donne une lecture plus stricte, car les requêtes imbriquées comptent aussi.

Si vous avez ajouté au fil des ans plusieurs outils de vente et de marketing, supprimez ceux que vous n’utilisez plus avant d’ajouter de nouveaux include.

Que se passe-t-il si un domaine possède deux enregistrements SPF ?

SPF échoue avec une erreur — deux enregistrements sont traités comme une configuration défectueuse, et non comme deux listes à combiner. La RFC 7208 indique que, lorsqu’un domaine possède plus d’un enregistrement v=spf1, la vérification « produit le résultat “permerror”.»

Cela arrive souvent ainsi : quelqu’un ajoute un second enregistrement TXT pour un nouvel outil au lieu de modifier l’existant. La solution consiste à les fusionner en un seul enregistrement comportant plusieurs termes include:, comme dans les exemples ci-dessus.

Comment activer DKIM dans Google Workspace ?

Générez une clé dans la console d’administration, publiez-la sous forme d’enregistrement TXT à l’adresse google._domainkey, puis cliquez sur « Lancer l’authentification.» La page de configuration DKIM de Google décrit la marche à suivre :

Dans la console d’administration Google, accédez à Applications > Google Workspace > Gmail > Authentifier les e-mails. (Vous devez disposer du droit d’administrateur associé aux paramètres Gmail.)
Choisissez le domaine et générez un nouvel enregistrement.
Choisissez la longueur de la clé. Google indique de choisir 2048 « si votre fournisseur de domaine accepte les clés de 2048 bits », car « les clés plus longues sont plus sûres que les clés plus courtes », et 1024 uniquement « si votre hébergeur de domaine n’accepte pas les clés de 2048 bits.»
Conservez le sélecteur de préfixe par défaut, google — Google le qualifie d’« option recommandée » pour Workspace.
Google vous affiche un nom d’hôte DNS, google._domainkey, et une valeur TXT qui commence par v=DKIM1. Copiez les deux dans un nouvel enregistrement TXT chez votre hébergeur DNS.
De retour dans la console d’administration, cliquez sur Lancer l’authentification.

La valeur TXT générée par Google a cette forme (la clé elle-même est une longue chaîne propre à votre domaine) :

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Délai : Google indique qu’« un délai maximal de 48 heures peut être nécessaire pour que l’authentification DKIM fonctionne » après l’ajout de la clé. Si vous venez de configurer Gmail pour un nouveau domaine, Google précise que vous « devez attendre entre 24 et 72 heures » avant que la clé DKIM soit même disponible dans la console d’administration.

Si un autre service envoie des e-mails pour vous, il vous fournira son propre enregistrement DKIM avec son propre sélecteur. Publiez-le aussi — plusieurs clés DKIM avec des sélecteurs différents peuvent coexister, contrairement à SPF.

Comment configurer DMARC sans bloquer vos propres e-mails ?

Publiez d’abord un enregistrement TXT à l’adresse _dmarc.yourcompany.com avec p=none, lisez les rapports, et ne durcissez la politique qu’ensuite. La page de configuration DMARC de Google indique : « Lorsque vous commencez à utiliser DMARC, nous vous recommandons de définir l’option de règle (p) sur none.» Elle conseille aussi de « patienter 48 heures après avoir configuré SPF et/ou DKIM avant de configurer DMARC.»

La page de Google donne cet exemple d’enregistrement complet :

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Cet exemple montre l’état final, le plus strict. Pour un premier enregistrement, le même format avec une politique de surveillance et une seule adresse de rapport suffit — par exemple v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. La balise rua envoie des rapports agrégés à cette boîte aux lettres ; Google recommande une boîte aux lettres ou un groupe dédié, car les rapports peuvent arriver en grand nombre.

Les trois valeurs de politique, telles que définies dans la spécification DMARC :

Politique	Ce que vous demandez aux destinataires de faire
`p=none`	Aucune action particulière — simple signalement
`p=quarantine`	Traiter les échecs comme suspects (par exemple, le dossier spam)
`p=reject`	Rejeter les e-mails qui échouent à la vérification DMARC

Un domaine n’a droit qu’à un enregistrement DMARC. Selon la RFC 9989, si plusieurs enregistrements DMARC sont renvoyés, « ils sont tous écartés » — ce qui signifie qu’aucune politique ne s’applique du tout.

Que signifie « alignement », et pourquoi DMARC échoue-t-il alors que SPF réussit ?

DMARC ne réussit que lorsque SPF ou DKIM réussit pour un domaine qui correspond à l’adresse From que les destinataires voient. SPF peut réussir pour le domaine propre de votre service d’envoi alors que l’en-tête From affiche le vôtre — et DMARC échoue alors quand même, car le domaine validé n’est pas aligné.

La spécification DMARC indique qu’un message est validé lorsqu’au moins une méthode d’authentification produit un résultat positif « fondé sur un identifiant qui est aligné » (RFC 7489, désormais reprise dans la RFC 9989). Par défaut, l’alignement est souple (adkim et aspf valent r par défaut) : mail.yourcompany.com et yourcompany.com comptent comme une correspondance parce qu’ils partagent le même domaine d’organisation. Le mode strict (s), comme dans l’exemple de Google, exige une correspondance exacte.

En pratique, c’est pourquoi DKIM compte autant pour la prospection par e-mail : lorsque votre service d’envoi signe avec votre domaine, l’alignement DKIM est validé même si l’alignement SPF ne l’est pas.

La norme DMARC a-t-elle changé en 2026 ?

Oui. La RFC 9989, publiée en mai 2026 comme document de type Standards Track, rend obsolète la RFC 7489 d’origine — et supprime la balise pct. Les enregistrements v=DMARC1 existants continuent de fonctionner.

Le principal changement que la plupart des expéditeurs remarqueront : pct (appliquer la politique à une partie seulement des e-mails en échec) a disparu. La RFC explique que « l’expérience opérationnelle a montré que la balise “pct” était généralement appliquée de manière inexacte, sauf si la valeur indiquée était 0 ou 100.» À sa place figure un indicateur de test, t=y, qui demande aux destinataires de ne pas appliquer la politique que vous avez indiquée pendant que vous la testez.

La page d’aide de Google montre encore pct=100 dans son exemple. Cela ne casse rien : la RFC 9989 précise que « les balises inconnues DOIVENT être ignorées », si bien qu’un pct résiduel est simplement ignoré. La prochaine fois que vous modifierez votre enregistrement, vous pourrez le supprimer.

Comment vérifier que tout fonctionne ?

Consultez les enregistrements que vous avez publiés, puis envoyez un vrai message à une adresse Gmail et lisez ses résultats d’authentification. Deux vérifications rapides :

Consultez les enregistrements DNS. Notre vérificateur gratuit recherche les enregistrements SPF, DKIM et DMARC du domaine de l’adresse que vous saisissez — sans inscription. Il vérifie le sélecteur DKIM par défaut de Google (google._domainkey) ; si votre service d’envoi utilise un autre sélecteur, le vérificateur indiquera DKIM comme non confirmé même s’il est bien configuré. L’outil est disponible en anglais et en coréen ; saisissez votre adresse e-mail d’envoi.
Vérifiez un vrai message. Envoyez un e-mail à un compte Gmail que vous contrôlez, ouvrez-le, choisissez « Afficher l’original » et cherchez SPF: PASS, DKIM: PASS et DMARC: PASS.

Laissez ensuite une semaine ou deux aux rapports DMARC. Lorsque chaque source légitime que vous utilisez apparaît comme validée, passez de p=none à p=quarantine, puis plus tard à p=reject si vous voulez la protection la plus forte contre l’usurpation d’identité.

Quelles erreurs font le plus souvent échouer l’authentification ?

Deux enregistrements SPF, trop de requêtes SPF, DKIM généré mais jamais lancé, et DMARC publié avant que SPF et DKIM aient eu le temps de fonctionner. Une liste de contrôle :

Un seul enregistrement SPF, avec chaque expéditeur sous forme d’un include: à l’intérieur, et pas plus de 10 termes de requête.
Cliquez sur « Lancer l’authentification » après avoir publié la clé DKIM — l’enregistrement DNS seul ne suffit pas.
Attendez environ 48 heures après SPF et DKIM avant d’ajouter DMARC, et publiez-le à _dmarc, pas à la racine.
Envoyez depuis un domaine que vous contrôlez. Vous ne pouvez pas publier DMARC pour une adresse @gmail.com.

L’authentification fait examiner vos e-mails ; elle ne donne pas aux destinataires l’envie de les recevoir. Les plaintes pour spam comptent toujours — Google et Yahoo demandent tous deux de garder votre taux de spam sous 0,3 %, comme nous l’expliquons dans pourquoi les e-mails de prospection finissent en spam. Et l’envoi à des adresses qui n’existent pas génère des rebonds, c’est pourquoi nous vous recommandons de vérifier les adresses avant d’envoyer.

En bref

Google et Yahoo exigent SPF ou DKIM de tout expéditeur, et les trois ainsi que l’alignement des expéditeurs en masse (plus de 5 000 messages par jour vers Gmail).
SPF : un enregistrement TXT à @, par exemple v=spf1 include:_spf.google.com ~all ; restez dans la limite de 10 termes de requête DNS.
DKIM : clé de 2048 bits, sélecteur google, TXT à google._domainkey, puis Lancer l’authentification.
DMARC : un enregistrement TXT à _dmarc, commencez à p=none avec une adresse de rapport, durcissez plus tard. La RFC 9989 (mai 2026) a remplacé pct par t=y.
Vérifiez vos enregistrements avec notre vérificateur gratuit d’authentification des e-mails, puis confirmez sur un vrai message.