Que faire si les e-mails de test Google Workspace SMTP Relay sont refusés en 2026 ?

Le code SMTP 250, renvoyé après réception complète du contenu du message, signifie que le serveur accepte celui-ci et prend en charge son traitement ultérieur ou le signalement d’un échec (RFC 5321). Il ne prouve pas que le message est visible dans la boîte cible. Pour diagnostiquer un e-mail de test Google Workspace SMTP Relay refusé, commencez donc par la réponse SMTP : si le relais refuse, vérifiez l’IP de sortie, l’expéditeur, l’authentification et l’identité HELO/EHLO ; s’il accepte, passez aux preuves de livraison et au classement côté destinataire. La conclusion d’un test doit venir d’une réception contrôlée.

Cet article s’adresse :

• aux développeurs qui testent l’envoi de notifications ou de messages de validation par leur propre application ;
• aux ingénieurs QA qui doivent produire une preuve réutilisable de réception en préproduction ;
• aux personnes responsables des hôtes d’envoi, des sorties réseau ou des règles de relais Workspace.

Séparez un refus du relais d’une absence dans la boîte

Ces deux symptômes ne se diagnostiquent pas de la même manière. Une réponse de refus pendant la session SMTP indique que le relais n’a pas accepté la soumission selon les conditions présentées. À l’inverse, lorsque le relais accepte le message, la cause de son absence visible peut se situer plus loin dans le parcours : traitement ultérieur, adresse destinataire erronée, classement dans une autre catégorie ou courrier indésirable.

L’interface de votre application n’est pas une preuve suffisante. Un message comme « envoi réussi » peut seulement indiquer que le code applicatif a terminé une étape, sans confirmer que le serveur a accepté le contenu. De même, une transaction SMTP acceptée ne confirme pas que le destinataire peut lire le message. Gardez ces étapes distinctes dans les rapports de test :

• Connexion : le programme atteint le service et obtient une réponse.
• Soumission SMTP : le message est transmis et le relais accepte ou refuse la demande.
• Traitement après acceptation : le message est pris en charge en vue de sa livraison ou un échec ultérieur est signalé.
• Réception contrôlée : le message est effectivement accessible à l’adresse prévue et permet de vérifier le parcours applicatif.

Pour une même exécution, conservez un identifiant de test ou un objet reconnaissable, l’adresse destinataire, l’heure de la tentative, la réponse SMTP et, si possible, la preuve côté destinataire. Retirez les données personnelles qui ne sont pas nécessaires avant de partager les journaux.

Quand le relais refuse, remontez de la réponse à la règle

Un message relay denied ne désigne pas à lui seul une cause unique. Il faut le rapprocher du contexte de la tentative et de la règle active du compte. Google documente les paramètres du relais, les méthodes d’identification et les erreurs courantes dans ses instructions de configuration du relais SMTP et sa documentation sur les erreurs SMTP de Gmail. Utilisez la réponse complète et ces références pour interpréter le cas, plutôt que de déduire la cause d’un message d’interface résumé.

L’adresse IP enregistrée ne correspond pas à la sortie réelle

Vérifiez l’IP publique avec laquelle l’environnement en échec établit réellement la connexion au relais. L’adresse d’un poste de développement peut différer de celle de la préproduction ; l’environnement d’intégration continue peut, lui aussi, emprunter une route ou une passerelle différente. Une règle correcte pour un environnement n’autorise pas nécessairement les autres.

Comparez donc la sortie réseau observée au moment du test avec l’adresse autorisée dans la règle Workspace concernée. Vérifiez également que vous examinez la règle du bon compte et du bon environnement. Si la réponse de Google fait référence à une IP non autorisée ou à une incompatibilité de domaine, notez précisément ce signal avant de modifier la configuration. Évitez d’ajouter une adresse supposée sans confirmer qu’elle correspond à la connexion fautive.

L’expéditeur ou le mode d’authentification ne correspond pas

Les règles de relais peuvent s’appuyer sur des conditions d’identification différentes. Selon la configuration retenue, le contrôle peut notamment dépendre d’une IP autorisée ou d’une authentification SMTP. Ne mélangez pas les prérequis : un secret configuré dans l’application ne remplace pas automatiquement l’autorisation de l’IP, et une IP autorisée ne signifie pas que chaque identité d’expéditeur est acceptée.

Comparez l’adresse From affichée au destinataire avec l’identité utilisée pendant la session SMTP et avec les types d’expéditeurs permis par la règle. Vérifiez aussi le domaine de l’adresse d’enveloppe MAIL FROM. Le nom présenté avec HELO ou EHLO doit être cohérent avec l’identité d’envoi attendue par votre configuration et interprétable dans ce contexte. Ne considérez pas un écart isolé comme une preuve de cause : rapprochez-le de la réponse SMTP et de la règle réellement appliquée. Les explications officielles des erreurs SMTP de Gmail aident à préciser le sens du retour observé.

