Polarys

Mes mails arrivent en spam chez mes clients

Un devis qui tombe en indésirable ne provoque aucune erreur, juste un client qui ne rappelle pas. Comment réparer, durablement.

Sommaire12

Mes mails arrivent en spam chez mes clients

Vous envoyez un devis. Personne ne répond. Vous relancez au téléphone, et le client vous dit la même phrase que les trois précédents : « ah, je viens de le retrouver dans mes indésirables ».

Rien ne vous a prévenu. Un mail classé en indésirable n'est pas un mail refusé : il part, il arrive, il est stocké, et il n'est simplement jamais lu. Aucun message d'erreur ne remonte dans votre boîte. C'est ce silence qui rend le problème coûteux : on perd des affaires pendant des mois sans jamais faire le lien.

Dans l'immense majorité des cas en très petite entreprise, la cause n'est ni votre texte, ni vos pièces jointes, ni votre fournisseur d'accès. C'est que votre nom de domaine ne dit pas qui a le droit d'envoyer du courrier en son nom. Ce guide explique ce mécanisme, puis fait poser les trois réglages qui le corrigent.

Ce guide traite le courrier sortant : le vôtre, qui n'arrive pas chez les autres. Si le problème est inverse, si ce sont des mails attendus qui n'arrivent pas jusqu'à vous, la fiche La boîte mail rejette ou n'affiche pas certains mails traite ce cas-là.

Pourquoi n'importe qui peut écrire votre adresse dans un mail

Le courrier électronique a été conçu à une époque où la question ne se posait pas. Résultat : l'adresse d'expéditeur affichée dans un mail est un simple champ de texte. Rien, dans le protocole lui-même, ne vérifie que celui qui envoie a le droit d'utiliser cette adresse. C'est l'équivalent exact de l'adresse que vous écrivez au dos d'une enveloppe : vous pouvez y mettre n'importe quoi, la Poste ne contrôle pas.

Un escroc peut donc envoyer, ce soir, un mail qui affiche contact@votre-entreprise.fr comme expéditeur. Il n'a besoin d'aucun accès à votre boîte, d'aucun mot de passe.

Les opérateurs de messagerie, Gmail, Outlook, Orange, Free, le savent. Alors ils ont ajouté une vérification par-dessus : avant d'afficher un mail, ils demandent au domaine expéditeur qui il autorise. Si le domaine ne répond rien, le mail n'est pas forcément bloqué, mais il devient suspect, et il part en indésirable.

Autrement dit, un domaine silencieux n'est pas un domaine neutre. C'est un domaine qui n'a pas de réponse à donner quand on demande des comptes pour lui.

Et depuis 2024, ce n'est plus une simple pondération : Gmail et Yahoo exigent formellement une authentification du domaine pour tout expéditeur, y compris les plus petits. Un domaine muet en 2026 finit en indésirable, mécaniquement.

Où le contrôle se fait, exactement

sequenceDiagram
    participant V as Votre boîte mail
    participant S as Serveur d'envoi
    participant D as DNS de votre domaine
    participant R as Serveur du client
    participant C as Boîte du client

    V->>S: Vous cliquez sur Envoyer
    S->>R: Le mail part, signé au passage
    R->>D: Qui a le droit d'envoyer pour ce domaine ?
    D-->>R: Réponse SPF, DKIM, DMARC
    alt Le domaine confirme
        R->>C: Boîte de réception
    else Le domaine ne répond rien
        R->>C: Indésirables
    end

Le point important de ce schéma : le contrôle ne se fait pas chez vous, il se fait chez le destinataire. Vous ne verrez donc jamais le problème depuis votre propre messagerie. Vos mails à vos collègues arrivent parfaitement, parce qu'ils ne passent pas par ce contrôle. C'est la raison pour laquelle ce défaut peut durer des années.

Ce qu'est un enregistrement DNS, en une minute

