Mails qui arrivent en spam : configurer SPF, DKIM et DMARC pas à pas

Quand vos mails arrivent en spam, ou qu’un client affirme n’avoir jamais reçu le devis que vous avez bien envoyé, vérifiez d’abord que votre domaine prouve qu’il en est l’expéditeur. Trois enregistrements DNS s’en chargent. Ce tutoriel montre comment configurer SPF, DKIM et DMARC pas à pas : voir ce que Gmail voit, ajouter les enregistrements là où se trouve la zone DNS de votre domaine (exemples chez OVH, Spaceship et Namecheap), puis durcir DMARC pour que les messageries refusent les emails qui se font passer pour vous.

La configuration des emails fait partie des prestations au forfait que je réalise, et j’ai travaillé avec des domaines enregistrés chez OVH, Namecheap, Spaceship, Infomaniak, Hostinger et l’ancien Google Domains. Les enregistrements sont courts. Ce qui demande du soin, c’est de retrouver chaque service qui envoie en votre nom et, chez OVH, de ne pas oublier un point à la fin d’une ligne.

Pour la théorie, MLK Leadhunters a publié SPF, DKIM et DMARC expliqués simplement. Cette page, c’est la pratique.

Pourquoi vos mails arrivent en spam, et ce que SPF, DKIM et DMARC y changent

Avant de peser vos mots, le serveur qui reçoit votre email vérifie qu’il vient bien du domaine affiché comme expéditeur. Chaque enregistrement répond à une partie de la question :

Ils prouvent votre identité. Ils ne sauvent pas un email qui ressemble à du spam, ni un envoi à des gens qui n’ont rien demandé.

Les grandes messageries les exigent désormais. Depuis février 2024, les consignes de Google pour les expéditeurs imposent à tous ceux qui écrivent à des adresses Gmail de passer SPF ou DKIM et de garder sous 0,1 % la part de leurs emails signalés comme spam par les utilisateurs de Gmail, sans jamais atteindre 0,3 %. Ceux qui envoient environ 5 000 messages par jour ou plus doivent en plus avoir les trois enregistrements, alignés sur le domaine de l’expéditeur ; Yahoo a adopté des règles proches au même moment. Google indique que Gmail applique ces règles plus strictement depuis novembre 2025, avec des rejets temporaires et définitifs. Outlook.com exige les trois enregistrements des domaines qui lui envoient 5 000 messages ou plus par jour depuis le 5 mai 2025. Si vous envoyez une newsletter, mon guide sur la délivrabilité d’une newsletter détaille le reste de ces règles, dont la désinscription en un clic.

Étape 1 : voir ce que Gmail voit avec « Afficher l’original »

1. Depuis votre adresse professionnelle, envoyez un court email à une adresse Gmail personnelle.
2. Ouvrez-le dans Gmail sur un ordinateur, cliquez sur les trois points à côté de la flèche Répondre, puis sur Afficher l’original.
3. Lisez les lignes en haut de la page. Voici l’objectif :

SPF     PASS   (IP 203.0.113.25)
DKIM    PASS   (domaine votreentreprise.fr)
DMARC   PASS

Les libellés autour varient selon la langue de Gmail ; ce qui compte, c’est PASS sur chaque ligne et votre propre domaine sur la ligne DKIM. Tout autre résultat renvoie à l’étape qui le corrige :

Étape 2 : lister tous les services qui envoient en votre nom

SPF et DKIM doivent couvrir tout ce qui met votre adresse en expéditeur, pas seulement votre boîte mail :

• Votre messagerie : celle d’OVHcloud, Google Workspace, Microsoft 365, Spacemail, Private Email chez Namecheap ou une autre. Si vous n’avez pas encore d’adresse sur votre propre domaine, mon guide pour créer une adresse mail professionnelle compare les options.
• Les outils qui écrivent à vos clients en votre nom : facturation, comptabilité, prise de rendez-vous, boutique en ligne.
• Les outils marketing : l’outil de vos mailings et votre CRM.
• Votre site, si ses formulaires envoient depuis votre adresse.

