Relais SMTP Google Workspace « 550 5.7.0 Mail relay denied » : la solution

Ce que ça veut dire

Le service de relais SMTP de Google Workspace (smtp-relay.gmail.com) permet à vos propres serveurs, applications et appareils d'envoyer des emails via Google. Google doit d'abord savoir que la connexion appartient à votre organisation Workspace. S'il ne parvient pas à rattacher la connexion à votre compte, il refuse avec un message qui ressemble généralement à ceci :

550-5.7.0 Mail relay denied [203.0.113.10]. Invalid credentials for
550-5.7.0 relay for one of the domains in: yourdomain.com (as obtained
550-5.7.0 from HELO and MAIL FROM). Email is being sent from a domain
550-5.7.0 or IP address which isn't registered in your Workspace account.
550-5.7.0 Please login to your Workspace account and verify that your
550-5.7.0 sending device is properly registered.

Google vous identifie de deux façons : par l'adresse IP de la connexion (si vous l'avez déclarée dans le réglage du relais), ou par une authentification SMTP avec un utilisateur Workspace. Il utilise ensuite le domaine présent dans le message d'accueil HELO/EHLO et dans l'expéditeur d'enveloppe (MAIL FROM) pour retrouver votre organisation.

Pourquoi cela arrive

• Le service de relais n'est pas configuré dans la console d'administration, ou la modification n'est pas encore appliquée (Google annonce jusqu'à 24 heures).
• L'IP ne correspond pas. Le réglage liste une IP, mais votre serveur sort par une autre : NAT, nouveau VPS, fournisseur cloud aux IP changeantes, ou IPv6 au lieu d'IPv4.
• Mauvais nom HELO. Le serveur annonce EHLO localhost ou un nom interne comme ip-10-0-0-5.ec2.internal, si bien que Google ne peut pas le rattacher à votre domaine. Voir nom d'hôte HELO/EHLO invalide.
• Le domaine de l'expéditeur n'est pas dans votre compte Workspace, par exemple une application qui envoie en tant que alerts@otherdomain.com.
• « Allowed senders » est trop strict : « Only registered Apps users in my domains » exige que l'expéditeur soit un utilisateur existant, donc noreply@yourdomain.com sans boîte mail échoue.
• Authentification exigée mais non envoyée, ou envoyée sans TLS.

C'est différent d'un utilisateur normal qui se connecte à smtp.gmail.com ; pour ces erreurs de connexion, voir Gmail SMTP « 535-5.7.8 Username and Password not accepted ».

Comment vérifier

1. Trouvez la vraie IP publique du serveur d'envoi, depuis le serveur lui-même :

   curl -4 https://ifconfig.me
   curl -6 https://ifconfig.me

   Si la seconde commande renvoie une adresse, votre serveur se connecte peut-être à Google en IPv6.
2. Regardez le nom HELO et l'échange avec Google :

   swaks --server smtp-relay.gmail.com:587 --tls \
     --ehlo mail.yourdomain.com \
     --from app@yourdomain.com --to you@example.com

3. Dans la console d'administration, allez dans Apps > Google Workspace > Gmail > Routing et ouvrez le réglage SMTP relay service. Comparez la liste d'IP, les expéditeurs autorisés et les options d'authentification avec ce que vous avez trouvé.
4. Vérifiez l'IP d'envoi sur les listes noires avec Delivmail et cherchez son propriétaire avec whois si vous n'êtes pas sûr du réseau auquel elle appartient.

Comment corriger

1. Configurez le réglage du relais (au niveau de l'organisation principale, droits d'administration des réglages Gmail nécessaires) :
   • Allowed senders : « Only addresses in my domains » convient à la plupart des applications et appareils ; il n'exige pas de boîte mail pour chaque adresse. Évitez « Any addresses ».
   • Authentication : cochez « Only accept mail from the specified IP addresses » et ajoutez l'IP publique de votre serveur (gardez une plage réduite), et/ou « Require SMTP Authentication ».
   • Cochez « Require TLS encryption » si votre serveur gère TLS.
2. Utilisez un vrai nom HELO appartenant à l'un de vos domaines Workspace. Exemple pour Postfix :

   relayhost = [smtp-relay.gmail.com]:587
   smtp_helo_name = mail.yourdomain.com
   smtp_tls_security_level = encrypt
   # force IPv4 if only an IPv4 address is registered
   smtp_address_preference = ipv4

3. Ou authentifiez-vous avec un utilisateur Workspace en TLS (port 587 avec STARTTLS ou 465). Dans ce cas, les identifiants de l'utilisateur identifient votre domaine. Le compte doit disposer d'un moyen de connexion valide (les règles OAuth ou mot de passe d'application s'appliquent comme pour le SMTP normal).
4. Utilisez un expéditeur de vos domaines : réglez l'expéditeur d'enveloppe et le From sur une adresse d'un domaine présent dans votre compte Workspace. Si vous devez envoyer pour un autre domaine, ajoutez-le à Workspace comme domaine secondaire ou domaine alias.
5. Attendez que la modification s'applique, puis réessayez.

Le relais via Google ne signe pas avec votre DKIM, sauf si le DKIM est activé pour le domaine dans Workspace ; voir SPF, DKIM et DMARC pour Google Workspace. Votre SPF doit aussi inclure _spf.google.com.

Vérifier que c'est corrigé

Envoyez un message via le relais à l'adresse unique de la page d'accueil de Delivmail. S'il arrive, le relais vous a accepté. Dans le rapport, le SPF doit passer pour les serveurs de Google, le DKIM doit être signé avec votre domaine et le DMARC doit passer. Renvoyez ensuite le message d'origine. Si vous recevez encore un refus, mais qui parle cette fois de limites du relais, vous avez dépassé cette erreur et atteint un quota.