Le DNS (Domain Name System, l'annuaire d'Internet) est ce qui traduit un nom, votre-entreprise.fr, en informations exploitables par des machines. C'est aussi là qu'on publie des mentions publiques à propos du domaine : quel serveur héberge le site, quel serveur reçoit le courrier, et donc, qui a le droit d'envoyer.

Concrètement, quelque part chez votre hébergeur, il existe une page appelée zone DNS. Elle contient une liste de lignes. Chaque ligne a trois parties :

PartieCe que c'estExemple
NomSur quoi porte la ligne@ (le domaine lui-même) ou _dmarc
TypeLa nature de l'informationTXT, CNAME, MX
ValeurLe contenu publiév=spf1 include:...

Le type TXT (texte libre) est celui qui nous intéresse : c'est un simple texte publié sur le domaine, que n'importe quelle machine peut venir lire. Les trois réglages de ce guide sont des lignes de ce genre.

Où trouver cette page : chez OVHcloud, dans l'espace client, section Noms de domaine puis « Zone DNS ». Chez Gandi, dans le domaine puis « Enregistrements DNS ». Chez d'autres, cela s'appelle « Éditeur de zone » ou « Advanced DNS ». Si vous ne trouvez pas cette page, ou si le domaine a été acheté par quelqu'un d'autre il y a huit ans, arrêtez-vous ici : voir plus bas, « Quand passer la main ».

Les trois lignes à poser, dans cet ordre

Elles répondent à trois questions différentes, et elles se complètent. Posez-les dans l'ordre : DMARC ne sert à rien tant que les deux premières ne sont pas en place, et peut même faire des dégâts.

RéglageLa question à laquelle il répond
SPFQuels serveurs ont le droit d'envoyer pour ce domaine ?
DKIMCe mail est-il bien celui qui est parti, non modifié en route ?
DMARCQue faire si les deux premiers échouent, et qui prévenir ?

1. SPF : la liste des serveurs autorisés