Pour chaque outil, cherchez la page de réglages souvent appelée authentification du domaine ou de l’expéditeur : la plupart fournissent des enregistrements DKIM à ajouter, souvent des CNAME. Beaucoup envoient avec leur propre adresse de retour, si bien que leur include SPF n’aiderait pas DMARC : c’est leur DKIM sur votre domaine qui compte. Envoyez aussi un email de test depuis chaque outil vers Gmail et vérifiez-le avec « Afficher l’original ».

Étape 3 : ouvrir votre zone DNS chez OVH, Spaceship ou Namecheap

Les enregistrements se placent là où la zone DNS de votre domaine est hébergée : en général chez le registrar, sauf si les serveurs DNS pointent ailleurs, vers Cloudflare ou le compte d’une ancienne agence par exemple. Mon article sur les enregistrements DNS montre comment vérifier, et mon guide sur le nom de domaine et l’hébergement démêle domaine, hébergement et messagerie.

Saisissez les noms sans votre domaine : _dmarc, pas _dmarc.votreentreprise.fr, sinon certaines interfaces créent _dmarc.votreentreprise.fr.votreentreprise.fr. Par habitude, j’utilise Spaceship, et mon tutoriel pour acheter un nom de domaine sur Spaceship détaille sa page Advanced DNS.

Étape 4 : configurer le SPF, un seul enregistrement par domaine

Le SPF est un TXT sur la racine qui liste les serveurs autorisés à envoyer les emails de votre domaine. Chaque messagerie vous donne son include :

Tous les expéditeurs tiennent dans un seul enregistrement :

; faux : deux SPF, donc le SPF échoue
@   TXT   "v=spf1 include:mx.ovh.com ~all"
@   TXT   "v=spf1 include:<votre autre outil> ~all"

; juste : un seul SPF qui cite les deux
@   TXT   "v=spf1 include:mx.ovh.com include:<votre autre outil> ~all"

Trois règles pour qu’il fonctionne :

1. Un seul SPF par domaine. Selon la RFC 7208, deux enregistrements font échouer le SPF : ajoutez chaque nouvel include à l’enregistrement existant.
2. Dix requêtes DNS au maximum. Chaque include, a et mx compte, y compris les include imbriqués dans celui d’un prestataire. Au-delà de dix, le SPF renvoie une erreur qui vaut un échec : retirez les services que vous avez quittés.
3. La fin de la ligne. ~all demande de traiter comme suspects les emails venus de serveurs non listés, -all de les refuser. L’exemple de Google utilise ~all, OVHcloud recommande -all. Gardez ~all tant que vous découvrez des expéditeurs, et laissez DMARC faire respecter la règle.

Chez OVH, Ajouter une entrée propose un type SPF guidé, avec une option qui inclut les serveurs email d’OVH ; un TXT sur le sous-domaine vide fait la même chose. Chez Namecheap : Domain List, Manage en face du domaine, onglet Advanced DNS, puis Add New Record sous Host Records, type TXT Record, @ comme host, la valeur, et enregistrez.

Étape 5 : configurer DKIM avec votre messagerie

DKIM signe chaque email avec une clé privée qui reste chez votre messagerie ; les serveurs destinataires vérifient la signature grâce à une clé publique publiée sur sélecteur._domainkey. Vous générez la clé chez la messagerie, la publiez dans votre zone DNS, puis activez la signature.

