Objectif
Localiser précisément l’étape où un message est refusé et appliquer une correction adaptée au code et au texte retournés. La procédure distingue refus temporaire et permanent, authentification du client, politique d’expéditeur, destinataire, taille/contenu, DNS et réputation, sans modifier plusieurs paramètres au hasard.
Prérequis
- Bounce/NDR
- Expéditeur, destinataire et serveur/relais utilisé.
- Accès aux journaux de l’application ou de la plateforme d’envoi.
- Accès DNS pour contrôler MX, SPF, DKIM, DMARC et éventuellement PTR.
- Possibilité d’envoyer un message minimal de test.
Procédure pas à pas
Conserver le code et le dialogue exacts
Copiez le code enrichi et la phrase du serveur distant. RFC 5321 définit les codes de base, mais les fournisseurs ajoutent souvent un sous-code 5.x.x et un texte précis. Notez également la commande concernée : MAIL FROM, RCPT TO ou fin de DATA.
- Le refus est rattaché à une commande SMTP et à un serveur précis.
Identifier qui émet le refus
Déterminez si l’erreur provient du relais SMTP authentifié, de la passerelle antispam, du serveur MX destinataire ou d’une protection intermédiaire. Le hostname présent dans le NDR et les logs permet d’éviter de modifier le mauvais système.
- Le composant qui prend la décision est identifié.
Classer temporaire ou permanent
Un 421/450/451/452 oriente vers un incident temporaire, throttling ou ressource indisponible. Un 550/553/554 est généralement un refus permanent qu’il faut corriger avant retry. Respectez les délais automatiques du MTA pour les 4xx.
- Le plan d’action distingue attente contrôlée et correction obligatoire.
Vérifier connectivité, port et TLS
Si l’application n’atteint pas le relais, testez DNS et TCP. Pour un relais authentifié, confirmez 465/SSL implicite ou 587/STARTTLS selon la documentation du fournisseur. Pour un serveur MX, le transport inter-MTA utilise généralement TCP 25.
Resolve-DnsName <SMTP-HOST>Test-NetConnection <SMTP-HOST> -Port <PORT>openssl s_client -starttls smtp -connect <SMTP-HOST>:587 -servername <SMTP-HOST>- Le serveur est joignable et présente le TLS attendu.
Vérifier authentification et compte autorisé
Pour un rejet sur AUTH ou juste après MAIL FROM, confirmez que le compte, le secret, MFA/app password ou OAuth correspondent à la méthode supportée. Un mot de passe correct ne signifie pas que le compte a le droit d’émettre avec n’importe quelle adresse From.
- L’authentification réussit avec la méthode supportée par le fournisseur.
Comparer From, MAIL FROM et compte authentifié
Relevez l’adresse visible From, l’enveloppe MAIL FROM/Return-Path et le compte authentifié. Certains relais exigent que From soit le compte ou un alias/domaine explicitement autorisé. Un mismatch explique de nombreux 550 5.7.x.
- Les trois identités sont comprises et les délégations nécessaires existent.
Contrôler le destinataire et la politique locale
Si le rejet survient à RCPT TO, vérifiez adresse, domaine, existence de la mailbox, groupes, restrictions de réception et taille. Testez un autre destinataire du même domaine puis un domaine différent afin d’isoler une erreur de boîte d’une politique globale.
- Le problème est classé destinataire unique, domaine ou expéditeur global.
Contrôler DNS et authentification du domaine
Pour les rejets liés à spoofing ou réputation, vérifiez SPF, DKIM, DMARC et MX. Si vous exploitez votre propre MTA, contrôlez aussi PTR, HELO/EHLO et réputation de l’IP. Dans Microsoft 365, lisez Authentication-Results et Message Trace plutôt que de deviner l’authentification.
Resolve-DnsName -Type MX <DOMAINE>Resolve-DnsName -Type TXT <DOMAINE>Resolve-DnsName -Type TXT _dmarc.<DOMAINE>- La configuration DNS correspond à la source réelle d’envoi.
Envoyer un message minimal et comparer
Envoyez un e-mail texte sans pièce jointe vers une adresse de test. Si le message passe, ajoutez progressivement contenu, destinataire ou pièce jointe jusqu’à reproduire le refus. Cela permet d’isoler une politique de contenu ou de taille d’un problème d’identité.
- Le facteur déclencheur du rejet est reproduit de façon contrôlée.
Valider avec un code 250 et les logs
Après correction, vérifiez que le serveur accepte MAIL FROM, RCPT TO et la fin de DATA avec le résultat prévu, puis confirmez la livraison côté destinataire. Contrôlez aussi les en-têtes SPF/DKIM/DMARC si le problème touchait l’authentification du domaine.
- Le message de test est accepté et la correction ne crée pas de relais ou expéditeur trop permissif.
Validation
La procédure est validée lorsque :
- Le code, sous-code et serveur ayant refusé sont identifiés.
- La connectivité, TLS et authentification ont été testés séparément.
- From, MAIL FROM, compte authentifié et destinataire sont cohérents.
- DNS/authentification du domaine ont été vérifiés si le rejet l’exige.
- Un message minimal puis un message réel sont acceptés après correction.
Retour arrière
- Restaurer les paramètres SMTP précédents si une nouvelle configuration échoue.
- Retirer toute allow-list ou délégation temporaire créée pour le test.
- Révoquer les secrets temporaires ou app passwords non conservés.
- Pour un 4xx, revenir au retry normal du MTA plutôt que forcer des envois répétés.
Dépannage / erreurs fréquentes
- 550 mailbox unavailable : vérifier existence et politique destinataire, pas seulement l’authentification.
- 550/5.7.x sender rejected : vérifier compte authentifié, From et MAIL FROM.
- 554 après DATA : examiner contenu, réputation, SPF/DKIM/DMARC et politique antispam.
- TLS échoue : vérifier port/chiffrement, SNI/certificat et interception réseau.
- Fonctionne vers un domaine mais pas un autre : comparer le serveur distant, sa politique et la réputation perçue.