Le SPF (Sender Policy Framework, cadre de politique d'expédition) est la liste publique des serveurs autorisés à envoyer du courrier pour votre domaine. Une seule ligne TXT, posée sur le domaine lui-même.

Sa forme est toujours la même :

v=spf1 include:<serveurs de votre fournisseur> ~all
  • v=spf1 : la version, invariable.
  • include:... : c'est ici que vous désignez votre fournisseur de messagerie. C'est la seule partie qui change d'un hébergeur à l'autre.
  • ~all : « tout le reste est douteux ». C'est la valeur à choisir au début. Sa variante stricte -all signifie « tout le reste est à rejeter » : elle est plus efficace, mais elle ne se pose qu'une fois que vous êtes certain d'avoir listé tous vos outils d'envoi.

Valeurs pour les cas les plus courants en France :

Votre messagerieNomTypeValeur à poser
Microsoft 365@TXTv=spf1 include:spf.protection.outlook.com -all
Google Workspace@TXTv=spf1 include:_spf.google.com ~all
OVHcloud (MX Plan, Email Pro, Zimbra)@TXTValeur fournie par OVHcloud, à récupérer dans l'espace client : la zone DNS d'un domaine avec messagerie OVHcloud est le plus souvent pré-remplie avec le bon include:, ne le réécrivez pas de mémoire
Gandi (Gandi Mail)@TXTValeur fournie par Gandi dans la fiche « Enregistrements DNS » du domaine, généralement déjà présente si la messagerie Gandi est active

Pourquoi cette prudence sur les deux dernières lignes : un include: erroné ne produit pas une erreur visible, il produit un SPF qui échoue silencieusement, donc exactement le problème que vous essayez de résoudre. Pour Microsoft 365 et Google Workspace, la valeur est universelle et documentée telle quelle. Pour les autres, recopiez ce que votre hébergeur affiche dans son interface, jamais un exemple trouvé ailleurs.

Le @ dans la colonne Nom signifie « le domaine lui-même », sans sous-domaine. Certaines interfaces demandent de laisser le champ vide, ou d'écrire le nom de domaine complet : c'est la même chose.

Le piège : ne jamais avoir deux lignes SPF

C'est l'erreur la plus fréquente, et elle est perverse, parce qu'elle survient au moment précis où vous essayez de bien faire.

Vous aviez déjà un SPF pour votre messagerie. Vous ajoutez un outil de devis, un logiciel de facturation, une infolettre, et cet outil vous donne une ligne SPF à poser. Vous l'ajoutez. Vous avez maintenant deux lignes TXT commençant par v=spf1 sur le même domaine.

La règle du protocole est sans appel : deux enregistrements SPF sur un domaine, c'est un SPF invalide. Pas « le plus récent gagne », pas « les deux s'appliquent ». Les serveurs destinataires considèrent la vérification comme cassée, et vos mails, y compris ceux qui partaient très bien la veille, basculent en indésirable.

La bonne manière : fusionner dans une seule ligne, en mettant plusieurs include: bout à bout.

Faux, deux lignes :

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

Juste, une seule ligne :

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

Le ~all reste unique, et toujours en dernier. Tout ce qui est écrit après lui est ignoré.

Limite à connaître : un SPF ne peut pas enchaîner plus de dix include: en cascade. Au-delà, il échoue, silencieusement là encore. Une TPE atteint rarement ce plafond, mais si vous accumulez cinq ou six outils d'envoi, c'est le moment d'en parler à un prestataire.

2. DKIM : la signature du courrier

Le DKIM (DomainKeys Identified Mail, courrier identifié par clés de domaine) ajoute une signature électronique à chaque mail qui part. Le serveur du destinataire vérifie cette signature auprès de votre domaine : si elle correspond, le mail est bien parti de chez vous et son contenu n'a pas été altéré en route.

Là où le SPF dit « ce serveur a le droit », le DKIM dit « ce message précis est authentique ». Les deux sont nécessaires, parce que le SPF seul se casse dès qu'un mail est réexpédié automatiquement, par exemple par une redirection d'adresse.

Point essentiel : une valeur DKIM ne se recopie jamais depuis un exemple. Elle contient une clé cryptographique unique, propre à votre domaine, générée par votre fournisseur. Copier celle d'un autre domaine produit une signature invalide, c'est-à-dire pire qu'aucune signature du tout.

Le DKIM ne se rédige donc pas, il s'active :

Votre messagerieOù l'activerCe que vous posez ensuite
Microsoft 365Portail Microsoft Defender, section Email et collaboration, Politiques, Paramètres d'authentification de messagerie, DKIMDeux enregistrements de type CNAME (alias de nom), nommés selector1._domainkey et selector2._domainkey, dont le portail vous donne les valeurs exactes. Vous revenez ensuite activer l'interrupteur dans le portail.
Google WorkspaceConsole d'administration, Applications, Google Workspace, Gmail, Authentifier les e-mailsUn enregistrement TXT nommé google._domainkey, dont la console affiche la valeur. Vous revenez ensuite cliquer sur « Démarrer l'authentification ».
OVHcloud, Gandi, autresInterface de gestion de la messagerie, rubrique DKIM ou « signature »L'hébergeur génère la clé et, le plus souvent, pose l'enregistrement lui-même si la zone DNS est chez lui.

Dans tous les cas, la séquence est la même : le fournisseur génère la clé, vous posez l'enregistrement dans la zone DNS, puis vous retournez activer la signature côté fournisseur. Cette dernière étape est celle qu'on oublie, et sans elle rien n'est signé.

3. DMARC : la consigne, en observation d'abord

Le DMARC (Domain-based Message Authentication, Reporting and Conformance, authentification de messages basée sur le domaine) répond à la question que les deux autres laissent ouverte : que doit faire le serveur destinataire quand SPF et DKIM échouent ? Et accessoirement : à qui envoyer un compte rendu ?

C'est une ligne TXT, sur le nom _dmarc.

Lisez ce paragraphe avant de poser quoi que ce soit. DMARC est le seul des trois qui peut couper du courrier légitime. Une consigne de rejet posée trop tôt, alors qu'un de vos outils n'est pas encore couvert par le SPF ou le DKIM, fait disparaître vos mails purement et simplement, sans indésirables, sans rattrapage. On ne commence donc jamais par le rejet.

La valeur à poser au départ :

NomTypeValeur
_dmarcTXTv=DMARC1; p=none; rua=mailto:VOTRE-ADRESSE@votre-domaine.fr

Une seule partie est à remplacer : VOTRE-ADRESSE@votre-domaine.fr, par une adresse que vous relevez réellement. Le reste se recopie tel quel.

Ce que disent ces trois morceaux :

  • v=DMARC1 : la version, invariable.
  • p=none : la consigne, ici « n'applique aucune sanction ». C'est le mode observation. Vous ne changez rien au traitement de votre courrier, vous demandez seulement à être informé.
  • rua=mailto:... : l'adresse à laquelle les grands opérateurs enverront un compte rendu, en général quotidien, listant tout ce qui a été envoyé sous votre nom et si cela a passé les contrôles.

Ces comptes rendus arrivent sous forme de fichiers compressés peu lisibles à l'œil nu. Ne cherchez pas à les décortiquer : ce qui vous intéresse, c'est simplement de constater, au bout de quelques semaines, que tout votre courrier légitime passe les vérifications. Des services gratuits savent les mettre en forme si vous voulez y regarder de près.

Durcir, mais plus tard. Après un ou deux mois d'observation sans surprise, et seulement si vous êtes certain que tous vos outils d'envoi, logiciel de facturation compris, sont couverts, on passe à p=quarantine (les mails non authentifiés partent en indésirable chez le destinataire), puis éventuellement à p=reject. Si vous n'êtes pas sûr, p=none reste utile : il suffit déjà à satisfaire l'exigence d'authentification des grands opérateurs. Rester en observation est infiniment préférable à un durcissement hasardeux.

Vérifier que c'est réparé, sans se raconter d'histoires

Attendez avant de tester. Une modification de zone DNS ne se propage pas instantanément : les serveurs du monde entier gardent l'ancienne réponse en mémoire pendant une durée fixée dans la zone, souvent quelques heures. Un test lancé dix minutes après la modification ne prouve donc rien : il peut afficher un échec alors que tout est correct, ou un succès trompeur en lisant une réponse mise en cache. Comptez 24 heures avant de conclure, 48 par prudence.

Ensuite, dans l'ordre :

  1. Envoyez un vrai mail à une adresse extérieure que vous contrôlez, de préférence une adresse Gmail ou Outlook personnelle. C'est le seul test qui reproduit vraiment le trajet, contrôle chez le destinataire compris.
  2. Ouvrez les détails techniques du message reçu. Dans Gmail : les trois points en haut à droite du message, puis « Afficher l'original ». Dans Outlook sur le web : les trois points, puis « Afficher la source du message ». Vous y cherchez trois lignes, et une seule chose compte, le mot qui suit :
spf=pass
dkim=pass
dmarc=pass
  1. Trois pass, c'est réparé. Un fail ou un none sur l'un des trois désigne précisément le réglage à reprendre, ce qui est déjà une information précieuse.

Ce qui ne prouve rien, et qu'il faut arrêter de faire :

  • Envoyer un mail à un collègue de la même entreprise : le message ne sort pas, il ne subit aucun contrôle externe.
  • Constater qu'un mail « est bien parti » depuis vos éléments envoyés : c'est toujours le cas, y compris quand il finit en indésirable à l'arrivée.
  • Demander à un client « est-ce que tu l'as reçu ? » : il regardera sa boîte de réception, pas ses indésirables.

Un dernier point de patience : réparer l'authentification corrige la cause, mais la réputation d'un domaine qui a longtemps envoyé sans authentification met quelques semaines à se rétablir complètement. L'amélioration est nette en quelques jours, totale en quelques semaines.

Ce que ce guide ne résout pas

Soyons clairs sur les limites, parce que croire qu'on a tout réglé est une manière de perdre encore des affaires.

  • Le contenu du mail compte aussi. Un objet tout en majuscules, une pièce jointe exécutable, un message composé d'une seule grande image sans texte : ces signaux pèsent, même avec une authentification parfaite.
  • Les envois en masse sont un autre métier. Si vous expédiez une infolettre à plusieurs centaines de contacts, cela relève des plateformes d'emailing spécialisées, avec leurs propres règles de réputation et de montée en charge progressive. Ce guide couvre votre courrier professionnel quotidien, pas la diffusion de masse.
  • Un domaine acheté la semaine dernière part avec une réputation neutre à construire. L'authentification est nécessaire, elle n'est pas suffisante dans les premières semaines.

Et un conseil à contre-courant, mais assumé : n'hébergez pas votre propre serveur de messagerie. L'idée revient régulièrement, souvent pour des raisons de coût ou d'indépendance. Pour une très petite entreprise, c'est une mauvaise décision : la délivrabilité d'un serveur autohébergé dépend de la réputation d'une adresse IP que vous ne maîtrisez pas, les grands opérateurs se méfient par défaut des petits serveurs isolés, et la maintenance de sécurité est permanente. Le coût réel n'est pas le serveur, c'est le courrier qui n'arrive pas. Une messagerie professionnelle hébergée coûte quelques euros par boîte et par mois, et c'est de l'argent bien placé.

Quand passer la main

Il y a des situations où insister coûte plus cher que d'appeler quelqu'un. Arrêtez-vous et faites appel à un prestataire si :

  • Vous n'avez pas accès à la zone DNS, ou vous ne savez pas qui détient le domaine. C'est fréquent quand le site a été fait par un tiers il y a des années. Récupérer la main sur un domaine est une démarche en soi, et ce n'est pas le moment d'improviser.
  • Le domaine sert déjà à plusieurs outils qui envoient du courrier : messagerie, logiciel de devis, boutique en ligne, plateforme de prise de rendez-vous. Fusionner correctement les SPF de tout ce monde demande un inventaire, et une erreur coupe tout.
  • Vous voyez des lignes que vous ne comprenez pas dans la zone DNS et vous hésitez à les toucher. Supprimer un enregistrement MX ou un CNAME au passage coupe la messagerie ou le site, immédiatement.
  • Vous avez déjà posé un DMARC en p=reject et du courrier a commencé à disparaître. Repassez en p=none sans attendre, puis faites-vous accompagner.

Comptez une à deux heures de prestation pour un domaine simple. C'est très peu au regard d'un devis perdu.

À retenir

  • Un mail en indésirable ne génère aucune erreur : le problème est invisible tant qu'on ne le cherche pas.
  • La cause habituelle n'est pas votre texte, c'est que votre domaine ne dit pas qui a le droit d'envoyer en son nom.
  • Trois lignes dans la zone DNS répondent à cela : SPF (quels serveurs), DKIM (signature du message), DMARC (la consigne).
  • Un seul enregistrement SPF par domaine, jamais deux : on fusionne les include: dans une ligne unique.
  • La clé DKIM ne se recopie pas : elle est propre à votre domaine et se génère chez votre fournisseur.
  • DMARC se pose en p=none, en observation. Le durcissement vient plus tard, ou jamais.
  • On vérifie 24 heures après, en s'envoyant un vrai mail vers l'extérieur, et on lit spf=pass, dkim=pass, dmarc=pass dans la source du message.

Mini-exercice

Envoyez dès maintenant un mail depuis votre adresse professionnelle vers une adresse Gmail personnelle, avec un objet ordinaire, par exemple « test ». Ouvrez le message reçu, affichez l'original, et cherchez les trois lignes spf=, dkim=, dmarc=.

Notez ce que vous lisez avant toute modification. C'est votre point de départ, et c'est aussi ce qui vous permettra de prouver, dans deux jours, que vous avez réellement réparé quelque chose.

À lire ensuite

Sur le même thème, pour aller plus loin.

Besoin d'un accompagnement personnalisé ?

Cours 1:1, conseil de solution, ou simplement une question précise - contacte-moi directement.