Email pro qui finit en spam ou n'arrive pas

Ton email pro part, mais n’arrive jamais

Tu envoies un devis depuis contact@tondomaine.fr. Le client ne reçoit rien. Tu renvoies : ça tombe dans ses indésirables. Pire, tu ne le sais même pas, parce qu’aucun message d’erreur ne te revient. Tu perds des clients sans comprendre pourquoi.

Le code de ton site n’est presque jamais en cause. Le problème est dans le DNS de ton domaine : il manque les enregistrements qui prouvent aux serveurs de réception que c’est bien toi qui envoies. Sans cette preuve, Gmail, Outlook et les autres te traitent comme un spammeur potentiel, et te filtrent.

Ces preuves portent trois noms : SPF, DKIM et DMARC. Les trois sont des enregistrements DNS. Aucun ne touche à ton site. Voici comment les poser correctement.

Pourquoi l’authentification email est devenue obligatoire

Depuis 2024, Gmail et Yahoo exigent SPF + DKIM + DMARC pour tout expéditeur qui dépasse 5 000 messages par jour vers leurs boîtes (source : Google Workspace Admin Help, 2024). Mais même pour un petit volume, l’absence d’authentification te fait perdre des points de réputation à chaque envoi.

La logique est simple. N’importe qui peut écrire contact@tondomaine.fr dans le champ expéditeur d’un email, c’est aussi facile que d’écrire une fausse adresse au dos d’une enveloppe. Les trois protocoles répondent chacun à une question du serveur de réception :

Les trois travaillent ensemble. SPF et DKIM seuls, sans DMARC, laissent une faille. DMARC sans les deux autres n’a rien à vérifier. Il faut les trois.

SPF : déclarer qui a le droit d’envoyer

SPF (Sender Policy Framework) désigne le protocole qui déclare, dans le DNS d’un domaine, la liste des serveurs autorisés à envoyer du courrier en son nom. Il est normalisé par la RFC 7208 depuis 2014. Concrètement, c’est un simple enregistrement TXT posé à la racine de ton domaine.

Type : TXT
Nom  : @  (la racine de ton domaine)
Valeur : v=spf1 include:_spf.google.com ~all

Décodage :

• v=spf1, version du protocole.
• include:_spf.google.com, autorise les serveurs de Google Workspace. C’est ici que tu déclares ton fournisseur.
• ~all, softfail : tout le reste est suspect mais pas rejeté brutalement.

La valeur de l’include dépend de qui envoie tes mails :

Tu n’as droit qu’à un seul enregistrement SPF par domaine. Si tu envoies via plusieurs services (ta messagerie + un outil de newsletter), tu combines leurs include dans la même ligne, tu n’en crées pas deux.

Exemple combiné (Google Workspace + Brevo) :

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

DKIM : signer chaque message

DKIM (DomainKeys Identified Mail) est le protocole qui attache une signature cryptographique à chaque message, afin de prouver qu’il n’a pas été altéré en route. Il est normalisé par la RFC 6376. Ton fournisseur signe avec une clé privée ; le serveur de réception vérifie avec la clé publique que tu publies dans ton DNS.

Tu ne génères pas cette clé toi-même : ton fournisseur te la donne. Tu te contentes de la coller dans un enregistrement TXT, sur un sous-domaine spécifique appelé sélecteur.

Type : TXT
Nom  : google._domainkey   (le sélecteur dépend du fournisseur)
Valeur : v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...   (clé publique, très longue)

Où trouver ta clé DKIM :

• Google Workspace : Admin > Apps > Gmail > Authentifier l’email > Générer un nouvel enregistrement. Sélecteur par défaut : google.
• Microsoft 365 : centre d’administration Defender > Stratégies > DKIM. Microsoft te donne deux CNAME (selector1 et selector2) à publier, pas un TXT.
• Hébergeur mutualisé (OVH, Plesk, cPanel) : le panneau email propose souvent un bouton « activer DKIM » qui crée l’enregistrement automatiquement dans ta zone.