• Messagerie OVHcloud. Le DKIM des offres email d’OVHcloud passe par des enregistrements CNAME, comme chez Microsoft 365.
• Google Workspace. Dans la console d’administration, ouvrez Applications > Google Workspace > Gmail > Authentifier les e-mails, choisissez le domaine et cliquez sur Générer un nouvel enregistrement. Publiez le TXT sur google._domainkey, puis revenez dans la console pour lancer l’authentification. Google recommande une clé de 2048 bits, et son aide sur DKIM traite des hébergeurs DNS qui n’acceptent que 1024 bits. Tant que vous êtes dans la console, mon guide pour sécuriser Google Workspace et Microsoft 365 liste les autres réglages à changer.
• Microsoft 365. Les réglages DKIM du portail Microsoft Defender donnent deux CNAME, selector1._domainkey et selector2._domainkey. Ajoutez-les, puis activez la signature au même endroit. J’utilisais Microsoft pour mes propres emails et c’était pénible : prévoyez un peu de patience.
• Spacemail. Sur les serveurs DNS de Spaceship, vérifiez dans Advanced DNS que spacemail._domainkey est bien là. Avec un autre hébergeur DNS, copiez l’enregistrement depuis Advanced DNS (Inactive records > Spacemail DNS records), comme le montre mon tutoriel pour configurer Spacemail.

Une clé de 2048 bits dépasse 255 caractères, la limite d’une chaîne dans un TXT : elle est donc stockée en plusieurs chaînes dans un même enregistrement. Certaines interfaces la découpent pour vous ; si la vôtre refuse la valeur, cherchez dans son aide la saisie des TXT longs.

Chez OVH, les CNAME de DKIM demandent un caractère de plus :

selector1._domainkey   CNAME   <cible donnée par Microsoft>.
selector2._domainkey   CNAME   <cible donnée par Microsoft>.

Étape 6 : configurer DMARC, en commençant par p=none

DMARC est validé quand SPF ou DKIM passe pour le même domaine que celui de votre adresse d’expéditeur : c’est l’alignement. L’enregistrement indique aussi que faire quand aucun des deux ne passe, et où envoyer les rapports. C’est un seul TXT nommé _dmarc, et la première version observe sans rien bloquer :

_dmarc   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@votreentreprise.fr"

• p=none ne demande que des rapports, et suffit déjà aux règles de Gmail, Yahoo et Outlook.com pour les gros expéditeurs.
• rua= est l’adresse des rapports quotidiens. Donnez-leur une boîte ou un alias à part : ils arrivent en pièces jointes XML compressées. Une adresse sur un autre domaine, celle d’un service de rapports par exemple, doit être autorisée par ce domaine, ce que ces services font pour vous.

Gardez un seul enregistrement _dmarc par domaine. Votre messagerie ne le crée pas forcément : Spacemail, par exemple, ne le fait pas. Chez OVH, le type DMARC du formulaire fonctionne, mais un TXT sur le sous-domaine _dmarc accepte toutes les balises.

Étape 7 : tester les trois enregistrements

Les enregistrements peuvent mettre quelques heures à apparaître partout. Interrogez ensuite le DNS depuis un terminal sur Mac ou Linux, en remplaçant google par le sélecteur de votre messagerie :

dig +short TXT votreentreprise.fr
dig +short TXT google._domainkey.votreentreprise.fr
dig +short TXT _dmarc.votreentreprise.fr

Sous Windows, nslookup -type=TXT _dmarc.votreentreprise.fr fait la même chose, et la Google Admin Toolbox propose une page Dig dans n’importe quel navigateur. Pour un DKIM en CNAME, demandez CNAME au lieu de TXT.

Envoyez enfin un nouvel email vers Gmail et rouvrez Afficher l’original : PASS sur les trois lignes, avec votre propre domaine sur la ligne DKIM. Recommencez avec chaque outil de l’étape 2.

Étape 8 : lire les rapports, puis passer en quarantine et en reject

En p=none, rien n’est bloqué ; les rapports vous disent quand vous pouvez changer cela. Chacun liste les serveurs qui ont envoyé des emails au nom de votre domaine, combien chacun en a envoyé, et si SPF et DKIM sont passés :

