Erreur 550 5.7.1 : ce que dit le rebond et comment la corriger

Un rebond 550 5.7.1 signifie que le serveur de réception a examiné votre message et a décidé de ne pas le prendre, en général à cause d'une règle de sécurité ou de politique. Cela ne veut pas dire que l'adresse email est morte ou supprimée. La plupart du temps, la boîte va bien. Le problème est que le même code couvre des cas très différents, d'un enregistrement SPF manquant à une liste de distribution qui n'accepte que le courrier interne. Le code seul ne vous dit donc pas quoi corriger. La ligne de texte qui le suit vous le dit, avec le nom du serveur qui a envoyé le rebond.

Lisez d'abord trois choses dans votre rebond

Ouvrez le rebond complet, pas seulement le résumé que montre votre plateforme d'envoi. Vous cherchez le code, le serveur qui a refusé le message et le texte après le code.

Un refus de Gmail ressemble à ceci dans le rebond brut :

Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [203.0.113.10] Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. - gsmtp

Dans cet extrait, le serveur qui a répondu figure sur la ligne Remote-MTA : gmail-smtp-in.l.google.com. Le code apparaît sur la ligne Diagnostic-Code sous la forme 550-5.7.1. Le texte après l'adresse IP dit que les filtres de Gmail ont jugé que le message ressemblait à du spam. La chaîne finale - gsmtp confirme que Gmail a produit le rebond. Si vous voyez à la place le marqueur gcdp, comme dans 550 5.7.1 This message violates example.com email policy. - gcdp <sessionid> - gsmtp, le refus vient d'une règle créée par l'administrateur Google Workspace du destinataire.

Le même code venant d'Outlook.com se lit très différemment :

Remote-MTA: dns; outlook-com.olc.protection.outlook.com
Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150).

Un hôte qui se termine par protection.outlook.com signifie que les serveurs de Microsoft ont refusé le message. Des noms comme outlook-com.olc.protection.outlook.com appartiennent à Outlook.com et Hotmail grand public, et non à l'installation Microsoft 365 d'une entreprise. Le code est le même que dans l'exemple Gmail, mais la cause est tout autre. S3150 signifie que l'adresse IP d'envoi, ou une partie de son réseau, est sur la liste de blocage de Microsoft. Cela n'a rien à voir avec l'adresse du destinataire.

Trouvez votre message 550 5.7.1 exact

Chaque système de messagerie formule son 550 5.7.1 à sa façon. Faites correspondre le texte de votre rebond à une ligne ci-dessous.

La version la plus vague est le texte brut de la RFC 3463, 550 5.7.1 Delivery not authorized, message refused (livraison non autorisée, message refusé), sans rien après. Certains serveurs gardent une raison courte exprès, pour que les spammeurs ne sachent pas ce qui a déclenché le filtre. Si vous envoyez par un relais ou un smarthost, vérifiez d'abord que votre application se connecte bien (SMTP AUTH) avant d'envoyer. Une connexion non authentifiée est une cause fréquente de votre côté. Si elle se connecte, demandez au destinataire de chercher le message dans ses propres journaux de messagerie. C'est en général le seul endroit où la vraie raison est enregistrée.

Si le problème est de votre côté

Si le rebond pointe vers l'authentification, la réputation ou le relais, vous pouvez corriger sans le destinataire. Vérifiez d'abord l'authentification. Une correction de réputation ne sert à rien tant que SPF ou DKIM échoue.

