Erreur 550 5.7.1 : comprendre et résoudre le rejet

Pourquoi les e-mails sont-ils rejetés avec une erreur 550 5.7.1 ?

Une réponse 550 5.7.1 signifie qu’un serveur de messagerie a refusé un message pour une raison liée à une règle ou à une politique. Le code, à lui seul, ne précise pas la règle en question : un serveur peut signaler un échec d’authentification, tandis qu’un autre peut bloquer un expéditeur, une adresse ou le contenu du message. Pour comprendre que signifie l’erreur 550 5.7.1 dans votre cas, examinez le texte de diagnostic qui accompagne le code ainsi que le serveur qui l’a émis.

Si un rapport de remise indique seulement « message rejeté », recherchez la réponse SMTP complète dans le journal des événements de votre service d’envoi ou dans l’avis de non-remise. Pour mener une enquête utile, commencez par ces éléments, plutôt que par modifier les paramètres DNS ou demander au destinataire de vérifier son dossier de courriers indésirables.

Que signifie un rejet 550 5.7.1 lors d’un échange SMTP ?

Les serveurs SMTP échangent des codes d’état pendant le traitement d’un message. Le premier chiffre du code 550 indique un échec permanent : il est peu probable qu’une nouvelle tentative avec le même message aboutisse. Le code étendu 5.7.1 signale un problème de sécurité ou de politique, sans préciser la règle qui a été déclenchée.

Le texte qui suit le code est important. Par exemple, « expéditeur non autorisé » suggère un problème différent de « message rejeté en raison de la politique locale ». Ces formulations ne sont que des exemples et n’ont pas de définition universelle : les fournisseurs de messagerie rédigent leurs propres diagnostics, et une même formule peut avoir des significations différentes selon le système.

Considérez le code 550 5.7.1 comme une catégorie, et non comme un diagnostic. Si vous vous demandez pourquoi les e-mails sont rejetés avec une erreur 550 5.7.1, la réponse pratique est qu’un système destinataire a appliqué une règle. Vous devez consulter la réponse complète pour savoir laquelle.

Comment savoir si le message a été rejeté par le serveur du destinataire ou par une passerelle intermédiaire ?

Consultez la transcription SMTP ou le rapport de non-remise détaillé pour repérer l’hôte qui a renvoyé la réponse 550. Pour savoir comment lire un rapport de non-remise SMTP, repérez notamment le nom de l’hôte ayant rejeté le message, le code d’état et le texte du diagnostic. Le nom de l’hôte apparaît souvent à côté de la réponse, parfois sous la forme d’un nom de serveur ou d’une adresse IP. Comparez-le au domaine du destinataire et à tout service de sécurité de messagerie connu pour se trouver en amont de ce domaine.

Les e-mails destinés à un utilisateur peuvent transiter par une passerelle de filtrage avant d’arriver sur le serveur de sa boîte aux lettres. Si cette passerelle renvoie le rejet pendant l’échange SMTP, il se peut que le serveur de messagerie du destinataire ne voie jamais le message. Le rapport de non-remise peut nommer directement la passerelle ou indiquer un nom d’hôte que l’administrateur du destinataire devra confirmer.

Examinez la séquence des réponses du serveur au lieu de vous fier aux champs « De » ou « À » d’une notification. Par exemple, une transcription peut montrer votre système d’envoi se connectant à un hôte, lui transmettant les données du message, puis recevant une réponse 550 de cet hôte. Cette réponse identifie le système qui a pris la décision, même si un autre fournisseur gère la boîte de réception du destinataire.

Certaines plateformes d’envoi n’affichent qu’un bref résumé dans leur tableau de bord. Ouvrez les détails de l’événement ou téléchargez le rapport de non-remise brut, si cette option est disponible : les lignes supplémentaires peuvent révéler quel hôte a rejeté le message et à quel moment.

Pourquoi un message peut-il être rejeté après l’acceptation de la connexion par le serveur ?

L’acceptation d’une connexion SMTP signifie uniquement que le système destinataire a autorisé le début de la conversation. Cela ne signifie pas qu’il a approuvé l’expéditeur, le destinataire ou le message. Les vérifications des règles peuvent avoir lieu à plusieurs étapes : après la présentation de l’adresse de l’expéditeur, après la saisie de l’adresse du destinataire ou après la transmission du contenu du message.

Un serveur peut accepter la connexion, puis rejeter une adresse de destinataire particulière. Dans un autre cas, il peut accepter l’enveloppe, puis examiner le message après que le serveur expéditeur en a transmis le contenu. La réponse finale peut donc intervenir plus tard dans l’échange, même si la connexion initiale semblait normale.

Le moment où le rejet survient aide à orienter l’enquête. S’il apparaît avant l’envoi du corps du message, le problème peut concerner l’hôte expéditeur, l’identité de l’expéditeur ou une règle appliquée au destinataire. S’il apparaît après l’envoi du corps, le système a peut-être évalué le contenu ou l’ensemble des informations concernant l’expéditeur, le destinataire et le message. Le texte de la réponse reste l’indice essentiel.

Que faut-il vérifier dans le rapport de non-remise complet avant de modifier votre configuration de messagerie ?

Enregistrez le rapport de non-remise original avant de modifier les enregistrements DNS, de changer l’adresse d’expédition ou de renvoyer le message. Un rapport complet conserve une trace de la décision du système destinataire et facilite la comparaison avec les tentatives ultérieures. Vérifiez les éléments suivants :