La connexion ou la négociation TLS échoue avant la soumission

Une connexion TCP réussie ne signifie pas que le programme a envoyé le message. Dans les journaux, vérifiez le nom d’hôte utilisé — notamment smtp-relay.gmail.com si c’est celui qui figure dans votre configuration —, le port, l’échange de réponses SMTP et la négociation TLS ou STARTTLS prévue par l’environnement. Les options applicables doivent être confirmées dans la documentation Google en vigueur et dans les paramètres du compte ; ne transposez pas mécaniquement le résultat d’une machine à toutes les autres.

Distinguez les erreurs de résolution ou de réseau, les délais d’attente, les échecs de négociation TLS, les problèmes d’authentification et les refus de politique. Une relance peut fournir une observation supplémentaire, mais elle ne corrige pas une règle incohérente. Avant de relancer, enregistrez l’étape où la session échoue et la réponse reçue, si le serveur en a renvoyé une. Cela évite de transformer plusieurs causes différentes en un seul statut applicatif « échec d’envoi ».

Symptôme observé	Preuve à recueillir	Vérification prioritaire
Refus du relais pendant la session	Réponse SMTP complète et paramètres présentés	IP autorisée, expéditeur, méthode d’authentification et règle active
Connexion établie, mais aucun message soumis	Journal de connexion et progression du dialogue SMTP	Hôte, port, TLS/STARTTLS et réponse du serveur
Relais ayant accepté, boîte sans message visible	Réponse d’acceptation, adresse cible et traces de traitement	Adresse exacte, journaux accessibles, courrier indésirable et autres catégories
Message reçu, parcours applicatif inachevé	Message de test et résultat de l’application	Lien ou code de validation, traitement de la notification et état de la session

Quand le relais accepte, recherchez une preuve côté réception

Après une acceptation SMTP, ne concluez ni « livré » ni « reçu » sur la seule base de la réponse de l’application. Vérifiez d’abord que le destinataire utilisé lors de cette exécution est celui que l’équipe contrôle et que le marqueur du message permet de le retrouver. Une faute dans l’adresse, une variable d’environnement périmée ou une substitution incorrecte en préproduction peut faire tester une autre boîte que celle attendue.

Inspectez ensuite les emplacements accessibles au destinataire : boîte principale, courrier indésirable et catégories ou dossiers dans lesquels les règles de tri peuvent placer le message. Consultez les en-têtes et le contenu original si cela aide à identifier le message. Lorsque votre organisation dispose des droits nécessaires, la recherche dans les journaux d’e-mails Google peut compléter les éléments visibles dans la boîte. Pour les soupçons de classement ou de rejet lié au contenu, consultez également les recommandations Google sur les problèmes de courrier indésirable et d’abus associés au relais SMTP.

Dans un scénario concret, une équipe QA peut recevoir la réponse d’acceptation du relais, sans voir la notification de préproduction dans la boîte attendue. Avant de modifier le transport, elle compare l’adresse cible inscrite dans les journaux, recherche le marqueur unique dans la boîte contrôlée, puis vérifie les autres catégories et les journaux d’administration disponibles. Si le message est bien reçu mais que son lien de validation ne mène pas à l’état attendu, le problème est désormais dans le parcours applicatif, pas dans le fait que le relais a accepté l’envoi.

Pour garder cette enquête réutilisable, conservez une trace par tentative plutôt qu’une capture d’écran isolée. Les journaux doivent permettre de relier la réponse du relais à la bonne adresse et au bon contenu, sans exposer des données personnelles superflues. Pour cadrer ce qui est raisonnable de conserver dans un environnement de test, consultez aussi les limites de service et de réception et la notice de confidentialité.

Choisissez la méthode de réception selon ce que le test doit prouver

Le moyen de recevoir un message dépend du résultat attendu. Un test qui vérifie seulement que l’application a construit le contenu ne nécessite pas la même preuve qu’un test de validation de compte, où le message doit être lisible et le lien fonctionnel. Le tableau ci-dessous aide à choisir un dispositif pour votre propre produit ou un environnement autorisé.

Méthode de vérification	Ce qu’elle permet d’établir	Limite à garder en tête
Journaux applicatifs et réponse SMTP	Le code a tenté l’envoi et le relais a répondu	Ne prouve pas que la boîte cible affiche le message
Adresse de test contrôlée par l’équipe	Le message est consultable et son contenu peut être inspecté	Nécessite de contrôler la boîte et de relier le message à l’exécution
Journaux d’administration accessibles	Des éléments de traitement du message peuvent compléter la trace	L’accès et le niveau de détail dépendent des droits de l’organisation
Validation complète dans l’application	Le message, le lien ou la notification produisent le résultat attendu	Un échec peut venir de la logique applicative après réception

Pour vérifier une fonction d’inscription, une réinitialisation de mot de passe ou une notification, la boîte contrôlée est généralement l’élément qui ferme la boucle : elle permet de lire le message et de tester l’action attendue. Pour un simple contrôle de génération du contenu, les journaux peuvent suffire, à condition de ne pas présenter ce résultat comme une réception réelle.

