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.
Dans 90 % des cas, le code de ton site n’y est pour rien. 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 envoie en volume. 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 :
| Protocole | Question posée | Réponse fournie |
|---|---|---|
| SPF | Ce serveur a-t-il le droit d’envoyer pour ce domaine ? | Liste des serveurs autorisés |
| DKIM | Le message a-t-il été modifié en route ? | Signature cryptographique |
| DMARC | Que faire si SPF ou DKIM échoue ? | Politique + rapports |
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) est un simple enregistrement TXT posé à la racine de ton domaine. Il liste les serveurs autorisés à envoyer du mail en ton nom.
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 :
| Fournisseur | Mécanisme SPF à inclure |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| OVH (mutualisé) | include:mx.ovh.com |
| Brevo / Sendinblue | include:spf.sendinblue.com |
| Mailgun | include:mailgun.org |
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
includedans 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) ajoute une signature cryptographique à chaque mail. Ton fournisseur signe avec une clé privée ; le serveur de réception vérifie avec une 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 (
selector1etselector2) à 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) est le chef d’orchestre. Il dit au serveur de réception comment réagir quand SPF ou DKIM échoue, et te fait remonter des rapports pour que tu voies qui envoie en ton nom.
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 sontnone(ne rien faire, juste observer) etreject(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.
- 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.
- 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.
- 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
includeconsomme des requêtes DNS, et la norme en autorise 10 maximum. Empiler trop d’include(messagerie + 3 outils marketing) casse silencieusement le SPF : il passe enpermerroret 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=rejecttrop tôt. Si tu metsrejectavant 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 ennonepuisquarantinele 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.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy