Lire le refus avant de chercher la cause
Quand vos e-mails arrivent en spam, le réflexe habituel consiste à réécrire le message ou à changer d’objet. C’est rarement la bonne piste : le plus souvent, le classement en indésirable vient d’un défaut technique côté domaine ou côté serveur. Avant toute correction, réunissez trois éléments.
- Le message de refus (bounce). Il contient un code (par exemple
550 5.7.1) et une phrase qui nomme souvent la cause : authentification, réputation d’IP, liste noire. Copiez-la intégralement. - Les en-têtes complets. Demandez au destinataire d’afficher l’original du message (« Afficher l’original » dans Gmail, « Afficher la source » dans Outlook). La ligne
Authentication-Resultsindiquespf=passoufail,dkim=passoufail,dmarc=passoufail. Un seulfailsuffit à expliquer le problème. - Un rapport de test. Envoyez un message ordinaire, avec votre signature habituelle, à l’adresse jetable fournie par un service comme mail-tester, et visez l’absence d’erreur plutôt que la note maximale.
Cause 1 : SPF, DKIM ou DMARC absents ou mal alignés
Les trois mécanismes répondent à une question du destinataire : ce serveur a-t-il le droit d’envoyer au nom de ce domaine ? SPF liste les serveurs autorisés dans un enregistrement DNS TXT ; DKIM signe chaque message avec une clé publiée en DNS ; DMARC indique quoi faire quand les deux échouent et où envoyer les rapports. Le guide SPF, DKIM et DMARC : méthode et dépannage détaille la publication des enregistrements ; cette section se limite au diagnostic.
Comment le vérifier
- Un seul enregistrement TXT
v=spf1sur le domaine : deux SPF au même niveau produisent une erreur permanente. - L’enregistrement DKIM (le sélecteur indiqué par Plesk, souvent
default._domainkey) doit répondre. _dmarc.votredomaine.frdoit exister, au minimumv=DMARC1; p=none; rua=mailto:….- Dans les en-têtes, contrôlez l’alignement : le domaine qui passe SPF ou DKIM doit être celui du champ
From, sinondmarc=fail.
Comment le corriger
Ajoutez au SPF chaque service qui envoie en votre nom (serveur NovaHoster, outil d’e-mailing, CRM, site web), activez DKIM dans Plesk, puis publiez DMARC en p=none et durcissez vers p=reject quand tous les expéditeurs légitimes sont alignés. Ces enregistrements se posent dans la zone DNS, décrite dans le guide Configurer les DNS d’un domaine. Comptez en général de quelques minutes à quelques heures de propagation.
Cause 2 : une adresse gratuite utilisée pour l’entreprise
Envoyer les devis et factures d’une société depuis une adresse @gmail.com ou @yahoo.fr pose deux problèmes. Le premier est technique : vous ne contrôlez ni le SPF, ni le DKIM, ni la politique DMARC de ce domaine. Si cette adresse sert d’expéditeur dans un outil d’e-mailing, un CRM ou le formulaire de votre site, DMARC échoue ; Yahoo publiant p=reject, ces messages sont refusés. Le second est la réputation : une adresse créée en deux minutes inspire moins confiance qu’un domaine enregistré depuis des années.
Comment le vérifier
Regardez le champ From de vos envois automatiques (site, newsletter, logiciel de facturation). S’il se termine par un domaine que vous ne possédez pas, vous êtes concerné.
Comment le corriger
- Réservez un nom de domaine à votre raison sociale.
- Créez les boîtes sur ce domaine avec un service d’e-mail professionnel : vous publiez alors vous-même les enregistrements d’authentification.
- Remplacez l’adresse gratuite dans chaque outil, puis ajoutez ces outils au SPF.
Le guide Configurer une adresse NovaHoster : Outlook, IMAP et SMTP décrit le paramétrage des boîtes ; envoyez toujours par le SMTP du domaine, jamais par celui d’un fournisseur d’accès.
Causes 3 et 4 : reverse DNS, HELO et réputation de l’IP partagée
À la connexion, le serveur destinataire voit une adresse IP et un nom annoncé dans la commande HELO. Il vérifie que l’IP a un enregistrement inverse (PTR) pointant vers un nom d’hôte, et que ce nom résout vers la même IP. Google exige cette cohérence de tous les expéditeurs. Sur un hébergement mutualisé, NovaHoster gère le PTR et le HELO des serveurs sortants ; le problème apparaît sur un serveur dédié ou un VPS que vous administrez.
Comment le vérifier
La première ligne Received: des en-têtes indique l’IP et le nom HELO de votre serveur. Un test « Reverse Lookup » (MXToolbox en propose un) montre vers quel nom pointe le PTR. Nom PTR, nom HELO et résolution directe doivent correspondre.
Comment le corriger
Le PTR se règle chez le fournisseur de l’IP, pas dans votre zone DNS : sur un serveur dédié NovaHoster, demandez-le par ticket. Réglez ensuite le nom d’hôte du serveur dans Plesk pour que le HELO corresponde.
L’IP partagée et sa réputation
Sur un mutualisé, votre domaine envoie depuis une IP commune à d’autres clients ; un compte voisin compromis peut dégrader temporairement sa réputation. Si votre activité dépend de l’e-mail (devis, relances, notifications d’une boutique), un serveur mail privé avec IP propre, PTR et DKIM réglés à la livraison, isole votre réputation de celle des voisins. Ce choix se justifie en général à partir de plusieurs centaines de messages par jour.
Cause 5 : votre domaine ou votre IP figure sur une liste noire
Les listes noires (DNSBL) recensent des IP ou des domaines vus en train d’envoyer du spam ; les serveurs destinataires les interrogent à chaque connexion. Figurer sur une liste obscure n’a presque aucun effet, figurer sur Spamhaus bloque une part importante de vos envois.
Comment le vérifier
- Relevez l’IP sortante dans les en-têtes d’un message ou dans le refus.
- Soumettez cette IP, puis votre domaine, au test « Blacklist Check » de MXToolbox ou à un service équivalent.
- Lisez le motif donné : spam effectif, plage d’IP dynamique, domaine récent, absence de PTR.
Comment le corriger
Supprimez d’abord la cause (compte piraté, formulaire exploité, mot de passe volé), sinon la réinscription est rapide. Chaque liste a sa procédure de retrait, souvent un formulaire en ligne. Sur un mutualisé, c’est NovaHoster qui demande le retrait de l’IP : ouvrez un ticket avec le nom de la liste et l’heure du refus. Pour éviter la récidive, un antispam professionnel filtre aussi le trafic sortant : un message suspect est bloqué avant de salir la réputation du domaine.
Causes 6 et 7 : contenu, mise en forme, volume et rythme
Une fois l’authentification et la réputation correctes, le contenu entre en jeu. Les filtres n’utilisent plus de liste fixe de mots interdits, mais certains schémas restent pénalisants parce qu’ils ressemblent au spam.
Contenu et mise en forme : ce qui déclenche les filtres
- Un message composé d’une seule image, sans texte lisible.
- Des liens raccourcis (bit.ly et équivalents), qui masquent la destination comme dans le hameçonnage.
- Les majuscules, les points d’exclamation en série, les mentions insistantes d’argent, d’urgence ou de gain.
- Les pièces jointes exécutables ou compressées (
.exe,.zip,.js) et les documents Office avec macros.
Le rapport de mail-tester liste les règles SpamAssassin déclenchées avec leur poids : corrigez d’abord les plus lourdes.
Volume et rythme : la montée en charge
Un domaine ou une IP qui n’envoyait rien et passe d’un coup à plusieurs milliers de messages par jour est traité avec méfiance, même bien configuré : les grands destinataires bâtissent la réputation sur l’historique. Augmentez progressivement (quelques dizaines de messages par jour, doublement chaque semaine, surveillance des rebonds et des plaintes) et gardez un rythme régulier : 2 500 messages par semaine passent mieux qu’un envoi mensuel de 10 000.
Causes 8, 9 et 10 : envoi massif depuis la boîte, listes achetées, rebonds
Ces trois causes viennent de la même erreur : utiliser une boîte de correspondance comme outil de diffusion.
Envoi massif depuis la boîte au lieu d’un outil d’e-mailing
Un serveur mutualisé limite les envois par heure et par boîte. Un publipostage depuis Outlook avec deux cents adresses en copie cachée dépasse ce quota, produit des refus temporaires et ressemble à un compte compromis ; sans lien de désinscription, les destinataires signalent. Au-delà de quelques dizaines de personnes, passez par un outil d’e-mailing dédié (Brevo, Mailchimp, Mailjet ou autre) authentifié sur votre domaine, et réservez la boîte aux échanges individuels.
Listes achetées et absence de désinscription
Une liste achetée contient des adresses qui ne vous ont rien demandé, des adresses mortes et souvent des pièges (spam traps) posés par les opérateurs de listes noires : un seul envoi suffit à inscrire votre IP. En France, la prospection vers des particuliers exige leur consentement préalable ; vers des professionnels, le message doit rester lié à leur fonction et offrir une désinscription simple. Vérifiez sur chaque campagne un lien de désinscription visible, fonctionnel en un clic, et traité dans les jours qui suivent.
Boîtes inexistantes et taux de rebond
Chaque message vers une adresse disparue revient en erreur 550 5.1.1, et un taux de rebond élevé signale que vous n’entretenez pas vos listes. Votre outil d’e-mailing affiche les rebonds durs par campagne ; depuis une boîte, comptez les messages de non-remise. Supprimez immédiatement toute adresse en rebond dur et nettoyez les fichiers anciens avant tout envoi. Visez en général un taux inférieur à quelques pour cent.
Cause 11 : un site piraté envoie du spam en votre nom
C’est la cause la plus brutale : vos e-mails arrivent en spam du jour au lendemain sans que vos pratiques aient changé. Un site WordPress ou PrestaShop compromis, ou un formulaire de contact sans protection, expédie des milliers de messages depuis votre hébergement ; l’IP et le domaine atterrissent sur des listes noires, et vos messages légitimes suivent.
Comment le vérifier
- Dans Plesk, consultez la file d’attente de messagerie : des centaines de messages vers des destinataires inconnus, avec des objets commerciaux, confirment l’intrusion.
- Dans le journal de messagerie, regardez si les envois partent d’un script PHP plutôt que d’une boîte authentifiée.
- Lancez une analyse Imunify360 depuis Plesk : les fichiers injectés apparaissent dans le rapport.
Comment le corriger
Le guide Supprimer un malware avec Imunify360 décrit le nettoyage pas à pas. Dans l’ordre : purger la file d’attente, mettre les fichiers infectés en quarantaine, changer tous les mots de passe (Plesk, FTP, base de données, boîtes, administration du site), mettre à jour le CMS et ses extensions, puis demander le retrait des listes noires. Ajoutez un captcha sur chaque formulaire.
Cause 12 : les exigences de Gmail et Yahoo pour les expéditeurs
Depuis février 2024, Google et Yahoo appliquent des règles communes à tous les expéditeurs, avec un niveau supplémentaire pour les envois en volume (Google fixe le seuil à environ 5 000 messages par jour vers Gmail). Qui ne les respecte pas voit ses messages refusés ou classés en indésirable.
Pour tous les expéditeurs
- SPF ou DKIM valide sur le domaine d’envoi.
- Enregistrement PTR cohérent pour l’IP d’envoi.
- Connexion TLS pour la transmission.
- Taux de signalement comme spam maintenu bas.
Pour les expéditeurs en volume
- SPF et DKIM, tous deux en place.
- DMARC publié, au minimum
p=none, avec alignement du domaineFrom. - Désinscription en un clic pour les messages marketing : en-têtes
List-UnsubscribeetList-Unsubscribe-Postconformes à la RFC 8058, demande traitée sous deux jours. - Taux de plainte mesuré dans Google Postmaster Tools inférieur à 0,10 %, et jamais au-delà de 0,30 %.
Comment le vérifier : inscrivez votre domaine dans Google Postmaster Tools (gratuit, après preuve de propriété par un enregistrement DNS) pour suivre la réputation, le taux de plainte et les erreurs d’authentification telles que Gmail les mesure ; Yahoo publie ses recommandations sur son portail pour expéditeurs. Comment le corriger : les outils d’e-mailing sérieux ajoutent les en-têtes de désinscription automatiquement, vérifiez-le sur un message de test ; pour des envois depuis votre propre serveur, c’est à votre développeur de les ajouter.
Tableau récapitulatif : cause, vérification, correction, responsable
Les douze causes dans l’ordre de diagnostic conseillé, avec le responsable de chaque correction.
| Cause | Vérification | Correction | Qui s’en charge |
|---|---|---|---|
| 1. SPF, DKIM, DMARC absents ou non alignés | En-tête Authentication-Results, requête DNS | Publier et aligner les trois enregistrements | Vous (zone DNS), support NovaHoster si besoin |
| 2. Adresse gratuite pour l’entreprise | Domaine du champ From | Domaine propre et boîtes professionnelles | Vous |
| 3. PTR ou HELO incohérent | Test Reverse Lookup, en-tête Received | Demander le PTR, régler le hostname | Hébergeur (mutualisé : déjà fait) |
| 4. IP partagée à mauvaise réputation | Refus mentionnant l’IP, Postmaster Tools | Ticket à l’hébergeur ; serveur mail privé si envois critiques | Hébergeur, puis vous |
| 5. Liste noire | Blacklist Check sur IP et domaine | Supprimer la cause, demander le retrait | Hébergeur pour l’IP, vous pour le domaine |
| 6. Contenu et mise en forme | Rapport mail-tester, règles SpamAssassin | Texte réel, liens complets, pas de pièce jointe risquée | Vous |
| 7. Volume et rythme | Refus temporaires 4xx, historique d’envoi | Montée en charge progressive, rythme régulier | Vous |
| 8. Envoi massif depuis la boîte | Quota dépassé, copies cachées nombreuses | Outil d’e-mailing authentifié sur le domaine | Vous |
| 9. Liste achetée, pas de désinscription | Origine des adresses, lien de désinscription | Consentement, lien en un clic, nettoyage | Vous, service marketing |
| 10. Rebonds élevés | Taux de rebonds durs par campagne | Suppression immédiate des adresses invalides | Vous |
| 11. Site piraté | File d’attente Plesk, analyse Imunify360 | Nettoyage, mots de passe, mises à jour | Vous ou prestataire, support NovaHoster |
| 12. Exigences Gmail et Yahoo | Postmaster Tools, en-têtes de désinscription | DMARC, désinscription en un clic, taux de plainte | Vous, développeur, outil d’e-mailing |
Liste de contrôle et outils gratuits de test
Passez cette liste chaque trimestre et après tout changement d’outil d’envoi ou d’hébergement.
- Un seul SPF, incluant tous les services expéditeurs, sous dix consultations DNS.
- DKIM actif dans Plesk pour chaque domaine d’envoi.
- DMARC publié avec une adresse de rapport que quelqu’un lit réellement.
- Toutes les adresses d’expédition (site, CRM, facturation) sur votre domaine.
- IP et domaine absents des principales listes noires.
- Test mail-tester sans erreur d’authentification ni de liste noire.
- Domaine inscrit dans Google Postmaster Tools, taux de plainte surveillé.
- Diffusions en nombre par un outil d’e-mailing, jamais depuis une boîte.
- Lien de désinscription en un clic sur chaque message marketing ; adresses en rebond dur supprimées après chaque envoi.
- CMS, extensions et mots de passe à jour ; analyse Imunify360 sans alerte.
Les outils gratuits à connaître
mail-tester note un message réel et liste les règles antispam déclenchées (tests gratuits limités par jour). MXToolbox vérifie les enregistrements DNS (SPF, DKIM, DMARC, PTR) et interroge les listes noires. Google Postmaster Tools montre, pour le trafic vers Gmail seulement et à partir d’un certain volume, la réputation du domaine et de l’IP et le taux de plainte. Ces outils tiers évoluent et leurs résultats restent indicatifs. En cas de doute côté serveur, ouvrez un ticket avec les en-têtes complets du message et le rapport de test : c’est ce qui permet une réponse précise dès le premier échange.
Questions fréquentes
Pourquoi mes e-mails arrivent en spam alors que SPF, DKIM et DMARC sont corrects ?
Comment savoir si mon domaine est sur une liste noire ?
Un mail professionnel en indésirable chez Gmail uniquement, que vérifier ?
Faut-il un serveur mail privé pour améliorer la délivrabilité e-mail ?
Puis-je envoyer ma newsletter depuis Outlook avec mon adresse professionnelle ?
Quelles sont les exigences de Gmail et Yahoo pour les expéditeurs depuis 2024 ?
Combien de temps faut-il pour que la réputation d’un domaine e-mail se rétablisse ?
Guides liés
Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :
Sources techniques
[1] Google — Exigences pour les expéditeurs d’e-mails (Email sender guidelines) [2] Yahoo — Sender Hub : bonnes pratiques et exigences pour les expéditeurs [3] IETF — RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC) [4] IETF — RFC 7208 : Sender Policy Framework (SPF) [5] IETF — RFC 8058 : Signaling One-Click Functionality for List Email Headers
Les options visibles et les formules dépendent de votre abonnement. Faites vérifier le contexte depuis l’Espace client, sans transmettre de mot de passe.
Demander une vérification