Pourquoi vos emails arrivent en spam : le guide diagnostic complet
Par CaptainDNS
Publié le 4 février 2026
Mis à jour le 10 novembre 2026
- 5 causes principales : authentification (SPF/DKIM/DMARC), réputation IP/domaine, contenu suspect, mauvais engagement, configuration technique
- Vérification prioritaire : testez votre IP sur les blacklists majeures et auditez votre authentification
- Depuis 2024 : Gmail et Yahoo exigent SPF, DKIM et DMARC pour les expéditeurs de masse
- Rejets Outlook.com de novembre 2026 (AS9031519) : sans DMARC applicable, l'ajout de
p=noneest le contournement rapporté. Des rejets sont aussi signalés avec SPF, DKIM et DMARC en pass : si votre authentification est déjà correcte, ne réécrivez pas vos enregistrements et suivez la procédure de signalement de la section Outlook.com - À partir de novembre 2026 : Spamhaus déploie progressivement une exigence de HELO valide, de PTR et d'A concordants pour chaque IP d'envoi, au risque d'un listing
- Seuil critique : un taux de plainte supérieur à 0,1% déclenche le classement en spam
- Diagnostic rapide : analysez vos en-têtes email pour identifier le problème exact
Pourquoi vos emails sont classés comme spam
Chaque jour, des milliards d'emails sont filtrés par les systèmes anti-spam. Un email sur six n'atteint jamais la boîte de réception de son destinataire. Pour les entreprises, c'est un enjeu critique : factures non reçues, confirmations de commande perdues, communications clients ignorées.
Le classement en spam n'est pas aléatoire. Les fournisseurs de messagerie (Gmail, Outlook, Yahoo) utilisent des centaines de signaux pour décider du sort de chaque email. Comprendre ces signaux est la clé pour résoudre le problème : ils se ramènent à cinq piliers mesurables (authentification, réputation, sécurité du transport, BIMI, engagement) que décompose notre guide sur le score de délivrabilité email.
Ce guide analyse les 5 causes principales du classement en spam et vous donne un plan d'action concret pour chaque situation. Que vous soyez administrateur système, responsable marketing ou développeur, vous trouverez les réponses à vos questions.
Cause 1 : Authentification email absente ou incorrecte
L'authentification email est devenue obligatoire en 2024. Gmail, Yahoo et Apple ont annoncé que les emails non authentifiés seraient systématiquement rejetés ou classés en spam.
Les 3 protocoles d'authentification
| Protocole | Fonction | Impact si absent |
|---|---|---|
| SPF | Liste les serveurs autorisés à envoyer pour votre domaine | Rejet ou spam |
| DKIM | Signe cryptographiquement chaque email | Spam ou défiance |
| DMARC | Définit la politique en cas d'échec SPF/DKIM | Pas de protection contre l'usurpation ; rejets Outlook.com rapportés depuis novembre 2026 (pas la seule situation signalée) |
Vérifier votre configuration
Utilisez un audit email domaine pour vérifier instantanément si votre domaine est correctement configuré :
- Entrez votre nom de domaine
- Consultez les résultats SPF, DKIM et DMARC
- Suivez les recommandations de correction
Erreurs SPF courantes
| Erreur | Conséquence | Solution |
|---|---|---|
| Pas de record SPF | Emails classés en spam | Créer un record TXT avec v=spf1 |
| Trop d'includes (>10 lookups) | SPF invalide (PermError) | Optimiser ou utiliser un service de flattening |
| IP manquante | Échec SPF pour certains envois | Ajouter l'IP ou le include du service |
| ~all vs -all | Politique trop permissive | Utiliser -all en production |
Erreurs DKIM courantes
| Erreur | Conséquence | Solution |
|---|---|---|
| Pas de signature | Email non authentifié | Configurer DKIM sur le serveur mail |
| Clé trop courte (<1024 bits) | Signature considérée faible | Générer une clé 2048 bits |
| Sélecteur incorrect | Échec de vérification | Vérifier le DNS et la configuration serveur |
| Corps modifié | Signature invalide | Vérifier les relais intermédiaires |
DMARC : la politique qui change tout
DMARC est le chef d'orchestre de l'authentification. Sans lui, même avec SPF et DKIM valides, vos emails peuvent être classés en spam, ou refusés pendant la transaction SMTP. Un refus ne dépose rien dans le dossier indésirable : l'expéditeur reçoit un rapport de non-remise et le message n'est pas livré. Depuis début novembre 2026, des opérateurs rapportent ce type de refus chez Outlook.com pour des domaines sans enregistrement DMARC. Les signalements de novembre visent aussi des domaines dont SPF, DKIM et DMARC sont déclarés corrects : l'absence de DMARC n'explique pas tous les cas (détail dans la section Outlook.com plus bas).
# Record DMARC p=none avec rapports agrégés
_dmarc.captaindns.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"
# Record DMARC strict (recommandé en production)
_dmarc.captaindns.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com"
| Politique | Comportement | Recommandation |
|---|---|---|
p=none | Surveillance uniquement | Phase initiale (2-4 semaines) |
p=quarantine | Emails suspects en spam | Phase intermédiaire |
p=reject | Emails suspects rejetés | Production sécurisée |
Cause 2 : Réputation IP ou domaine dégradée
Même avec une authentification parfaite, vos emails peuvent atterrir en spam si votre réputation est mauvaise. Les fournisseurs de messagerie maintiennent des scores de réputation basés sur l'historique d'envoi.
Comprendre la réputation
La réputation se compose de deux éléments :
- Réputation IP : Score de l'adresse IP qui envoie les emails
- Réputation domaine : Score du domaine d'envoi (From)
| Facteur | Impact sur la réputation |
|---|---|
| Taux de plainte spam | Très élevé (seuil : 0,1%) |
| Taux de bounce | Élevé (seuil : 5%) |
| Engagement (ouvertures, clics) | Modéré |
| Historique du domaine | Modéré |
| Blacklists | Critique |
Vérifier si votre IP est blacklistée
Une IP sur une blacklist majeure (Spamhaus, Barracuda) verra ses emails systématiquement rejetés par Gmail, Outlook et Yahoo.
Pour vérifier si votre IP est listée, testez-la contre les principales DNSBL :
- Spamhaus ZEN : Utilisée par la majorité des grands providers
- Barracuda BRBL : Très répandue en entreprise
- SpamCop : Basée sur les signalements utilisateurs
Blacklists à surveiller en priorité
| Blacklist | Impact | Utilisée par |
|---|---|---|
| Spamhaus ZEN | Critique | Gmail, Yahoo, Outlook |
| Barracuda BRBL | Critique | Entreprises, filtres Barracuda |
| SpamCop | Élevé | Nombreux providers |
| UCEProtect | Modéré | Filtres anti-spam |
Améliorer sa réputation
| Action | Impact | Délai |
|---|---|---|
| Demander le delisting des blacklists | Immédiat | 24-72h |
| Réduire le taux de plainte | Élevé | 2-4 semaines |
| Retirer les hard bounces qui visent l'adresse (utilisateur inconnu, boîte inexistante). Un refus qui vise le domaine, l'IP ou l'authentification se corrige à la source, sans retirer le destinataire | Élevé | Immédiat |
| Réchauffer progressivement les nouvelles IPs | Préventif | 4-6 semaines |
Cause 3 : Contenu problématique
Les filtres anti-spam analysent le contenu de chaque email. Certains éléments déclenchent automatiquement un classement en spam.
Mots et expressions à éviter
Les filtres anti-spam utilisent des listes de mots suspects. Voici les catégories les plus risquées :
| Catégorie | Exemples | Risque |
|---|---|---|
| Urgence excessive | "URGENT", "Agissez maintenant", "Dernière chance" | Élevé |
| Promesses financières | "Gratuit", "Gagnez de l'argent", "Sans frais" | Élevé |
| Pression commerciale | "Offre limitée", "Plus que 24h", "Stock épuisé" | Modéré |
| Expressions suspectes | "Cliquez ici", "100% garanti", "Aucun engagement" | Modéré |
Structure de l'email
| Problème | Pourquoi c'est filtré | Solution |
|---|---|---|
| Email 100% image | Texte caché, technique de spammeur | Ratio 60% texte / 40% images |
| Liens raccourcis (bit.ly) | Masquent la destination | Utiliser les URLs complètes |
| Trop de liens | Comportement spam typique | Maximum 3-5 liens par email |
| Pas de version texte | HTML uniquement = suspect | Toujours inclure text/plain |
| Formulaires intégrés | Technique de phishing | Liens vers le site web |
Ratio HTML/texte optimal
Contenu recommandé :
- Texte : 60-80%
- Images : 20-40%
- Liens : 3-5 maximum
- Taille totale : < 100 Ko
Cause 4 : Mauvais engagement des destinataires
Les fournisseurs de messagerie mesurent comment les destinataires interagissent avec vos emails. Un faible engagement signale un contenu non désiré.
Signaux d'engagement négatif
| Signal | Impact | Seuil critique |
|---|---|---|
| Plaintes spam | Très élevé | >0,1% déclenche le spam |
| Hard bounces | Élevé | >5% dégrade la réputation |
| Soft bounces répétés | Modéré | >10% sur 30 jours |
| Faible taux d'ouverture | Modéré | <10% sur listes actives |
| Désabonnements élevés | Modéré | >1% par campagne |
Le cercle vicieux du spam
Faible engagement → Classement en spam → Encore moins d'engagement → Réputation dégradée
Pour briser ce cercle :
- Nettoyez vos listes : Supprimez les adresses inactives depuis plus de 6 mois
- Segmentez : Envoyez du contenu pertinent à chaque segment
- Respectez le consentement : Double opt-in obligatoire
- Facilitez le désabonnement : Lien visible, processus en 1 clic
Bonnes pratiques d'hygiène de liste
| Action | Fréquence | Impact |
|---|---|---|
| Supprimer les hard bounces qui visent l'adresse (utilisateur inconnu, boîte inexistante). Si le refus vise le domaine, l'IP ou l'authentification : corriger la cause et renvoyer, sans toucher à la liste | Immédiat | Critique |
| Supprimer les plaintes spam | Immédiat | Critique |
| Nettoyer les inactifs (>6 mois) | Mensuel | Élevé |
| Ré-engagement des tièdes | Trimestriel | Modéré |
| Validation des emails à l'inscription | Continu | Préventif |
Cause 5 : Configuration technique défaillante
Des problèmes de configuration technique peuvent saboter tous vos efforts.
Checklist de configuration serveur
| Élément | Vérification | Commande |
|---|---|---|
| Reverse DNS (PTR) | L'IP doit résoudre vers un FQDN | dig -x <IP> |
| FQDN vers IP | Le FQDN doit résoudre vers l'IP | dig A <fqdn> |
| HELO/EHLO | Doit résoudre vers l'IP d'envoi et rester le même | Logs serveur |
| Port 25 ouvert | Pas de blocage FAI | telnet mail.server.com 25 |
| TLS activé | STARTTLS obligatoire | Test de connexion |
Reverse DNS : pourquoi c'est critique
Le reverse DNS (PTR record) est vérifié par tous les providers majeurs. Sans PTR valide, vos emails sont immédiatement suspects.
# Vérifier le PTR de votre IP
dig -x 192.0.2.1
# Résultat attendu
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.captaindns.com.
# Le FQDN doit résoudre vers la même IP
dig A mail.captaindns.com
# Résultat : 192.0.2.1
Configuration HELO/EHLO
Le serveur mail s'identifie avec HELO ou EHLO. Le nom annoncé doit :
- Être un FQDN valide (pas une IP, pas "localhost", pas un nom par défaut de l'hébergeur)
- Résoudre vers l'IP qui envoie l'email (enregistrement A)
- Rester le même d'une connexion à l'autre depuis cette IP
Le PTR de cette IP pointe de son côté vers un FQDN qui résout vers la même IP : c'est le FCrDNS (forward-confirmed reverse DNS).
# Mauvais
EHLO localhost
EHLO [192.0.2.1]
EHLO server1
# Bon
EHLO mail.captaindns.com
Spamhaus, novembre 2026. À partir de novembre 2026, Spamhaus déploie progressivement une exigence pour chaque IP d'envoi : un HELO valide, un reverse DNS (PTR) et un enregistrement A concordant. Une IP qui ne la respecte pas s'expose à un listing. Spamhaus ne publie ni jour précis ni calendrier. En IPv6, l'adresse d'envoi doit appartenir à un bloc /64 ou plus grand, doté d'un reverse DNS valide. Vérifiez dès maintenant le PTR et l'enregistrement A de chaque IP d'envoi avec les commandes dig ci-dessus, puis le nom annoncé en HELO dans les logs de votre serveur. Pour un contrôle concret, envoyez un message vers une boîte externe et lisez l'en-tête Received ajouté par le serveur destinataire : le nom qui suit from est en général celui que votre serveur annonce en HELO/EHLO. Selon le serveur destinataire, il apparaît plutôt entre parenthèses, après helo= ou HELO. L'analyseur d'en-têtes email présenté plus bas le montre. Si vos serveurs d'envoi sont aussi vos MX, le Testeur SMTP/MX signale un banner dont le nom ne correspond pas à celui du MX.
Diagnostic par fournisseur
Chaque fournisseur a ses spécificités. Voici comment diagnostiquer les problèmes pour les principaux.
Gmail
Outils de diagnostic :
- Google Postmaster Tools : réputation domaine et IP
- Headers Gmail : cherchez
X-Gm-SpametX-Gm-Phishy
Exigences Gmail 2024 :
| Critère | Volume <5 000/jour | Volume >5 000/jour |
|---|---|---|
| SPF ou DKIM | Obligatoire | Obligatoire |
| DMARC | Recommandé | Obligatoire |
| Taux plainte | <0,3% | <0,1% |
| TLS | Recommandé | Obligatoire |
| Désabonnement 1-clic | - | Obligatoire |
Codes d'erreur courants :
| Code | Signification | Action |
|---|---|---|
421 4.7.0 | Trop de connexions | Réduire le débit |
550 5.7.1 | Politique DMARC | Corriger SPF/DKIM |
550 5.7.26 | Échec authentification | Vérifier SPF, DKIM |
Outlook.com et Microsoft 365 : distinguer les diagnostics
Microsoft reçoit les emails par deux services distincts, qui ne réagissent pas toujours de la même façon. Outlook.com est la messagerie grand public (adresses outlook.com, hotmail.com, live.com, msn.com). Microsoft 365 héberge la messagerie d'entreprise, sous le domaine de chaque client. Le nom du serveur qui refuse, dans le rapport de non-remise (NDR), aide à savoir lequel répond : MailRoute décrit les serveurs Outlook.com en olc.protection.outlook.com, et le domaine Microsoft 365 testé par Spam Resource passait par un serveur en mail.protection.outlook.com.
Outils de diagnostic :
- SNDS (Smart Network Data Services) : réputation IP
- JMRP : feedback loop
Particularités Outlook :
- Utilise Spamhaus et des blacklists propriétaires
- Filtrage agressif des nouveaux domaines (<30 jours)
- Programme SNDS pour surveiller la réputation
Outlook.com (grand public)
La règle publiée par Microsoft vise les expéditeurs à fort volume. Un domaine qui envoie plus de 5 000 messages par jour vers Outlook.com doit passer SPF et DKIM, publier un enregistrement DMARC (au minimum p=none) et passer DMARC grâce à un SPF ou un DKIM aligné sur le domaine du From. L'annonce du site Postmaster d'Outlook.com fixe le départ au 5 mai 2025, avec d'abord un classement en indésirables puis des rejets ; le rejet associé est 550 5.7.515.
Le rejet rapporté a cette forme (MailRoute signale aussi une variante sans le code entre parenthèses) :
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
Dans le rapport de non-remise publié sur Microsoft Q&A le 6 novembre, ce refus arrive à l'intérieur d'un autre code. La ligne « Error Details » donne, données personnelles retirées par le modérateur :
Error: 550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records
Le rapport affiche 550 5.7.23 comme code de statut, sous le titre « SPF validation error ». Le texte d'aide qui l'accompagne parle uniquement de SPF : vérifier l'enregistrement, n'en publier qu'un, y inclure spf.protection.outlook.com. Le diagnostic détaillé se trouve après la flèche : c'est le 550 5.7.1 « Message lacks SPF/DKIM/DMARC Auth Records », que Hornblower409 rattache à l'AS9031519. Ce gabarit ne prouve pas que votre SPF est faux. Sur le même fil, Martin rapporte cette enveloppe en déclarant SPF, DKIM et DMARC corrects depuis des années.
Si vous recevez ce rejet, lisez et conservez d'abord le rapport complet : code extérieur, texte intérieur, serveur qui refuse et éventuel AS9031519. Cherchez ensuite l'enregistrement DMARC à _dmarc.<domaine>. Pour un sous-domaine, regardez aussi celui du domaine parent, dont la politique peut s'appliquer. Vous pouvez vérifier l'enregistrement DMARC publié sans ligne de commande. Une recherche DNS qui n'aboutit pas (délai dépassé, erreur du serveur) ne prouve pas l'absence d'enregistrement : recommencez avant de conclure. Ce contrôle montre ce qui est publié, pas le résultat SPF ou DKIM d'un message donné.
Si aucun enregistrement DMARC ne s'applique au domaine :
- Publiez un enregistrement TXT à
_dmarc.<domaine>de valeurv=DMARC1; p=none. Beaucoup d'hébergeurs DNS ajoutent le domaine eux-mêmes : saisissez alors_dmarcseul comme nom. Un domaine n'a qu'un enregistrement DMARC, n'en créez pas un second au même nom, et ne remplacez pas une politique plus stricte qui fonctionne déjà. - Vérifiez qu'au moins SPF ou DKIM passe et qu'il est aligné sur le domaine de l'adresse d'expéditeur affichée (From). Un enregistrement DMARC sans authentification alignée échoue quand même. Pour contrôler l'alignement, envoyez un message vers une autre boîte et lisez son en-tête
Authentication-Results(voir comment lire les en-têtes d'un email). - Attendez que les caches DNS expirent : les serveurs gardent quelque temps en mémoire l'ancien enregistrement, ou le fait qu'il n'en existait aucun. Pour un ancien enregistrement, ce délai est son TTL, fixé dans votre zone DNS. Si aucun enregistrement n'existait, la durée pendant laquelle les serveurs retiennent cette absence dépend de l'enregistrement SOA de votre zone (cache négatif, RFC 2308), pas du TTL du nouvel enregistrement. Renvoyez ensuite les messages refusés. Un 550 est un échec permanent, votre serveur ne retentera pas l'envoi.
L'ajout d'un p=none est rapporté comme contournement pour certains domaines sans DMARC (Hornblower409 et Cameron Scott sur le fil Microsoft Q&A), pas comme une réparation du service Microsoft. p=none ne demande ni quarantaine ni rejet au titre de la politique DMARC. Il ne garantit pas pour autant l'acceptation par Outlook.com, ni l'arrivée en boîte de réception.
Si SPF, DKIM et DMARC sont déjà corrects et que vos messages passent l'authentification :
- Ne réécrivez pas une configuration correcte pour répondre au seul texte du rapport. Ne publiez pas de second enregistrement SPF : deux enregistrements SPF provoquent un PermError (voir le guide SPF PermError). N'ajoutez pas non plus
include:spf.protection.outlook.comparce que le rapport le suggère : votre SPF doit autoriser les services qui envoient réellement pour votre domaine. - Gardez le rapport complet et les éléments techniques, puis signalez le rejet à Microsoft Sender Support. C'est la démarche que conseille Hornblower409 quand les messages refusés avec AS9031519 passent l'authentification.
- En entreprise, Daniel-Vo demandait le 9 novembre de fournir au support Microsoft 365 des Network Message IDs récents, les journaux des messages concernés et des exemples au format .eml. Ces éléments vont au support, pas dans un forum public.
- Réessayez plus tard, sans garantie de résultat. Les rejets sont rapportés comme intermittents, mais un 550 reste un échec permanent : votre serveur ne retentera pas l'envoi, c'est à vous de renvoyer le message.
Un pass obtenu sur un autre message, ou chez un autre destinataire, aide au diagnostic sans prouver le verdict du serveur Outlook.com qui a refusé le vôtre. Comme les rejets sont partiels, un renvoi accepté ne prouve pas non plus que la configuration est correcte, prévient MailRoute : contrôlez les enregistrements plutôt que le résultat d'un seul envoi.
Microsoft 365 (entreprise)
Microsoft 365 applique ses propres mécanismes de filtrage. Il ajoute un verdict propriétaire compauth dans l'en-tête Authentication-Results ; un compauth=fail augmente le risque de classement en indésirable (voir le guide compauth Microsoft 365). Lors du test d'Al Iverson (Spam Resource) du 7 novembre 2026, le message refusé vers outlook.com a été accepté vers le domaine Microsoft 365 testé. Ce test isolé ne montre pas que les destinataires hébergés sur Microsoft 365 sont à l'abri, ni qu'ils subissent le même incident. Des clients Microsoft 365 peuvent en revanche être touchés comme expéditeurs, quand ils écrivent vers Outlook.com : c'est à eux que s'adresse la demande de support de Daniel-Vo citée plus haut. Lisez toujours le texte complet du NDR.
Codes d'erreur Outlook.com et Microsoft 365
| Code | Signification | Action |
|---|---|---|
550 5.7.1 | Refus générique : lire le texte complet du NDR | Demander un delisting seulement si le texte désigne un blocage d'IP, en suivant la procédure qu'il indique |
550 5.7.1 avec « Message lacks SPF/DKIM/DMARC Auth Records » | Rejet Outlook.com rapporté depuis novembre 2026 pour des domaines sans DMARC, mais aussi pour des domaines dont l'authentification passe | Vérifier l'enregistrement DMARC et l'alignement SPF ou DKIM sans conclure à une défaillance sur le seul libellé. Sans DMARC : publier p=none puis renvoyer. Si tout passe : signaler à Microsoft Sender Support |
550 5.7.23, lorsqu'il accompagne le diagnostic AS9031519 | Enveloppe orientée SPF autour du refus 550 5.7.1 « Message lacks SPF/DKIM/DMARC Auth Records » (rapports publiés sur Microsoft Q&A, novembre 2026). Seul, ce code signale un échec SPF et ne prouve pas cet incident | Lire le diagnostic après la flèche avant de toucher au SPF, puis suivre la situation qui correspond (DMARC absent ou authentification déjà correcte) |
550 5.7.515 | Niveau d'authentification requis non atteint (expéditeurs à fort volume vers Outlook.com) | SPF et DKIM valides, DMARC publié, alignement sur le From |
550 5.7.606 | IP basse réputation | Consulter SNDS et suivre la procédure de delisting indiquée dans le NDR. Le refus vise l'IP : ne pas retirer les destinataires refusés |
421 4.7.0 | Limite de débit | Réduire les envois |
Yahoo / AOL
Outils de diagnostic :
- Yahoo Sender Hub : réputation et guidelines
- Complaint Feedback Loop : plaintes en temps réel
Exigences Yahoo 2024 :
| Critère | Requis |
|---|---|
| SPF | Obligatoire |
| DKIM | Obligatoire |
| DMARC | Obligatoire pour >5 000 emails/jour |
| Désabonnement 1-clic | Obligatoire |
| Taux plainte | <0,3% |
Plan d'action recommandé
Étape 1 : Diagnostic immédiat (30 minutes)
- Testez votre IP sur les blacklists majeures
- Vérifiez l'authentification (SPF, DKIM, DMARC) de votre domaine
- Analysez un email problématique via ses en-têtes avec l'analyseur d'en-têtes email
Si vos messages sont refusés plutôt que classés en spam, partez du texte exact du NDR avant toute demande de delisting. Un même code 550 5.7.1 recouvre plusieurs causes. « Message lacks SPF/DKIM/DMARC Auth Records » ne vise pas votre IP : vérifiez DMARC et l'alignement, sans conclure à leur défaillance sur le seul libellé. Des rejets sont aussi signalés avec une authentification en pass ; dans ce cas, suivez la procédure « authentification déjà correcte » de la section Outlook.com. Un delisting ne se justifie que si le texte désigne l'IP ou une liste de blocage.
Étape 2 : Corrections prioritaires (1-2 jours)
- Demandez le delisting si blacklisté (Spamhaus, Barracuda en priorité)
- Corrigez les erreurs d'authentification détectées
- Configurez le reverse DNS si manquant
Étape 3 : Amélioration continue (2-4 semaines)
- Inscrivez-vous aux feedback loops (Gmail, Outlook, Yahoo)
- Surveillez les taux de plainte (objectif <0,1%)
- Nettoyez vos listes : retirez les adresses inactives depuis plus de 6 mois et les hard bounces dont le refus porte sur l'adresse (utilisateur inconnu, boîte inexistante). Si le refus vise votre domaine, votre IP ou votre authentification, corrigez la cause et renvoyez, sans retirer le destinataire
- Mettez en place un monitoring régulier des blacklists
Étape 4 : Prévention long terme
- Double opt-in pour toutes les inscriptions
- Désabonnement facile (1-clic, en-tête List-Unsubscribe)
- Monitoring automatisé des blacklists et de la réputation
- Audit trimestriel de la configuration email
FAQ
Pourquoi mes emails arrivent en spam alors que j'ai configuré SPF et DKIM ?
SPF et DKIM ne suffisent pas seuls. Depuis 2024, Gmail et Yahoo exigent aussi DMARC des expéditeurs de masse. Chez Outlook.com, des rejets sont rapportés depuis début novembre 2026 pour des domaines sans DMARC, y compris à faible volume, mais aussi pour des domaines dont l'authentification passe ; le 9 novembre, un modérateur de Microsoft Q&A les rattachait à une dégradation de service (voir la question suivante). Vérifiez également que votre IP n'est pas sur une blacklist et que votre taux de plainte est inférieur à 0,1%. Un échec sur n'importe lequel de ces points peut déclencher le spam, même avec une authentification partielle.
Pourquoi Outlook.com rejette-t-il mes emails avec AS9031519 malgré SPF et DKIM valides ?
Deux situations sont rapportées depuis début novembre 2026. Des opérateurs (liste Mailop, MailRoute, Spam Resource) observent ce rejet sur des domaines sans enregistrement DMARC ; des participants du fil Microsoft Q&A « SPF Validation Error » le signalent aussi, de façon intermittente, avec SPF, DKIM et DMARC en pass. Le 9 novembre 2026, Daniel-Vo, présenté sur ce fil comme « Microsoft External Staff » et modérateur, décrivait un problème du service Exchange vers Outlook.com, Hotmail.com et Live.com, classé en « service degradation », dont la cause restait recherchée. Ce n'est ni une entrée Service Health ni une nouvelle règle publiée. Le rapport de non-remise peut afficher 550 5.7.23 et le titre « SPF validation error » : lisez le diagnostic après la flèche avant de toucher au SPF. S'il n'existe aucun DMARC applicable, publiez un TXT v=DMARC1; p=none à _dmarc.<domaine>, vérifiez que SPF ou DKIM passe et reste aligné sur le domaine du From, puis renvoyez les messages refusés : un 550 est définitif, votre serveur ne le retentera pas. p=none est un contournement rapporté, sans garantie d'acceptation. Si l'authentification passe déjà, ne réécrivez pas vos enregistrements : gardez le rapport complet et signalez le rejet à Microsoft Sender Support.
Comment savoir si mon IP est sur une blacklist ?
Utilisez un vérificateur de blacklist qui teste votre IP contre les principales listes (Spamhaus, Barracuda, SpamCop). Le test couvre 25+ blacklists simultanément et fournit les liens de delisting pour chaque liste concernée. Testez votre IP immédiatement si vos emails sont rejetés ou classés en spam.
Combien de temps faut-il pour sortir d'une blacklist ?
Les délais varient selon la blacklist : SpamCop se délist automatiquement en 24-48h sans nouveau report. Spamhaus traite les demandes manuelles en 24-48h. Barracuda répond en 12-24h. UCEProtect a un délai de 7 jours. Dans tous les cas, le problème à l'origine du listing doit être corrigé avant de demander le delisting.
Mes emails passent en spam uniquement chez Gmail, pourquoi ?
Gmail est particulièrement strict depuis février 2024. Vérifiez les points suivants : (1) DMARC est-il configuré avec au moins p=none ? (2) Le taux de plainte est-il sous 0,1% ? (3) Le désabonnement en 1-clic est-il implémenté pour les emails de masse ? Utilisez Google Postmaster Tools pour voir votre réputation domaine chez Gmail.
Comment améliorer mon taux de délivrabilité rapidement ?
Actions immédiates : (1) Vérifiez et corrigez votre authentification SPF/DKIM/DMARC. (2) Testez votre IP sur les blacklists et demandez le delisting si nécessaire. (3) Retirez de votre liste les hard bounces dont le refus porte sur l'adresse (utilisateur inconnu, boîte inexistante), ainsi que les inactifs de plus de 6 mois. Si le refus vise votre domaine, votre IP ou votre authentification, corrigez la cause et renvoyez avant de toucher à la liste. (4) Réduisez les envois vers les adresses qui n'ouvrent jamais. Ces actions peuvent améliorer la délivrabilité en 1-2 semaines.
Quel est le taux de plainte acceptable ?
Le seuil critique est 0,1% (1 plainte pour 1 000 emails). Au-delà, Gmail et Yahoo commencent à classer vos emails en spam. Google recommande de rester sous 0,05% pour une délivrabilité optimale. Surveillez ce taux via les feedback loops et Google Postmaster Tools.
Mon serveur mail est bien configuré mais mes emails passent toujours en spam ?
Si la configuration technique est correcte, le problème est probablement lié à : (1) La réputation de votre IP ou domaine (vérifiez les blacklists). (2) Le contenu de vos emails (mots déclencheurs, ratio image/texte). (3) L'engagement des destinataires (taux d'ouverture faible, plaintes). Analysez vos en-têtes pour identifier le facteur déclenchant.
Comment réchauffer une nouvelle IP pour l'envoi d'emails ?
Le réchauffement d'IP consiste à augmenter progressivement le volume d'envoi sur 4-6 semaines. Commencez par 50-100 emails/jour vers vos destinataires les plus engagés, puis doublez le volume chaque semaine. Surveillez les bounces et plaintes. Ne passez jamais de 0 à des milliers d'emails/jour sous peine de déclencher les filtres anti-spam.
Que change l'exigence HELO/PTR de Spamhaus de novembre 2026 ?
À partir de novembre 2026, Spamhaus déploie progressivement une exigence pour chaque IP d'envoi : un reverse DNS (PTR) qui pointe vers un FQDN, ce FQDN qui résout vers la même IP (enregistrement A), et un nom HELO/EHLO qui résout vers l'IP d'envoi et reste le même d'une connexion à l'autre. Selon Spamhaus, un reverse DNS absent ou discordant est l'une des raisons les plus courantes d'envisager le listing d'une IP. Spamhaus n'a publié ni jour précis ni calendrier : il s'agit d'un déploiement progressif, pas d'une coupure à date fixe. En IPv6, l'adresse d'envoi doit se trouver dans un bloc /64 ou plus grand, avec un reverse DNS valide.
Glossaire
- DNSBL (DNS-based Blackhole List) : Liste noire d'IPs consultable par requête DNS. Aussi appelée RBL (Realtime Blackhole List).
- SPF (Sender Policy Framework) : Record DNS listant les serveurs autorisés à envoyer des emails pour un domaine.
- DKIM (DomainKeys Identified Mail) : Signature cryptographique ajoutée aux emails pour prouver leur authenticité.
- DMARC (Domain-based Message Authentication, Reporting & Conformance) : Politique définissant le traitement des emails échouant SPF/DKIM.
- Hard bounce : Échec de livraison permanent (code 5xx). L'adresse peut ne pas exister, mais le refus peut aussi viser votre domaine ou votre authentification. Le serveur d'envoi ne retente pas : après correction, renvoyez le message. Avant de retirer une adresse de vos listes, vérifiez que le refus porte bien sur elle.
- Soft bounce : Email temporairement rejeté (boîte pleine, serveur indisponible).
- Feedback loop : Programme permettant aux expéditeurs de recevoir les signalements spam des destinataires.
- Reverse DNS (PTR) : Enregistrement DNS associant une adresse IP à un nom de domaine.
- FQDN (Fully Qualified Domain Name) : Nom de domaine complet (ex: mail.captaindns.com).
- Réputation IP : Score attribué à une adresse IP basé sur son historique d'envoi.
Guides blacklist connexes
- Comment retirer votre IP d'une blacklist : le guide complet du delisting : Procédures détaillées pour Spamhaus, Barracuda, SpamCop et plus
- Spamhaus vs Barracuda vs SpamCop : comparatif : Les 3 blacklists majeures décryptées
Sources
- Google Email Sender Guidelines (2024) (exigences officielles Gmail)
- Yahoo Sender Best Practices (guidelines Yahoo/AOL)
- Microsoft 365 Anti-Spam Protection (documentation Outlook)
- Microsoft Support - Fix NDR error 550 5.7.515 in Outlook.com (règle officielle des expéditeurs à fort volume vers Outlook.com)
- Outlook.com Postmaster (annonce des exigences pour les expéditeurs à fort volume, départ au 5 mai 2025, consultée le 8 novembre 2026)
- Spam Resource - Microsoft newly rejecting mail lacking DMARC? (7 novembre 2026) (observations et tests d'Al Iverson)
- Mailop - Microsoft requiring DMARC now or just us? (témoignages d'opérateurs, novembre 2026)
- MailRoute - 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (6 novembre 2026) (retour opérationnel d'un fournisseur de relais)
- Microsoft Q&A - SPF Validation Error (fil ouvert le 6 novembre 2026) (échange de support, pas une documentation normative : déclaration du 9 novembre 2026 de Daniel-Vo, Microsoft External Staff et modérateur, réponse du modérateur bénévole Hornblower409 et témoignages d'utilisateurs ; consulté le 10 novembre 2026)
- The Register - Outlook.com bounces legit emails as Microsoft's authentication crackdown goes sideways (9 novembre 2026) (article de presse)
- RFC 7489 - DMARC (spécification technique)
- Spamhaus - Understanding DNSBLs (fonctionnement des blacklists)
- Spamhaus Sender Guidelines (exigences HELO, PTR et A pour les IP d'envoi)
