Votre email n’est jamais arrivé. Le serveur a répondu 554 5.0.0 et c’est tout. Aucune explication. Juste un rejet permanent.
Le vrai problème avec cette erreur : elle est volontairement vague. Elle peut signifier cinq choses différentes. Pendant que vous cherchez laquelle, vos emails continuent de rebondir. Et chaque rebond dégrade un peu plus votre réputation d’expéditeur.
Ce que signifie vraiment le code 554 5.0.0
Le code SMTP 554 indique un rejet permanent. Le serveur destinataire a refusé votre message et ne le réessaiera pas. Le sous-code 5.0.0 est le plus générique qui soit : erreur permanente, point. Le serveur ne vous dit pas pourquoi.
C’est différent d’un code comme 554 5.7.1 (relais refusé) ou 554 5.7.5 (échec DMARC) qui pointent directement la cause. Avec le 5.0.0, vous devez diagnostiquer. La cause se trouve dans l’une de ces cinq zones, et l’ordre dans lequel vous les vérifiez change tout.
Les cinq causes à vérifier, dans l’ordre
La plupart des guides vous donnent sept actions à faire en parallèle. C’est une erreur. Corriger votre SPF avant de savoir si votre IP est blacklistée vous fait perdre une heure pour rien.
Commencez par la blacklist. C’est là que la plupart des équipes perdent du temps : elles modifient leur SPF alors que leur IP est blacklistée depuis trois semaines. MXToolbox ou MultiRBL vérifient en 30 secondes. Si vous apparaissez sur Spamhaus, Barracuda ou SORBS, le serveur destinataire a probablement rejeté votre message avant même d’en lire le contenu. Chaque liste a sa procédure de délisting : Spamhaus accepte les demandes via formulaire, Barracuda exige une vérification de domaine.
Si vous n’êtes pas blacklisté, vérifiez vos enregistrements d’authentification. SPF, DKIM et DMARC ne sont plus optionnels. Depuis début 2024, Google et Yahoo les imposent aux expéditeurs en volume. En novembre 2025, Gmail a franchi un cap : les messages non conformes ne sont plus filtrés vers le spam, ils sont activement rejetés. Un SPF mal configuré autorise des serveurs non prévus à envoyer en votre nom. DKIM manquant ? Le destinataire ne peut pas vérifier l’intégrité du message. Et si DMARC n’est pas publié, le serveur en face n’a aucune consigne sur quoi faire quand l’authentification échoue. Vérifiez vos DNS avec MXToolbox ou Google Admin Toolbox. Sur un serveur dédié ou un VPS, contrôlez aussi le reverse DNS (enregistrement PTR) : sans PTR valide pointant vers votre domaine, de nombreux serveurs rejettent la connexion avant même de vérifier SPF ou DKIM.
Si vous déployez DMARC pour la première fois, commencez par p=none pour collecter les rapports sans bloquer de messages. Une fois vos flux identifiés, passez à p=quarantine puis p=reject. Rester en p=none indéfiniment ne protège contre rien.
Troisième cause possible : le contenu. Certains serveurs rejettent en 554 des messages qui ressemblent à du spam, sans mentionner de blacklist. Les déclencheurs courants : liens raccourcis (bit.ly, tinyurl), pièces jointes exécutables, images sans texte, en-têtes malformés.
Quatrième cause possible : un problème de configuration SMTP entre votre client et votre serveur d’envoi. Mauvais port, chiffrement incorrect, authentification désactivée. Le tableau ci-dessous liste les paramètres de référence.
| Fournisseur | Serveur SMTP | Port | Chiffrement |
|---|---|---|---|
| Gmail | smtp.gmail.com | 587 | TLS |
| Outlook / Microsoft | smtp-mail.outlook.com | 587 | TLS |
| Yahoo Mail | smtp.mail.yahoo.com | 587 | TLS |
| OVH / LWS | ssl0.ovh.net | 465 | SSL |
Cinquième cas : le problème vient du destinataire. Boîte pleine, domaine expiré, enregistrements MX corrompus. L’erreur 554 5.0.0 ne vient pas toujours de vous. Envoyez à une adresse différente sur le même domaine. Si l’erreur se répète uniquement pour ce destinataire, le problème est chez lui.
Comment lire le message d’erreur complet
Le code 554 5.0.0 seul ne suffit pas. C’est le texte qui suit qui contient la vraie information.
Ouvrez le message de non-remise (NDR) reçu. Cherchez la ligne commençant par Remote server returned ou Diagnostic-Code. Vous y trouverez souvent un message plus explicite :
554 5.0.0 Service unavailable: problème de réputation ou de configuration serveur554 5.0.0 Message rejected: contenu ou politique de filtrage554 5.0.0 NXDomain: le domaine destinataire n’existe pas ou les MX sont invalides554 5.0.0 smtp; 5.1.2 Bad destination host: erreur DNS sur le domaine destinataire
Ce texte vous oriente vers la cause. Ne cherchez pas à corriger sans l’avoir lu.
Gmail, Outlook, Exchange : les différences à connaître
Gmail impose 500 emails par jour pour les comptes personnels et 2 000 pour Google Workspace. Au-delà, les envois sont bloqués. Gmail exige aussi que SPF, DKIM et DMARC soient configurés pour tout expéditeur envoyant plus de 5 000 messages par jour.
Outlook et Exchange Online appliquent des filtres basés sur la réputation IP. Un serveur qui envoie depuis une adresse sans historique positif sera suspect. Microsoft propose son outil Smart Network Data Services (SNDS) pour surveiller cette réputation en temps réel.
Sur Exchange on-premise, l’erreur 554 5.0.0 apparaît souvent quand le relais SMTP n’est pas autorisé pour l’adresse IP source. Vérifiez les connecteurs de réception dans Exchange Admin Center.
L’erreur que vous répétez sans le savoir
Voici ce que font la plupart des équipes quand elles voient un code 554 : elles modifient leurs DNS, attendent la propagation, réessaient, voient que ça ne fonctionne toujours pas, ajoutent une entrée SPF, attendent encore. Plusieurs heures perdues alors qu’elles étaient blacklistées depuis le début.
Le code 554 5.0.0 est un rejet permanent. Tant que la cause racine n’est pas identifiée, renvoyer le message ne sert à rien. Chaque tentative supplémentaire dégrade votre réputation d’expéditeur.
L’ordre compte. Blacklist d’abord (5 minutes). Authentification ensuite (15 à 30 minutes). Contenu et configuration en dernier.
Éviter le 554 5.0.0 à l’avenir
Nettoyez vos listes d’abord. Les adresses invalides génèrent des hard bounces qui dégradent la réputation. Un taux de rebond supérieur à 2 % déclenche des alertes chez la plupart des fournisseurs. Un outil comme CaptainVerify identifie les adresses invalides, les pièges à spam et les boîtes pleines avant l’envoi. Moins de rebonds, meilleure réputation.
Activez les boucles de rétroaction auprès des grands fournisseurs. Yahoo Postmaster et Google Postmaster Tools alertent dès que vos messages sont signalés comme spam. C’est gratuit. Ça évite de découvrir le problème trop tard.
Réchauffez les nouvelles IPs progressivement. Un serveur qui envoie 10 000 emails le premier jour sera suspect pour tous les fournisseurs, même si votre contenu est irréprochable.
Le 554 5.0.0 n’arrive pas par hasard. Il documente quelque chose. La question, c’est depuis combien de temps vous envoyez avec ce problème sans le savoir.
Attention à ne pas confondre avec l’erreur SMTP 550 5.7.1 : elle ressemble au 554 mais indique un refus de relais côté destinataire. Les causes et les corrections ne sont pas les mêmes. Si votre message d’erreur affiche 550, c’est un autre problème.
Questions fréquentes sur l’erreur SMTP 554 5.0.0
Quelle est la différence entre 554 5.0.0 et 554 5.7.1 ?
Le code 554 5.7.1 indique un refus de relais : votre serveur tente d’envoyer via un relais SMTP qui ne vous y autorise pas. Le 554 5.0.0 est plus générique et recouvre plusieurs causes. Les deux sont des rejets permanents mais 5.7.1 pointe directement le problème de relais.
L’erreur 554 5.0.0 vient-elle toujours de mon côté ?
Non. Si l’erreur contient NXDomain ou Bad destination host, le problème est chez le destinataire : domaine expiré, MX invalides. Testez avec un autre destinataire sur le même domaine pour confirmer.
Combien de temps faut-il pour sortir d’une blacklist ?
Cela dépend de la liste. Spamhaus peut prendre 24 à 48 heures après soumission d’une demande. Barracuda est souvent plus rapide. Certaines listes se mettent à jour automatiquement si votre IP cesse d’envoyer du spam pendant plusieurs jours.
Faut-il contacter le support du fournisseur destinataire ?
Si vous avez corrigé authentification, blacklist et configuration et que l’erreur persiste vers un même destinataire, oui. Gmail, Microsoft et Yahoo ont chacun un formulaire postmaster. Fournissez les en-têtes complets du message rejeté.
