Quand un email part en spam, le problème vient souvent du domaine, pas de l’outil
Quand un message finit en spam, le réflexe habituel consiste à accuser l’outil d’envoi. C’est humain. Mais, dans beaucoup de cas, le vrai sujet se trouve ailleurs : le domaine est mal configuré, ou mal reconnu par les serveurs de réception.
Autrement dit, le logiciel n’est pas toujours en cause. Le message peut être techniquement correct, mais partir avec une identité mal vérifiée. Et là, la délivrabilité email se dégrade vite, même si l’interface d’envoi paraît propre.
Le point de départ est souvent plus simple qu’on ne le croit :
- un enregistrement SPF absent ou incomplet ;
- une signature DKIM mal publiée ;
- une politique DMARC trop floue pour rassurer les filtres ;
- un sous-domaine utilisé sans cohérence avec le domaine principal ;
- des changements DNS récents encore mal propagés ou mal contrôlés.
Le problème est rarement “l’outil en lui-même”. Il vient plus souvent de la manière dont le domaine présente ses preuves d’authentification aux serveurs. C’est ce qui explique qu’un changement de plateforme ne règle pas toujours le spam.
Le bon réflexe consiste donc à vérifier la base DNS avant de changer d’abonnement ou de passer des heures sur les modèles d’email.
Quand cette base est saine, on peut enfin évaluer l’outil pour ce qu’il est : un transporteur. Quand elle est bancale, même un bon transporteur part avec un handicap.
L’essentiel
- Un email en spam signale souvent un problème d’identité du domaine, pas un défaut de l’outil d’envoi.
- Les premiers contrôles à faire sont SPF, DKIM, DMARC et la cohérence entre domaine principal et sous-domaine.
- Changer de plateforme sans corriger le DNS laisse souvent le même symptôme au même endroit.
Les 5 réglages DNS qui conditionnent la délivrabilité email
Quand un email finit en spam, il faut regarder la base avant l’interface. Sur le terrain, cinq réglages DNS suffisent souvent à expliquer l’essentiel du problème.
Ils ne dépendent pas d’un outil d’envoi en particulier. Ils dépendent du domaine, de la manière dont il prouve son identité, et de la cohérence entre ce que vous déclarez et ce que les serveurs reçoivent réellement.
- SPF : il autorise les serveurs à envoyer pour votre domaine. S’il est absent, incomplet ou trop large, la confiance baisse.
- DKIM : il signe le message. Sans signature valide, le contenu paraît moins fiable aux filtres.
- DMARC : il dit quoi faire quand SPF ou DKIM ne passent pas. Sans politique claire, le domaine reste plus difficile à interpréter.
- Le bon alignement entre domaine d’envoi et domaine visible : si l’adresse expéditrice, le sous-domaine et les signatures ne racontent pas la même histoire, les serveurs hésitent.
- Les enregistrements liés au sous-domaine : beaucoup d’envois partent d’un sous-domaine mal préparé, alors que le domaine principal semble correct en surface.
Le point clé, c’est que ces réglages travaillent ensemble. Un SPF propre ne compense pas une signature DKIM cassée. Un DMARC présent ne rassure pas si les identités ne s’alignent pas.
Un message peut donc être bien rédigé, bien ciblé, et finir quand même en spam si le DNS envoie des signaux contradictoires. C’est frustrant, mais c’est aussi ce qui rend le diagnostic plus simple : on peut vérifier chaque brique une par une.
Un outil d’envoi transporte le message. Le DNS, lui, prouve que ce message a le droit de partir au nom du domaine.
Quand cette base est propre, on arrête de confondre un problème d’authentification avec un problème de plateforme.
SPF, DKIM et DMARC ne servent à rien s’ils sont mal alignés
Le trio est souvent présenté comme un bloc unique. En pratique, ce n’est pas le cas. Chacun a un rôle précis, et un seul maillon mal relié suffit à brouiller le signal envoyé aux serveurs de réception.
SPF vérifie qui a le droit d’émettre. DKIM prouve que le message n’a pas été altéré. DMARC arbitre la suite quand l’un des deux échoue. Le problème, c’est que ces contrôles peuvent être présents sans raconter la même histoire.
C’est là que l’alignement devient décisif. Si l’adresse visible, le domaine de signature et le domaine déclaré ne correspondent pas correctement, le message peut paraître incohérent, même avec des enregistrements publiés.
- un SPF valide, mais trop large ou rattaché au mauvais sous-domaine ;
- une signature DKIM active, mais générée pour une autre identité d’envoi ;
- une politique DMARC en place, mais sans cohérence avec le domaine réellement utilisé dans l’en-tête ;
- un sous-domaine technique oublié alors qu’il porte une partie des envois ;
- des modifications DNS récentes qui ont corrigé un point et laissé les autres en décalage.
Le piège le plus courant n’est pas l’absence totale d’authentification. C’est une authentification partielle, ou mal raccordée, qui donne l’illusion que tout est en ordre alors que les serveurs voient une identité bancale.
Autrement dit, un email en spam ne signale pas seulement “un contrôle manquant” ; il signale souvent un ensemble de preuves qui ne convergent pas.
La réalité du terrain
Ce qu’on observe le plus souvent, ce n’est pas un domaine totalement “sans SPF, sans DKIM, sans DMARC”. C’est un domaine qui a commencé à se sécuriser, mais avec des réglages qui pointent dans des directions différentes. Les filtres ne lisent pas cela comme un effort, ils le lisent comme une identité incertaine. La conséquence pratique est simple : il faut vérifier l’alignement avant de chercher une panne côté outil.
Comparer les réglages DNS selon leur effet sur l’authentification, la réputation, la mise en confiance des serveurs et la facilité de vérification
Pour éviter de traiter tous les réglages DNS comme s’ils avaient le même rôle, il faut les lire à quatre niveaux. Certains prouvent l’identité. D’autres protègent l’image du domaine. D’autres encore rendent le message plus lisible pour les filtres.
Le tableau ci-dessous aide à trancher rapidement ce qui sécurise l’envoi, ce qui rassure les serveurs, et ce qui se contrôle le plus facilement au quotidien.
| Réglage | Authentification du message | Protection de la réputation | Simplicité de contrôle |
|---|---|---|---|
| SPF | Autorise les serveurs d’envoi déclarés | Limite l’usurpation du domaine | Vérification rapide dans le DNS public |
| DKIM | Signe le contenu avec une clé liée au domaine | Renforce la confiance sur les messages modifiés | Contrôle plus technique, mais lisible |
| DMARC | Coordonne SPF et DKIM pour l’alignement | Protège la réputation quand l’identité diverge | Lecture simple si la politique est publiée |
| Domaine d’envoi | Identité visible par le destinataire | Porte la réputation accumulée dans le temps | Contrôle simple dans l’adresse expéditrice |
| Sous-domaine d’expédition | Sépare les flux techniques des envois principaux | Isolé pour éviter de contaminer le domaine racine | À vérifier séparément dans la zone DNS |
La lecture utile est simple : SPF, DKIM et DMARC authentifient, tandis que le domaine et le sous-domaine organisent la réputation et la clarté du signal envoyé aux serveurs. Si un seul maillon est propre mais que les autres ne suivent pas, le diagnostic reste bancal.
Autrement dit, on ne cherche pas seulement un enregistrement “présent” ; on cherche un ensemble lisible, cohérent et vérifiable.
Quand cette grille est claire, il devient plus facile de savoir quoi corriger en premier avant de toucher à l’outil d’envoi. Le bon ordre de lecture évite de bricoler au hasard.
E-mailing · plateforme française
Brevo, pour une liste qui grossit plus vite que vos envois
Vérifié le 10 août 2026
Le suivi des retours serveur et des erreurs d’envoi évite de diagnostiquer à l’aveugle
Quand un email n’arrive pas, le réflexe courant consiste à accuser l’outil. C’est souvent trop rapide.
Les retours serveur, les rejets et les erreurs d’envoi disent pourtant beaucoup plus que l’interface de votre plateforme. Ils montrent si le blocage apparaît avant l’acceptation du message, au moment de l’authentification, ou après coup, côté filtrage.
La vraie question n’est pas “est-ce que l’email est parti ?” mais “à quel moment le trajet s’est arrêté ?”. C’est cette lecture qui permet de distinguer un souci de DNS, un problème de réputation ou une cadence d’envoi trop agressive.
- Rejet immédiat : le serveur refuse le message dès l’entrée. On regarde d’abord l’adresse, l’authentification et les enregistrements associés.
- Bounce différé : l’envoi a été accepté, puis bloqué plus loin. Le contenu, la réputation ou le comportement d’envoi deviennent alors des pistes sérieuses.
- Absence de retour clair : c’est souvent là que les diagnostics partent dans tous les sens. Sans code d’erreur lisible, on navigue à vue.
Dans la pratique, les messages d’erreur les plus utiles sont ceux qui nomment la cause ou la famille de cause. Un code lié à l’authentification n’oriente pas vers le même correctif qu’un rejet lié à la réputation du domaine ou à une politique de sécurité trop stricte.
Un bon diagnostic commence par le texte exact du refus, pas par une intuition sur l’outil.
Le bon réflexe consiste donc à garder une trace des bounces, à lire les réponses SMTP quand elles sont disponibles, puis à rapprocher ces indices de la configuration DNS et du rythme d’envoi. C’est plus lent qu’un avis à chaud, mais beaucoup plus fiable.
Sans ce suivi, on corrige parfois un réglage sain et on laisse intacte la vraie cause. Avec lui, le problème devient lisible. Et c’est là que la délivrabilité email cesse d’être une loterie.
Pourquoi mes emails vont en spam et que vérifier en priorité ?
❓ Pourquoi mes emails arrivent en spam alors que l’outil semble correct ?
Parce que l’outil n’est souvent que le véhicule. Si le domaine n’est pas proprement déclaré, si l’authentification est incomplète ou si l’adresse d’envoi mélange plusieurs usages, les serveurs destinataires se méfient vite.
La première vérification porte donc sur la configuration DNS du domaine, pas sur l’interface d’envoi. C’est là que se joue une grande partie du tri initial.
❓ Que faut-il regarder en premier dans le DNS ?
Il faut vérifier l’existence et la cohérence des enregistrements liés à l’envoi, puis contrôler que l’adresse expéditrice correspond bien au domaine déclaré. Un réglage absent, mal saisi ou publié sur le mauvais sous-domaine suffit à brouiller le signal.
Ensuite, il faut tester ce qui est réellement visible publiquement, pas ce qui a été saisi dans l’outil. Le DNS local ou “en attente” ne compte pas tant qu’il n’est pas publié correctement.
❓ Comment savoir si le problème vient de l’authentification ou de la réputation ?
Si les messages sont rejetés très tôt, la piste technique est prioritaire. Si les envois passent mais finissent classés en courrier indésirable, la réputation du domaine, la qualité de la liste et le rythme d’envoi prennent plus de poids.
Un rejet avec un message lié à la sécurité n’appelle pas le même correctif qu’un filtrage silencieux après acceptation. Le texte exact du retour serveur reste le meilleur indice de départ.
❓ Pourquoi un sous-domaine d’envoi peut-il changer la situation ?
Parce qu’il permet de séparer les flux. Quand les emails transactionnels, les newsletters et les tests partagent la même identité, un incident sur un flux peut contaminer les autres.
Avec un sous-domaine dédié, le diagnostic devient plus lisible et l’impact d’un incident reste mieux contenu. Cela ne règle pas tout, mais cela évite souvent de mélanger des usages qui n’ont pas la même sensibilité.
❓ Quand faut-il faire relire la configuration ?
Dès que les vérifications de base sont en place mais que les refus continuent, ou dès que les retours serveur restent ambigus. Une relecture est aussi utile quand plusieurs personnes ont modifié la zone DNS à des moments différents.
Le bon moment, c’est avant de multiplier les changements au hasard. Une configuration relue proprement fait souvent gagner du temps, parce qu’elle évite de corriger le mauvais maillon.
