Erreur SMTP 550 5.7.1 : trouver la cause du rejet

L’erreur SMTP 550 5.7.1 ne suffit pas à conclure que votre adresse IP a mauvaise réputation. Le serveur destinataire a refusé le message, mais la raison exploitable se trouve dans le texte complet du rejet et dans le trajet de l’envoi. Demander un retrait de liste avant d’identifier ce serveur peut vous faire traiter le mauvais problème.

Le diagnostic ci-dessous part d’un avis de non-remise et aboutit à un test de correction. Il convient aux équipes qui gèrent leur propre serveur comme à celles qui utilisent un prestataire : dans ce second cas, certaines traces devront être demandées au support.

Lire l’avis complet et retrouver l’envoi

Conservez le message de non-remise original, souvent appelé NDR ou DSN. Relevez l’heure, le destinataire concerné, le serveur qui a refusé, le diagnostic SMTP complet et l’identifiant de l’envoi dans votre plateforme. Plusieurs destinataires d’un même message peuvent avoir reçu des résultats différents.

Ne confondez pas le serveur qui vous remet l’avis d’échec avec celui qui a pris la décision. Le premier peut simplement retransmettre le refus du second. Dans le journal sortant, recherchez la tentative correspondante et l’adresse IP effectivement utilisée. Une machine possède parfois plusieurs sorties, notamment après une migration ou via un pool partagé.

La documentation Microsoft consacrée à 550 5.7.1 présente plusieurs causes, dont des restrictions de réception et des problèmes de routage ou d’autorisation. Ce code sert donc de point d’entrée au diagnostic, sans désigner à lui seul une liste de blocage.

Construire une ligne d’incident exploitable

L’exemple suivant est fictif. Les domaines et l’adresse IP sont réservés à la documentation ; le texte illustre un journal simplifié et n’est pas un code propre à un fournisseur.

heure : 2026-09-29T08:20:00Z
application : facturation
id_envoi : TEST-204
sortie_smtp : 192.0.2.52
destination : comptabilite@client.example
serveur_rejet : mx.client.example
phase : fin de DATA
diagnostic : 550 5.7.1 Message refused by recipient policy

Cette ligne permet de demander une vérification précise : « pouvez-vous retrouver TEST-204 vers cette boîte à cette heure ? ». Elle ne justifie pas encore « notre IP est blacklistée ». L’administrateur destinataire peut reconnaître une règle sur les pièces jointes ou un expéditeur interdit, tandis que votre fournisseur vérifie la sortie réelle.

Ajoutez à cette ligne la dernière réussite connue, le premier échec et les modifications intervenues entre les deux. Un changement de plateforme, de domaine de retour ou de modèle de facture devient alors une hypothèse testable. Une liste de changements datés vaut mieux qu’une série d’essais improvisés.

Orienter l’enquête avec le texte du refus

Cette table organise les recherches ; elle ne remplace pas la terminologie du fournisseur. Google publie par exemple plusieurs diagnostics associés à 550 5.7.1, avec des motifs différents, dans sa liste des erreurs SMTP Gmail. Conservez la phrase qui accompagne le code au lieu de la supprimer dans le ticket.

Vérifiez aussi l’étendue de l’incident. Une seule adresse touchée oriente vers une restriction locale. Plusieurs destinataires d’un même domaine orientent vers sa passerelle ou sa politique. Plusieurs domaines touchés par une seule application orientent vers son trajet d’envoi. Ces observations priorisent les tests, mais ne constituent pas une preuve définitive.

Séparer l’authentification de la réputation

Pour l’authentification, travaillez sur un message récent du même flux, avec les mêmes paramètres, reçu par une boîte de test que vous contrôlez. Relevez les domaines évalués, pas seulement les mots pass ou fail. Un service marketing et votre messagerie bureautique peuvent utiliser des identités différentes malgré un nom visible identique.

Le guide SPF, DKIM et DMARC donne les repères nécessaires. Comparez ensuite la configuration attendue par le prestataire et le DNS publié. Évitez de modifier simultanément plusieurs domaines ou de retirer une protection pour voir si « cela passe » : vous perdriez la relation entre changement et résultat.

Pour la réputation, recherchez l’indicateur exact mentionné dans le refus. Une réputation de domaine web et une réputation d’IP SMTP ne décrivent pas nécessairement le même risque. Le guide de réputation e-mail aide à distinguer les objets examinés. Une source externe peut apporter du contexte sans connaître la politique privée du destinataire.

Si votre IP est partagée, demandez au prestataire de confirmer sa responsabilité et l’action prévue. Si vous contrôlez cette IP, cherchez d’abord une activité d’envoi inattendue : compte compromis, application détournée, file d’attente inhabituelle ou ancien service encore actif. Un retrait de liste ne corrige pas la cause qui a déclenché le signal.

Tester une correction, une variable à la fois

Préparez un essai limité avec un destinataire volontaire. Utilisez le même flux que celui en échec et un contenu reconnu comme attendu. Notez exactement ce qui a changé : connecteur corrigé, signature activée, destinataire autorisé ou problème de réputation traité.

Conservez le nouvel identifiant d’envoi, le résultat SMTP et, en cas de réception, les en-têtes du message arrivé. L’acceptation par un relais intermédiaire n’établit pas à elle seule la présence dans la boîte de réception. Vérifiez également si le message a été classé en courrier indésirable ou en quarantaine.

Ne relancez pas toute la file sur la base d’un seul résultat ambigu. Déterminez quels messages ont réellement échoué et lesquels ont déjà été délivrés. Un rejeu doit éviter les doubles factures, doubles notifications ou demandes de validation répétées.

Préparer l’escalade lorsque la cause reste opaque

Un ticket utile contient le diagnostic intégral, les heures avec fuseau, les identifiants de trace, la sortie SMTP et un exemple représentatif expurgé des données inutiles. Indiquez les domaines touchés, les réussites comparables et le test réalisé. Demandez la règle ou la catégorie précise à l’origine du refus.

La clôture doit nommer la cause démontrée et la preuve de rétablissement. Si la passerelle destinataire conserve un motif privé, écrivez cette limite et le résultat de ses vérifications. Pour examiner le contexte public de l’indicateur cité, ouvrez un rapport IP ou domaine. Utilisez-le dans l’escalade comme un élément daté, sans promettre qu’un score favorable fera accepter les prochains messages.