Erreur 554 5.7.1 Relay Access Denied : ce que signifie ce refus SMTP
Ce message apparaît quand un serveur de messagerie refuse de transmettre (« relayer ») un e-mail vers son destinataire, parce qu’il ne reconnaît pas l’expéditeur comme autorisé à passer par lui. Le code 554 signale une erreur permanente côté serveur : contrairement à une erreur temporaire (4xx) qui pousse le système à réessayer plus tard, un 554 arrête l’envoi net, sans nouvelle tentative automatique. Le sous-code 5.7.1 précise la nature du refus : une politique de sécurité, pas un problème de contenu ou de destinataire invalide.
Concrètement, le message ne quitte jamais le serveur de départ. Sur un site WordPress, ce refus se manifeste de deux façons : soit un message d’erreur explicite renvoyé par le plugin d’envoi (WP Mail SMTP, Easy WP SMTP, ou le client mail utilisé pour tester la configuration), soit un échec totalement silencieux si rien ne relaie l’erreur jusqu’à l’interface — un formulaire de contact qui semble fonctionner mais dont aucun message n’arrive jamais, un symptôme proche de celui déjà couvert pour le formulaire de contact WordPress qui ne fonctionne pas, sauf qu’ici le blocage est confirmé côté serveur SMTP plutôt qu’hypothétique.
Pourquoi le serveur refuse de relayer ce message précis
Un serveur SMTP correctement sécurisé n’accepte de relayer un message que pour des expéditeurs qu’il peut vérifier : une adresse IP autorisée, un compte authentifié, ou un domaine d’envoi qu’il gère lui-même. Sans authentification SMTP (identifiant et mot de passe transmis à la connexion), le serveur traite la tentative d’envoi comme un usage potentiellement abusif — l’usage type d’un serveur de relais ouvert exploité pour du spam — et la bloque par défaut. La quasi-totalité des hébergeurs a fermé ce type de relais anonyme depuis plusieurs années : l’envoi authentifié est devenu la norme, pas une option de sécurité renforcée.
Le message d’erreur complet renvoyé par le serveur prend la forme 554 5.7.1 <adresse@domaine.fr>: Relay access denied, l’adresse mentionnée étant celle de l’expéditeur rejeté — un premier indice utile avant même d’ouvrir la configuration du plugin, puisqu’il confirme quelle adresse précise le serveur refuse de reconnaître comme légitime.
Trois situations distinctes produisent ce même code d’erreur, et les distinguer évite de perdre du temps à corriger la mauvaise cause.
Cas n°1 : authentification SMTP absente ou expirée
La cause la plus fréquente sur un site WordPress : le plugin d’envoi tente une connexion sans identifiants valides, ou avec un mot de passe d’application révoqué depuis un changement de sécurité côté hébergeur ou fournisseur de messagerie. Le port utilisé compte aussi : le port 25, historiquement destiné au relais entre serveurs, est bloqué par défaut pour l’envoi applicatif chez la majorité des hébergeurs mutualisés, précisément pour empêcher ce type d’abus ; les ports 587 (avec chiffrement STARTTLS) ou 465 (SSL/TLS direct) sont ceux à utiliser pour un envoi authentifié depuis un site ou une application.
Vérifier dans la configuration du plugin SMTP que le nom d’utilisateur correspond exactement à l’adresse d’envoi déclarée, que le mot de passe est à jour, et que le port choisi correspond au mode de chiffrement sélectionné (STARTTLS sur 587, SSL/TLS sur 465) résout la majorité des cas de cette catégorie.
Cas n°2 : enregistrements MX ou SPF encore pointés vers un ancien serveur
Après une migration vers un nouvel hébergeur ou un changement de serveur mail, les enregistrements DNS MX (qui déterminent quel serveur reçoit le courrier du domaine) et SPF (qui liste les serveurs autorisés à envoyer en son nom) mettent du temps à se propager. Tant que ces enregistrements pointent encore vers l’ancien serveur, le nouveau serveur de messagerie ne se reconnaît pas comme légitime pour ce domaine et refuse de relayer les messages envoyés en son nom, même avec des identifiants par ailleurs valides.
Un enregistrement SPF mal mis à jour après une migration produit exactement ce symptôme : la commande dig TXT votredomaine.fr (ou un outil de vérification DNS en ligne) permet de contrôler que l’enregistrement SPF actuel mentionne bien le nouveau serveur d’envoi, sous la forme include: suivi du domaine de l’hébergeur ou ip4: suivi de son adresse IP.
Le délai de propagation joue un rôle direct ici : tant que le TTL (durée de vie en cache) de l’ancien enregistrement SPF n’est pas écoulé chez tous les résolveurs DNS consultés par les serveurs destinataires, certains continueront à valider l’envoi selon l’ancienne règle, produisant des refus intermittents plutôt qu’un blocage systématique — un piège qui peut faire croire à une correction incomplète alors qu’il s’agit simplement d’un cache DNS pas encore renouvelé partout.
Cas n°3 : adresse d’expéditeur non autorisée par le domaine d’envoi
Un message envoyé avec une adresse « From » qui ne correspond pas au domaine ou au compte authentifié déclenche le même refus, même si l’authentification SMTP elle-même est correcte. C’est un cas fréquent quand un formulaire de contact WordPress utilise par défaut l’adresse de l’administrateur du site comme expéditeur (typiquement une adresse Gmail ou Outlook personnelle), alors que l’envoi transite par le serveur SMTP du nom de domaine professionnel : le serveur refuse de relayer un message qui prétend venir d’un domaine tiers qu’il ne gère pas.
La correction consiste à aligner l’adresse d’expéditeur configurée dans le plugin d’envoi avec le domaine réellement authentifié auprès du serveur SMTP — utiliser une adresse contact@votredomaine.fr plutôt qu’une adresse Gmail, en configurant si besoin un alias ou une adresse de réponse (Reply-To) distincte pour rediriger les réponses vers une boîte personnelle sans casser l’authentification d’envoi.
Diagnostiquer la configuration SMTP en quelques minutes
Avant de modifier quoi que ce soit, confirmer le diagnostic exact avec un test isolé du reste du site évite de corriger à l’aveugle. La plupart des plugins SMTP WordPress proposent un bouton d’envoi de test qui affiche le message d’erreur complet renvoyé par le serveur, y compris le code 554 et le sous-code 5.7.1 — une information nettement plus précise que celle visible par défaut dans l’interface d’administration. En dehors de WordPress, un outil de test SMTP en ligne de commande (swaks sous Linux, ou un client mail configuré manuellement) permet de reproduire l’échec en isolant chaque paramètre : port, chiffrement, identifiants, adresse d’expéditeur.
Croiser ce diagnostic avec les journaux du serveur mail, accessibles depuis le panneau d’hébergement (cPanel, Plesk, ou l’interface propriétaire de l’hébergeur) sous une section dédiée aux journaux de messagerie, confirme laquelle des trois causes précédentes correspond à la situation réelle plutôt que de tester les trois au hasard.
Éviter la récidive après une migration ou un changement d’hébergeur
Une migration de site ou de serveur mail est le déclencheur le plus courant de cette erreur, parce qu’elle touche simultanément l’authentification (nouveaux identifiants SMTP), les enregistrements DNS (MX, SPF) et parfois l’adresse d’expéditeur si le domaine change de gestionnaire de messagerie. Tester l’envoi de mail immédiatement après chaque étape d’une migration, plutôt qu’à la toute fin, permet d’isoler quel changement précis a cassé l’envoi au lieu de devoir remonter plusieurs jours de modifications.
Consigner la date et l’heure exactes de chaque bascule (changement de nameservers, mise à jour du plugin SMTP, activation du nouveau compte mail) facilite aussi le travail du support de l’hébergeur si le problème persiste au-delà de la propagation DNS attendue : un horodatage précis permet de croiser directement avec les journaux serveur plutôt que de décrire le symptôme de façon approximative.
Comparer les garanties d’assistance mail proposées par les hébergeurs avant de migrer reste utile pour limiter ce risque : le comparatif hébergement email professionnel détaille les critères techniques (authentification, limites d’envoi, support SPF/DKIM) à vérifier avant de choisir une offre, plutôt que de découvrir ces contraintes au moment d’un blocage d’envoi.