Une procédure de diagnostic reproductible

Appliquez ces étapes à une seule tentative avant de changer plusieurs paramètres. Le but est de faire correspondre chaque conclusion à une preuve observable.

1. Reproduisez le test dans un environnement autorisé. Notez l’application, l’environnement, l’adresse destinataire contrôlée et le marqueur choisi. N’utilisez pas de données personnelles réelles si elles ne sont pas nécessaires.
2. Récupérez la réponse SMTP complète. Conservez les réponses du serveur et l’étape de la session où elles surviennent. Un statut simplifié provenant de l’application ne remplace pas ce journal.
3. Classez l’incident. Déterminez si la connexion échoue, si l’authentification ou la règle refuse l’envoi, si le relais accepte le message, ou si le message est reçu sans achever l’action applicative.
4. Si le relais refuse, comparez la configuration à la tentative. Confirmez l’IP publique de sortie, la règle du compte, le type d’expéditeur autorisé, la méthode d’authentification et les identités From, MAIL FROM et HELO/EHLO pertinentes.
5. Si la connexion échoue, examinez le transport. Vérifiez l’hôte configuré, le port et la négociation TLS/STARTTLS dans l’environnement concerné, en vous appuyant sur la configuration Google actuelle plutôt que sur une hypothèse issue d’un autre environnement.
6. Si le relais accepte, vérifiez le destinataire. Recherchez le marqueur dans la boîte contrôlée, puis examinez le courrier indésirable, les autres catégories et les traces d’administration auxquelles votre équipe a accès.
7. Confirmez le résultat métier. Ouvrez le lien ou suivez la notification dans le cadre du test, puis consignez séparément l’acceptation du relais, la réception lisible et la réussite du parcours applicatif.

Une fois la cause isolée, ne modifiez que le paramètre concerné, puis répétez le même scénario et comparez les preuves. Cette discipline aide à éviter les faux diagnostics : plusieurs changements simultanés peuvent faire disparaître le symptôme sans révéler quelle règle ou quelle étape était en cause.

FAQ sur les refus et la réception du relais

Que vérifier en premier quand le relais répond « relay denied » ?

Commencez par conserver la réponse SMTP complète et la tentative correspondante dans les journaux. Vérifiez ensuite que l’adresse IP publique réellement utilisée par l’environnement est autorisée, puis comparez l’expéditeur et le mode d’authentification avec la règle active. Ne modifiez pas plusieurs paramètres à la fois : une correction isolée permet de relier le résultat à sa cause.

Pourquoi une adresse IP enregistrée peut-elle encore être refusée ?

L’adresse enregistrée peut ne pas être celle qui sort réellement du réseau de développement, de préproduction ou de l’environnement d’intégration continue. Un changement de route réseau, une passerelle différente ou une règle Workspace différente peuvent aussi expliquer l’écart. Comparez l’IP observée dans l’environnement fautif avec la règle du compte concerné, puis vérifiez le message d’erreur exact.

Comment confirmer qu’un message accepté est arrivé dans la boîte de test ?

Associez l’envoi à une adresse de réception contrôlée et à un marqueur unique, puis vérifiez la boîte, ses catégories et les informations du message. Si votre organisation y a accès, consultez aussi la recherche dans les journaux d’e-mails pour suivre le traitement. Un accusé SMTP positif atteste l’acceptation par le relais, pas la lecture effective dans la boîte cible.

Comment distinguer une règle de relais incorrecte d’un classement en courrier indésirable ?

Un refus explicite pendant la session SMTP oriente vers la connexion, l’authentification ou la règle du relais. Si le relais accepte le message, recherchez plutôt les traces de traitement ultérieur et contrôlez la boîte, y compris le dossier de courrier indésirable et les autres catégories. Conservez la réponse SMTP et les preuves de réception séparément afin de ne pas confondre les étapes.

Pour fermer la boucle avec une réception contrôlée

Si le relais accepte un message mais que l’équipe ne peut pas confirmer sa réception, une adresse de test séparée peut faciliter l’inspection sans mêler ces essais à la boîte professionnelle. Pour des inscriptions, essais ou validations temporaires de votre propre produit, RelayTmp peut être une option de réception à considérer ; consultez ses informations et ses limites avant de l’intégrer au scénario. Les comptes qui exigent un suivi durable, une récupération ultérieure ou des échanges de réponse restent mieux servis par une adresse permanente. Pour choisir entre les deux usages, notre guide sur la différence entre adresse temporaire et adresse permanente permet de vérifier si une boîte temporaire convient au test prévu.

Questions fréquentes

Lancer un test propre

Ouvrir une boîte de réception jetable

Ouvrez une boîte e-mail temporaire copiable instantanément, puis actualisez-la et consultez de vrais e-mails de test sur la même page.

Ouvrir la boîte de réception