Microsoft 365 utilise des CNAME pour DKIM, pas des TXT. Ne convertis pas l’un en l’autre : recopie exactement le type d’enregistrement que ton fournisseur indique.

DMARC : dire quoi faire en cas d’échec

DMARC (Domain-based Message Authentication, Reporting and Conformance) est le protocole qui indique au serveur de réception comment réagir quand SPF ou DKIM échoue, et qui fait remonter des rapports sur les envois faits en ton nom. Il est normalisé par la RFC 7489. C’est le chef d’orchestre des deux autres.

C’est un TXT posé sur le sous-domaine _dmarc.

Type : TXT
Nom  : _dmarc
Valeur : v=DMARC1; p=quarantine; rua=mailto:dmarc@tondomaine.fr; pct=100; adkim=s; aspf=s

Décodage :

• p=quarantine, politique : les mails non authentifiés vont en spam. Les autres valeurs sont none (ne rien faire, juste observer) et reject (rejet pur).
• rua=mailto:..., adresse qui reçoit les rapports agrégés quotidiens.
• pct=100, applique la politique à 100 % du trafic.
• adkim=s / aspf=s, alignement strict.

La bonne progression : tu démarres en p=none pour observer sans rien casser, tu lis les rapports pendant quelques semaines, tu corriges SPF/DKIM si des envois légitimes échouent, puis tu passes en quarantine, et enfin reject quand tout est propre.

Tester : ne devine jamais, mesure

Une fois les trois enregistrements posés, attends la propagation DNS (de quelques minutes à 48 h, voir notre guide DNS qui ne propage pas) puis teste.

1. mail-tester.com, envoie un mail à l’adresse jetable qu’il te donne, reçois une note sur 10. C’est le test le plus complet : il vérifie SPF, DKIM, DMARC, la réputation de l’IP et le contenu, et te dit précisément ce qui cloche.
2. mxtoolbox.com, tape ton domaine dans les outils « SPF Record Lookup », « DKIM Lookup » (avec ton sélecteur) et « DMARC Lookup ». Vérifie que chaque enregistrement existe et est valide.
3. Google Postmaster Tools, pour suivre dans la durée ta réputation et ton taux de spam vu par Gmail. Indispensable si tu envoies en volume.

Envoie aussi un vrai test vers une adresse Gmail et une adresse Outlook : ouvre le mail, affiche « Afficher l’original » (Gmail) et vérifie que SPF, DKIM et DMARC affichent tous PASS.

Pièges courants

• SPF qui dépasse 10 lookups DNS. Chaque include consomme des requêtes DNS, et la norme en autorise 10 maximum (source : RFC 7208, section 4.6.4). Empiler trop d’include (messagerie + 3 outils marketing) casse silencieusement le SPF : il passe en permerror et tout échoue. Solution : nettoie les services que tu n’utilises plus, ou utilise un service de « SPF flattening ».
• Oublier DKIM en croyant que SPF suffit. SPF seul casse dès qu’un mail est transféré (le serveur intermédiaire change). DKIM, lui, survit au transfert. Les deux sont nécessaires, pas l’un OU l’autre.
• Passer en p=reject trop tôt. Si tu mets reject avant d’avoir vérifié que tous tes envois légitimes (facturation, CRM, formulaire de contact du site) passent l’authentification, tu bloques tes propres mails. Reste en none puis quarantine le temps de lire les rapports.
• Modifier le DNS et tester dans la minute. La propagation prend du temps. Tu testes l’ancienne valeur, tu crois que c’est cassé, tu re-modifies, et tu t’enfonces. Attends, puis vérifie avec un outil qui interroge les serveurs autoritaires, pas ton cache local.
• Deux enregistrements SPF sur le même domaine. Beaucoup de panneaux DNS te laissent en créer deux. Résultat : SPF invalide, tout échoue. Il n’en faut qu’un, qui combine tous tes include.

Une délivrabilité cassée coûte des clients en silence, et c’est souvent le symptôme d’un domaine mal configuré dont personne ne t’a remis les accès complets. Tu veux un regard concret sur ton site et tes emails ? Demande un audit gratuit.