• Code d’état étendu : Vérifiez si la réponse est 5.7.1 ou correspond à un autre code. Le résumé du rapport peut omettre le code précis renvoyé pendant l’échange SMTP.
• Texte du diagnostic : Copiez l’explication complète du serveur, y compris tout numéro de référence ou libellé de règle. Ne vous fiez pas à un message abrégé du tableau de bord.
• Hôte ayant rejeté le message : Notez le nom d’hôte ou l’adresse IP indiqués à côté de la réponse. Cela permet de déterminer si la décision vient du serveur du destinataire ou d’une passerelle de filtrage.
• Horodatage : Notez la date et l’heure, ainsi que le fuseau horaire s’il est indiqué. L’administrateur du destinataire pourra s’en servir pour rechercher l’événement dans les journaux de messagerie.
• Détails du message et du destinataire : Conservez l’identifiant du message, l’adresse de l’expéditeur, celle du destinataire et toute tentative de remise mentionnée. Ces éléments permettent d’identifier la transaction sans faire de suppositions.

Conservez le texte original dans son intégralité, même s’il contient des en-têtes techniques. Il peut être judicieux de masquer les informations personnelles sans rapport avec le problème avant de partager le rapport, mais supprimer l’hôte ayant rejeté le message ou la ligne de diagnostic peut rendre l’enquête beaucoup plus difficile.

Comment distinguer un blocage lié à une règle côté expéditeur d’une règle propre au destinataire ?

Comparez les résultats pour différents destinataires et domaines. Si plusieurs domaines sans lien entre eux rejettent le même message avec des formulations similaires, un problème côté expéditeur devient plus probable. Si une seule adresse ou une seule organisation le rejette alors que d’autres destinataires le reçoivent, il est plus probable qu’une règle locale ou une politique de passerelle soit en cause.

Ces tendances sont des indices, pas des preuves. La passerelle d’un destinataire peut appliquer une règle à tout un domaine expéditeur, ce qui peut toucher plusieurs personnes d’une même organisation. À l’inverse, un problème de configuration côté expéditeur peut sembler sélectif si seuls certains fournisseurs destinataires appliquent la règle concernée.

Recherchez dans le diagnostic les termes qui indiquent la portée de la règle, comme un expéditeur bloqué, un destinataire soumis à des restrictions ou une règle de sécurité locale. Effectuez ensuite un test contrôlé : envoyez le même type de message à un autre destinataire autorisé, sans modifier plusieurs paramètres à la fois. Si le message parvient à d’autres domaines, mais échoue systématiquement auprès d’une entreprise, transmettez les éléments recueillis à l’administrateur de sa messagerie.

Si le rejet mentionne l’authentification ou la politique du domaine, vérifiez les enregistrements du domaine d’envoi et leur alignement avant de demander une dérogation. Une liste de vérification ciblée, comme celle de ce guide de configuration de l’authentification des e-mails, peut vous aider à vérifier les enregistrements concernés. Elle ne permet toutefois pas d’affirmer que l’authentification est à l’origine de l’erreur 550, à moins que le rapport de non-remise ne le confirme.

Quelles informations transmettre à l’administrateur de messagerie du destinataire ?

Envoyez un compte rendu concis, mais suffisamment détaillé pour que l’administrateur puisse retrouver l’événement dans ses journaux. Joignez le rapport de non-remise complet ou la transcription SMTP, l’identifiant du message, les adresses de l’expéditeur et du destinataire, ainsi que l’heure approximative de l’envoi et son fuseau horaire. Ajoutez le nom d’hôte ayant rejeté le message et la ligne de diagnostic 550 5.7.1 exacte.

Décrivez ce qui s’est passé sans supposer la cause. Par exemple : « Un message envoyé à alex@example.com à 14:20 UTC a été rejeté par mx.example.net avec le code 550 5.7.1 ; le rapport de non-remise ci-joint contient la réponse complète. » L’administrateur dispose ainsi des éléments nécessaires pour effectuer une recherche, sans qu’une hypothèse non vérifiée soit présentée comme un fait.

Si le message a été envoyé par l’intermédiaire d’un fournisseur ou d’une application, indiquez le nom du service et, si possible, l’identifiant de l’événement de remise. Pour les e-mails transactionnels, le journal des événements peut aider à relier une action de l’application à la tentative SMTP ; les informations sur les webhooks d’e-mails transactionnels peuvent aider les équipes à conserver une trace de ces événements de remise pour les examiner ultérieurement.

Quand est-il pertinent de demander au destinataire d’ajouter un expéditeur à sa liste d’autorisation ?

Demandez si l’expéditeur peut être ajouté à une liste d’autorisation lorsque l’administrateur du destinataire confirme qu’une règle locale bloque un expéditeur légitime et peut préciser quelle identité d’expéditeur ou quel domaine doit bénéficier d’une exception. Fournissez le rapport de non-remise exact et indiquez l’adresse ou le domaine de l’expéditeur concerné. Il revient à l’administrateur de déterminer si une exception est compatible avec les règles de son organisation.

L’ajout à une liste d’autorisation ne résout pas tous les cas d’erreur 550 5.7.1. Si vous cherchez comment résoudre un rejet d’e-mail 550 5.7.1, commencez par suivre le diagnostic indiqué dans le rapport et déterminez quel serveur a rejeté le message. Si le rapport signale un problème d’authentification côté expéditeur, une adresse mal formée ou une violation plus générale des règles, une exception risque de masquer le symptôme sans corriger la cause. Ne demandez une exception locale que si l’administrateur de messagerie du destinataire confirme que sa propre politique est en cause.