Gmail et Outlook.com refusent désormais directement une grande partie du courrier non authentifié. Commencez donc par le DNS. Votre domaine d'envoi a besoin d'enregistrements SPF, DKIM et DMARC (DKIM est souvent un CNAME fourni par votre fournisseur d'email). Vérifiez d'abord l'enregistrement SPF. Il doit lister chaque adresse IP de serveur et chaque service d'envoi qui transmet des messages en votre nom. La RFC 7208 limite chaque domaine à un seul enregistrement SPF et à dix requêtes DNS. Publier plusieurs enregistrements ou dépasser dix requêtes provoque automatiquement un échec PermError. Envoyez-vous ensuite un message de test et ouvrez les en-têtes. La vue « Afficher l'original » de Gmail indique SPF, DKIM et DMARC en PASS ou FAIL, ce qui est plus rapide que de lire les enregistrements DNS. L'enregistrement DMARC se trouve à _dmarc.votredomaine.com, et le domaine de votre adresse From doit correspondre au domaine qui a passé SPF ou DKIM.

Si l'authentification passe et que Gmail dit encore « likely unsolicited mail » (probablement du courrier non sollicité), le problème est en général la réputation, c'est-à-dire la façon dont les destinataires ont réagi à vos anciens emails. Google Postmaster Tools affiche votre taux de spam. Google demande aux expéditeurs de le garder sous 0,1 % et de ne jamais le laisser atteindre 0,3 %. S'il monte, mettez la campagne en pause au lieu d'envoyer plus de volume. Le courrier qui arrivait en spam a tendance à rebondir directement quand la réputation continue de baisser.

La qualité de la liste joue directement sur ce point. Les vieilles listes sont pleines de boîtes abandonnées, et certains fournisseurs transforment des adresses mortes depuis longtemps en spam traps. Les toucher, ou rebondir sur beaucoup d'adresses qui n'existent plus, dit aux filtres que vous ne gardez pas votre liste propre. Si la liste a plus de quelques mois, ou si elle vient d'un scraping ou d'un achat, vérifiez la liste avant d'envoyer (en anglais).

Les erreurs de relais sont un problème à part. Unable to relay ou Invalid credentials for relay [IP] signifie que le serveur par lequel vous envoyez ne reconnaît pas votre application comme autorisée à l'utiliser.

Si vous faites passer vos messages par le service de relais SMTP de Google Workspace, ouvrez la console Google Admin, allez dans Applications, sélectionnez Google Workspace, ouvrez Gmail et affichez Routage. Vérifiez la configuration du service de relais SMTP. Si vous vous authentifiez par adresse IP, confirmez que l'adresse IP de votre serveur figure dans la liste autorisée. Si vous vous authentifiez par identifiants, vérifiez que votre application se connecte sur le port 587 avec TLS et les bons identifiants de compte. Si vous envoyez par Microsoft 365, ouvrez le Centre d'administration Exchange et examinez vos connecteurs de flux de messagerie. Les applications et appareils qui envoient par Microsoft 365, comme un CRM ou un scanner de bureau, passent en général par un connecteur. Une mauvaise adresse IP ou un mauvais nom de certificat sur ce connecteur est une raison fréquente de 550 5.7.1 Unable to relay.

Si seul le destinataire peut corriger

Parfois, le blocage est voulu. Les entreprises sous Microsoft 365 ou Google Workspace fixent souvent des règles qui empêchent les expéditeurs externes d'atteindre certaines adresses.

Un cas courant est une liste de distribution comme all-staff@ qui n'accepte que le courrier venant de l'entreprise. Écrivez-lui depuis l'extérieur et Exchange Online vous renvoie un 550 5.7.1, qui nomme souvent le groupe. La page de dépannage de Microsoft indique que l'expéditeur ne peut en général pas corriger cela. Le propriétaire du groupe ou un administrateur Exchange doit modifier le groupe dans le Centre d'administration Microsoft 365 et ajouter votre adresse à la liste des expéditeurs autorisés.

Google Workspace fonctionne de la même façon. La chaîne gcdp dans un rebond Gmail signifie qu'un administrateur a créé une règle dans Google Admin qui a refusé votre message selon son contenu, ses pièces jointes ou le domaine de l'expéditeur. Rien de ce que vous changez de votre côté ne permettra de passer.

Dans ce cas, demandez au destinataire de transmettre le rebond à son équipe informatique. Donnez-lui l'adresse d'envoi, l'adresse du destinataire, l'heure du rebond et le rebond complet, par exemple :

Bonjour [Prénom], un email que je vous ai envoyé le [Date] à [Heure] m'est revenu avec une erreur de politique 550 5.7.1. Il semble qu'une règle de votre système de messagerie l'ait bloqué. Pourriez-vous transmettre les détails du rebond ci-dessous à votre équipe informatique, pour qu'elle autorise la livraison depuis mon adresse ?
Expéditeur : [Votre email]
Destinataire : [Son email]
Diagnostic : [Collez la ligne Diagnostic-Code]

Les codes que vous pouvez voir à côté de 550 5.7.1

Voici les codes d'erreur SMTP qui apparaissent le plus souvent dans le même rapport de rebonds. Certains signifient que l'adresse n'existe plus. D'autres signifient que l'adresse est bonne et que votre configuration doit être corrigée.

Pour la différence générale entre rebonds temporaires et permanents, consultez notre guide hard bounce et soft bounce. En pratique, retirez une adresse après un 550 5.1.1, mais gardez-la après un 550 5.7.26. Dans ce second cas, l'adresse est bonne et c'est votre authentification qui a échoué.

Le code 550 5.7.515 ne concerne que les gros expéditeurs. Depuis le 5 mai 2025, Microsoft refuse le courrier des domaines qui envoient 5 000 messages ou plus par jour vers des adresses Outlook.com, Hotmail et Live, sauf si SPF passe, DKIM passe et un enregistrement DMARC (p=none suffit) est aligné avec l'un des deux.

Vous verrez parfois ce code écrit 5.7.15 en ligne, mais c'est un autre code (priorité trop basse). Le rebond de Microsoft indique 5.7.515.

Questions fréquentes

Comment corriger le code d'erreur 550 5.7.1 ? Lisez la ligne de diagnostic de votre rebond pour voir si l'échec vient de l'authentification, de la réputation ou d'une règle côté destinataire. Si l'authentification a échoué, mettez à jour vos enregistrements SPF, DKIM et DMARC et vérifiez vos identifiants SMTP sortants. Si une règle de l'administrateur du destinataire ou un groupe restreint a causé le blocage, envoyez les en-têtes du rebond au destinataire pour que son équipe informatique autorise votre adresse.

Que signifie 550 5.7.1 unsolicited mail ? C'est Gmail qui vous dit que ses filtres considèrent votre message comme du spam, surtout à cause de votre réputation d'expéditeur. Les causes habituelles sont des destinataires qui marquent votre courrier comme spam, une hausse soudaine du volume depuis un nouveau domaine ou une nouvelle adresse IP, ou un envoi à une vieille liste. Vérifiez votre taux de spam dans Google Postmaster Tools et ralentissez jusqu'à ce qu'il repasse sous 0,1 %.

Que signifie le code d'état Outlook 5.7.1 ? Dans Microsoft 365, un 5.7.1 venant d'Outlook signifie en général qu'une règle Exchange ou une restriction de groupe a bloqué la livraison. Sur les comptes grand public Outlook.com et Hotmail, il contient souvent le code S3150. Ce code signifie que Microsoft a placé votre adresse IP d'envoi sur sa liste de blocage grand public. Si vous voyez S3150, contactez la personne qui gère votre serveur d'envoi et indiquez-lui le lien de dépannage présent dans le rebond.

Que signifie « 550 5.7.1 outbound relay not allowed » ? Cette erreur signifie qu'une application d'envoi a essayé de transmettre du courrier par un serveur SMTP sans fournir d'authentification valide. Les serveurs de messagerie refusent de relayer pour des expéditeurs non authentifiés, pour que les spammeurs ne puissent pas envoyer par eux. Pour corriger, configurez votre application pour qu'elle s'authentifie avec un nom d'utilisateur et un mot de passe valides, et une connexion TLS sur le port 587.

Quelle que soit la cause, gardez le rebond complet. C'est la première chose que demandera l'équipe informatique du destinataire ou votre fournisseur d'email.

Si la plupart de vos rebonds sont des 550 5.1.1 plutôt que des 5.7.1, c'est la liste qui pose problème. Il vaut alors la peine de la vérifier avec Giggal.ai (en anglais) avant le prochain envoi.