<row>
  <source_ip>203.0.113.25</source_ip>
  <count>42</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</row>

Un service de rapports DMARC transforme ces fichiers en tableaux lisibles. Trois choses à repérer :

• Un de vos services en échec : configurez son DKIM (étape 5) ou ajoutez-le au SPF (étape 4).
• Des emails transférés qui échouent au SPF : c’est attendu, le serveur qui transfère n’est pas dans votre liste. DKIM survit en général au transfert, donc DMARC passe quand même : une raison de plus d’avoir DKIM partout.
• Des serveurs que vous ne reconnaissez pas : quelqu’un envoie en votre nom, ce que les deux réglages suivants arrêtent.

Quand quelques semaines de rapports montrent vos propres services en PASS, durcissez la politique en deux temps, à quelques semaines d’écart :

1. p=quarantine : les messageries placent les emails en échec dans les spams.
2. p=reject : celles qui appliquent DMARC les refusent.

_dmarc   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@votreentreprise.fr"

Gardez l’adresse rua= après le passage en reject : les rapports sont votre moyen de repérer un nouvel outil que personne n’a authentifié. La fraude au paiement demande plus que des enregistrements DNS : mon guide sur la fraude au faux RIB donne les règles qui la bloquent.

Domaines qui n’envoient rien, et domaines de cold emailing

Un ancien nom de marque, un .com qui redirige vers votre .fr, un domaine acheté pour protéger votre nom : quand rien n’en part, personne ne le surveille, ce qui arrange quiconque veut se faire passer pour vous. Fermez-le avec deux enregistrements, uniquement là où rien n’est envoyé :

@        TXT   "v=spf1 -all"
_dmarc   TXT   "v=DMARC1; p=reject"

Le cold emailing est le cas inverse : des domaines secondaires qui ne servent qu’à envoyer, jamais votre domaine principal, pour les raisons que MLK Leadhunters donne dans n’envoyez jamais de cold emails depuis votre domaine principal. Chaque domaine secondaire a besoin de MX, SPF, DKIM et DMARC, et p=none suffit aux règles des messageries. Les enregistrements ne sont que le ticket d’entrée : mes campagnes partent en texte brut, sans liens ni HTML, pour une bonne délivrabilité, et s’arrêtent à trois emails. Mon guide sur l’infrastructure de cold emailing dimensionne les domaines et les boîtes.

Spacemail est la messagerie que j’encourage pour sa configuration simple, mais les règles de Spaceship interdisent les envois en masse non sollicités et la chauffe automatisée par des outils tiers : lisez sa politique et obtenez son accord écrit avant d’utiliser Spacemail pour du cold emailing. Si vous préférez confier vos campagnes, c’est le métier de MLK Leadhunters.

Configurer SPF, DKIM et DMARC : la checklist, et quand déléguer

1. « Afficher l’original » sur un email de test vers Gmail, avant et après.
2. La liste de tous les services qui envoient au nom de votre domaine.
3. Une copie de la zone DNS avant toute modification.
4. Un seul SPF, avec tous les expéditeurs, dix requêtes au maximum.
5. DKIM activé chez votre messagerie et dans chaque outil, avec un point final sur les cibles CNAME chez OVH.
6. Un seul DMARC, d’abord en p=none, avec une adresse de rapports que quelqu’un lit.
7. Quelques semaines de rapports propres, puis quarantine, puis reject.
8. v=spf1 -all et p=reject sur les domaines qui n’envoient rien.

Vous n’avez pas besoin de moi quand une seule messagerie envoie tous vos emails : trois enregistrements et un peu de patience suffisent. Déléguez quand plusieurs outils envoient au nom de votre domaine sans que personne ne sache lesquels, quand le SPF frôle les dix requêtes, quand les rapports montrent des serveurs inconnus, ou quand vos emails n’arrivent plus depuis une modification DNS : c’est le cas urgent.