Objectif
Corriger un refus où un relais SMTP considère que l’identité d’expédition n’est pas autorisée pour le compte authentifié. La procédure compare le compte SMTP, l’adresse From visible et l’enveloppe MAIL FROM/Return-Path, vérifie les alias ou délégations, corrige les formulaires web et valide la réception sans élargir excessivement les droits d’envoi.
Prérequis
- Message complet 550/5.7.x avec heure du test.
- Adresse du compte SMTP utilisé pour AUTH.
- From configuré par l’application et éventuel Return-Path/envelope sender.
- Liste des alias, délégations ou adresses Send As autorisés chez le fournisseur.
- Accès aux réglages WordPress/plugin/application qui compose le message.
Procédure pas à pas
Relever les trois identités d’expédition
Notez le compte utilisé pour SMTP AUTH, l’en-tête From visible et l’enveloppe MAIL FROM. Dans beaucoup d’applications ces valeurs peuvent différer. Le diagnostic consiste d’abord à savoir laquelle est refusée par le serveur.
- Compte AUTH, From et MAIL FROM sont connus séparément.
Lire le texte du 550 et le moment du refus
Si le refus intervient à MAIL FROM, la politique concerne souvent l’enveloppe. S’il apparaît après DATA, le serveur peut comparer les en-têtes au compte authentifié. Conservez le sous-code et le hostname du relais afin d’appliquer la documentation du bon fournisseur.
- Le contrôle de politique est localisé dans la transaction SMTP.
Tester avec l’adresse exacte du compte SMTP
Configurez temporairement From et envelope sender avec l’adresse exacte du compte authentifié, puis envoyez un message minimal. Si ce test passe, le problème vient très probablement d’un alias ou d’une adresse non autorisée plutôt que du secret SMTP ou du réseau.
- Le test avec l’identité exacte du compte distingue authentification et autorisation d’expéditeur.
Vérifier les alias et droits Send As
Si l’application doit envoyer avec contact@domaine.fr alors que SMTP AUTH utilise site@domaine.fr, confirmez que contact@ est un alias ou une identité explicitement autorisée par le fournisseur. Un simple enregistrement DNS ou le fait de posséder le domaine ne donne pas automatiquement le droit d’émettre avec toutes les adresses.
- L’adresse From finale est autorisée pour le compte authentifié.
Corriger WordPress ou l’application
Dans WordPress, utilisez une adresse dédiée du domaine comme From et forcez-la si le plugin SMTP le permet. Dans les formulaires, placez l’adresse du visiteur dans Reply-To. Ainsi, les réponses humaines vont au visiteur sans demander au relais d’émettre comme user@gmail.com ou une adresse externe qu’il n’autorise pas.
- Les formulaires utilisent un From du domaine contrôlé et un Reply-To dynamique.
Vérifier le Return-Path ou MAIL FROM
Certains plugins ou bibliothèques modifient l’enveloppe indépendamment du From. Si le fournisseur impose aussi une correspondance sur MAIL FROM, activez l’option de Return-Path conforme ou laissez le relais appliquer son envelope sender supporté. Ne forcez pas une adresse externe.
- L’enveloppe d’envoi ne contredit pas la politique du relais.
Contrôler SPF, DKIM et DMARC après acceptation
Une fois le 550 corrigé, envoyez vers une boîte externe et vérifiez Authentication-Results. L’alignement de From avec une identité autorisée améliore souvent DKIM
Resolve-DnsName -Type TXT <DOMAINE>Resolve-DnsName -Type TXT _dmarc.<DOMAINE>- Le message reçu passe les contrôles attendus ou les écarts sont identifiés.
Tester plusieurs scénarios applicatifs
Testez formulaire de contact, reset de mot de passe, notification e-commerce ou autre fonction critique qui peut construire ses propres en-têtes. Un test SMTP du plugin ne garantit pas que toutes les extensions utilisent le même From. Inspectez les logs sans conserver inutilement le contenu des messages.
- Les principaux e-mails transactionnels partent avec l’identité autorisée.
Documenter le mapping final
Conservez le compte SMTP, l’adresse From autorisée, le Reply-To attendu et la source qui fournit le secret. Ne documentez pas le mot de passe lui-même. Si plusieurs sites utilisent le même compte, évaluez un compte dédié par application pour réduire l’impact d’une compromission.
- La configuration est reproductible sans exposer le secret.
Validation
La procédure est validée lorsque :
- Le compte SMTP authentifié et les adresses From/MAIL FROM sont cohérents ou explicitement autorisés.
- Le serveur n’émet plus l’erreur 550 Sender mismatch.
- Les formulaires placent les adresses visiteurs dans Reply-To plutôt que From.
- SPF/DKIM/DMARC du message reçu sont contrôlés après correction.
- Les différents types de notifications de l’application ont été testés.
Retour arrière
- Restaurer l’ancien From uniquement s’il était autorisé et fonctionnel.
- Supprimer une délégation/alias temporaire créée pour tester si elle n’est pas nécessaire à la configuration finale.
- Révoquer un secret SMTP temporaire généré pendant le diagnostic.
- Si le fournisseur refuse toujours l’alias, revenir à l’adresse exacte du compte SMTP jusqu’à validation de la délégation correcte.
Dépannage / erreurs fréquentes
- Test SMTP du plugin passe mais formulaire échoue : le formulaire écrase probablement From ou Reply-To.
- From est correct mais erreur persiste : vérifier envelope MAIL FROM/Return-Path.
- Alias existe mais refus continue : le fournisseur peut distinguer réception d’un alias et droit d’envoi Send As.
- Message accepté mais arrive en spam : passer au diagnostic SPF, DKIM, DMARC et réputation.
- Erreur seulement sur une application : comparer les en-têtes construits et le compte réellement utilisé par cette application.