page · relais SMTP Google

Que doit évaluer une équipe produit avant de choisir le service de relais SMTP de Google ?

Ne choisissez le relais SMTP de Google Workspace que si son modèle d’administration, d’identité et de quotas correspond à la charge de travail. Confirmez qui détient le domaine Workspace et le paramètre de la console d’administration, si l’application peut utiliser une IP publique stable sur liste d’autorisation ou une authentification SMTP protégée par TLS, quels expéditeurs d’enveloppe sont autorisés et comment TLS est imposé. Modélisez les limites actuelles de Google par utilisateur, par client et par transaction avant le déploiement. Testez les erreurs temporaires et définitives, conservez les réponses SMTP, authentifiez l’expéditeur visible avec SPF, DKIM et DMARC, et traitez l’acceptation, la livraison au serveur destinataire et l’arrivée en boîte de réception comme des résultats distincts.

Commencer par l’adéquation à la charge de travail et à l’administration

Le service de relais SMTP de Google est une route d’administration Google Workspace destinée aux applications, appareils et serveurs de messagerie qui envoient via smtp-relay.gmail.com. Évaluez-le comme faisant partie du périmètre Workspace et de sécurité de la messagerie de l’organisation, et non comme un endpoint SMTP anonyme générique. Identifiez le super-administrateur Workspace responsable, les domaines du compte, les systèmes sources, les IP publiques de sortie, les adresses d’expéditeur, les catégories de messages, les volumes de destinataires en pointe et par jour, le profil des pièces jointes et le contact en cas d’incident. Déterminez si la charge de travail est transactionnelle, opérationnelle interne, rédigée par des utilisateurs, en masse avec abonnement ou générée par des appareils. Gardez ces catégories séparées, car les besoins en autorisation, consentement, suppression, audit et réputation diffèrent. Vérifiez que les environnements inférieurs ne peuvent pas utiliser les routes de production ni les adresses des clients. Un relais peut transporter un message autorisé ; il ne décide pas si l’événement métier est légitime, si un destinataire a donné son consentement ni si l’état de l’application doit avancer en aval.

Comparer l’autorisation par IP et l’authentification SMTP

La configuration actuelle de Google permet aux administrateurs de restreindre l’entrée du relais à des adresses IP publiques spécifiées, d’exiger une authentification SMTP sur TLS, ou de combiner ces choix de politique selon le paramètre documenté. L’autorisation par IP stable peut convenir à des centres de données maîtrisés ou à des passerelles de sortie fixes, mais elle devient fragile derrière un NAT cloud changeant, plusieurs régions, des services de basculement ou des réseaux tiers. L’authentification SMTP identifie un compte Workspace et un domaine d’envoi, mais introduit un cycle de vie des identifiants, une dépendance au statut de l’utilisateur, des interactions avec l’authentification multifacteur et les politiques, ainsi qu’une exigence stricte de TLS. N’utilisez jamais un même identifiant large pour plusieurs tenants ou des applications sans rapport. Pour chaque option, documentez qui peut ajouter une IP ou un compte, comment les changements sont examinés, comment une compromission est détectée, comment l’accès est révoqué et ce que fait le basculement. Gardez les plages d’IP autorisées aussi réduites que possible et vérifiez l’adresse publique de sortie depuis l’environnement d’exécution réel au lieu de copier une adresse interne.

Définir les expéditeurs autorisés et l’identité du domaine

Le paramètre de relais de la console d’administration contrôle les expéditeurs autorisés. Google documente des options liées aux utilisateurs Apps enregistrés et aux adresses des domaines détenus, ainsi qu’une option plus large, « n’importe quelle adresse », qui accroît l’exposition aux abus. Choisissez l’option la plus restreinte que la charge de travail permet. Inventoriez l’expéditeur de l’enveloppe SMTP indépendamment des champs From et Reply-To visibles. Google précise que lorsqu’un expéditeur est extérieur aux domaines du compte, SMTP AUTH ou un domaine présenté dans HELO ou EHLO peut influer sur la façon dont l’expéditeur de l’enveloppe est identifié ou réécrit. Ne comptez pas sur la réécriture pour remplacer un modèle d’expéditeurs détenus. Exigez une correspondance approuvée entre application, tenant, catégorie de message, expéditeur d’enveloppe, domaine From visible et return path. Bloquez les en-têtes arbitraires fournis par les utilisateurs, l’injection de sauts de ligne et les adresses From inter-tenants avant de vous connecter à Google. Testez l’acheminement des bounces et les messages d’absence, y compris avec un expéditeur d’enveloppe vide, sans assouplir l’ensemble du paramètre.

Exiger délibérément la sécurité du transport

Le guide actuel du relais de Google oriente les systèmes sur site compatibles TLS vers smtp-relay.gmail.com sur le port 587 et explique que l’authentification SMTP exige TLS. Le paramètre de la console d’administration peut aussi imposer TLS pour les connexions provenant du serveur d’envoi. Activez l’exigence TLS en production, sauf contrainte historique documentée faisant l’objet d’une exception limitée dans le temps. Validez le nom du serveur, la chaîne de certificats, la politique de protocoles et de suites de chiffrement prises en charge, la négociation STARTTLS et le comportement en cas d’échec. Le client doit échouer de façon sûre si le TLS requis ne peut pas être établi ; un repli silencieux vers le texte en clair annule la politique. Protégez les identifiants SMTP dans un magasin de secrets géré et tenez-les à l’écart des lignes de commande, des URL, du code source, des logs, des outils d’analyse, des rapports de plantage et des tickets. Le TLS de transport protège le saut vers Google, pas l’ensemble du cycle de vie du message ni la boîte aux lettres. Un contenu sensible peut nécessiter des contrôles au niveau applicatif, une minimisation des données, une politique de conservation et des décisions distinctes de chiffrement de bout en bout.

Modéliser les quotas actuels avant de choisir le relais

La documentation actuelle de configuration du relais SMTP de Google indique que chaque utilisateur peut envoyer jusqu’à 10 000 messages, à 10 000 destinataires uniques au maximum, sur une période de 24 heures, avec des limites éventuellement plus basses pendant l’essai. Elle documente aussi une limite de 100 destinataires par transaction SMTP ainsi que des contrôles supplémentaires par client, en pointe et par jour. Considérez-les comme des plafonds documentés à ce jour, pas comme un objectif de capacité ni un engagement permanent. Revérifiez la page officielle pour le compte et la charge de travail avant le lancement. Comptez les destinataires, pas seulement les messages, en incluant To, Cc, Bcc, les nouvelles tentatives et la diffusion multiple. Placez des contrôles applicatifs de débit, de concurrence, d’ancienneté de file d’attente et d’équité entre tenants en dessous des limites de Google. Déclenchez des alertes sur l’accélération et la marge restante. Ne réagissez pas à une limite en répartissant le trafic sur des comptes non autorisés, en faisant tourner les expéditeurs d’enveloppe ou en ouvrant des connexions non maîtrisées. Une charge de travail qui approche régulièrement d’une limite Workspace partagée peut nécessiter l’évaluation d’un transport dédié.

Construire un workflow de soumission fiable

Placez le client SMTP derrière un worker serveur autorisé ou une file d’attente. Persistez une tâche sortante unique avec une clé d’événement métier stable, le tenant, la catégorie de message, la révision du modèle, l’expéditeur et les destinataires approuvés, le fondement du consentement ou de la nécessité, la décision de suppression et l’historique des tentatives. Réclamez cette tâche une seule fois, générez et validez le contenu, puis connectez-vous à l’endpoint Google configuré. Limitez le nombre de destinataires par transaction et la taille des messages selon les limites actuelles et la politique du produit. Enregistrez la réponse SMTP complète, le code de statut étendu, l’hôte distant, l’horodatage et l’identifiant de tentative, sans journaliser les identifiants ni de contenu superflu. Si le relais accepte la transaction DATA, ne marquez que l’étape d’acceptation par le fournisseur ou le relais. Si le client atteint un timeout après l’envoi des données mais avant d’avoir reçu la réponse finale, laissez la tentative à l’état inconnu et effectuez un rapprochement avant de renvoyer. SMTP ne fournit pas de clé d’idempotence applicative : le contrôle des doublons relève donc de la file d’attente et du modèle d’événements du produit.

Classer les erreurs du relais au lieu de tout réessayer

La page des erreurs du relais SMTP de Google documente des situations distinctes, notamment le refus de relais, des identifiants de relais ou une identification de domaine invalides, le dépassement de la limite quotidienne, un report temporaire lié à la limite de pointe et un trop grand nombre de destinataires dans une seule transaction. Capturez la réponse exacte et associez-la à une catégorie interne précise. Corrigez les erreurs de configuration, de domaine d’expéditeur, d’identifiants, d’IP et de destinataires par transaction avant de rejouer. Suspendez ou replanifiez le travail une fois la limite quotidienne épuisée. Réessayez les erreurs temporaires de pointe ou de transport admissibles avec un backoff exponentiel, de la gigue, un nombre maximal de tentatives et des limites d’ancienneté de file d’attente. Ne réessayez jamais indéfiniment une réponse définitive. Si une erreur mentionne une IP non enregistrée, confirmez l’adresse de sortie publique réelle de l’environnement d’exécution et le bon paramètre Workspace au lieu d’élargir la liste d’autorisation. Conservez des comptages agrégés respectueux de la confidentialité par système source, révision de configuration, domaine d’expéditeur, catégorie de statut et période. Déclenchez des alertes sur les réponses inédites et les pics d’erreurs d’authentification, car ils peuvent signaler une dérive de politique, une révocation d’identifiants, un changement de NAT ou un abus.

Authentifier l’expéditeur au-delà de l’accès au relais

L’autorisation d’utiliser le relais de Google n’équivaut pas à l’authentification de l’expéditeur vis-à-vis des destinataires. Publiez une politique SPF qui autorise le chemin d’envoi réel pour l’identité de l’enveloppe, configurez la signature DKIM avec un domaine contrôlé par l’organisation et aligné pour DMARC, et publiez une politique DMARC relue pour le domaine From visible. Vérifiez le message brut reçu dans des boîtes externes contrôlées. Consignez le résultat et le domaine SPF, le résultat DKIM, le domaine d= et le sélecteur, le domaine From visible, l’alignement et le résultat DMARC. Une signature techniquement valide du fournisseur ou de Workspace peut rester non alignée avec un domaine From personnalisé. Le transfert peut aussi modifier les preuves SPF. N’ajoutez pas de second enregistrement SPF et n’affaiblissez pas DMARC pour toute l’organisation simplement pour faire réussir un test. Coordonnez les administrateurs DNS et de messagerie, conservez les enregistrements antérieurs, testez les réponses faisant autorité et récursives, et déployez un seul changement d’identité à la fois.

Exiger l’observabilité et une procédure de sortie testée

Utilisez la recherche dans les journaux d’e-mails de la console d’administration Google et les logs côté relais lorsqu’ils sont disponibles, mais gardez le registre des envois détenu par le produit comme système de référence pour les décisions. Surveillez l’ancienneté des files d’attente, l’acceptation, les réponses temporaires et définitives, l’utilisation des limites, les signaux de bounce et de plainte, l’authentification et la latence par catégorie de message et domaine d’expéditeur. Restreignez les accès et évitez les adresses complètes ou le contenu dans les métriques courantes. Testez les changements d’IP source, la rotation des identifiants, l’échec TLS, la désactivation du paramètre dans la console, la suspension d’un utilisateur, l’épuisement des limites, la diffusion à de nombreux destinataires, les changements DNS et une panne du fournisseur. Définissez un retour arrière capable de suspendre la cohorte concernée sans perdre de tâches persistées. Pour une migration, isolez les champs SMTP propres au fournisseur dans un seul adaptateur et conservez les clés d’événements métier, l’état des suppressions, l’autorisation des expéditeurs et l’historique des tentatives. Un second relais ne doit pas devenir un contournement automatique des rejets définitifs liés à la politique ou aux destinataires. La compatibilité exige des tests au niveau des champs et des erreurs, pas un simple changement de nom d’hôte.

Comment SendHQ s’intègre

SendHQ est une API e-mail limitée à l’espace de travail pour les communications produit attendues, avec l’envoi depuis un domaine vérifié, les e-mails entrants, les modèles hébergés, les événements de livraison, les suppressions et un tableau de bord web. Comparez-la au relais SMTP Google Workspace à l’aide de sa documentation actuelle et de tests contrôlés sur les limites de compte et de tenant, les identifiants et leur rotation, l’application des expéditeurs autorisés, les identités d’enveloppe et visibles, l’échec TLS, les limites de destinataires, les réponses temporaires et permanentes, les résultats ambigus, les suppressions, la lecture des événements et la migration.

Questions fréquentes

Quel nom d’hôte Google Workspace utilise-t-il pour le relais SMTP ?

Le guide de configuration actuel de Google utilise smtp-relay.gmail.com. Choisissez le port et le comportement TLS d’après les instructions officielles et la politique de sécurité imposée par l’organisation.

Peut-on restreindre le relais SMTP de Google par IP source ?

Oui. Le paramètre de la console d’administration peut n’accepter que des adresses IP publiques spécifiées. Gardez des plages étroites et vérifiez l’adresse de sortie réelle de l’environnement d’exécution ainsi que son comportement en cas de basculement.

L’authentification SMTP fonctionne-t-elle sans TLS sur ce relais ?

Le guide actuel de Google indique que l’authentification SMTP exige TLS. Les clients de production doivent échouer de façon sûre (fail closed) si la négociation TLS requise ou la validation du certificat n’aboutit pas.

Combien de destinataires une transaction du relais SMTP peut-elle contenir ?

Google documente actuellement une limite de 100 destinataires par transaction smtp-relay.gmail.com. Revérifiez la page officielle en vigueur, car les limites du fournisseur et les conditions du compte peuvent changer.

Faut-il réessayer après une erreur de limite de pointe du relais ?

Google décrit l’épuisement de la limite de pointe comme temporaire. Conservez la même tâche persistée et utilisez un backoff borné, de la gigue, un nombre maximal de tentatives et des limites d’ancienneté de file d’attente plutôt qu’une redistribution immédiate.

L’acceptation par le relais signifie-t-elle que le destinataire a reçu l’e-mail ?

Non. L’acceptation par le relais n’est qu’une étape du transport. L’acceptation par le serveur destinataire, un bounce ultérieur, le filtrage de la boîte, l’arrivée en boîte de réception et l’engagement humain restent des observations distinctes.

L’accès au relais Google peut-il remplacer SPF, DKIM et DMARC ?

Non. L’autorisation du relais contrôle l’utilisation du service de Google. L’authentification vis-à-vis des destinataires et l’alignement DMARC exigent des identités d’envoi, des enregistrements DNS et des signatures corrects, ainsi qu’une vérification des messages reçus.

Cette page prouve-t-elle que SendHQ est compatible avec le relais SMTP de Google ?

Non. Comparez les capacités documentées de SendHQ aux exigences de relais SMTP Google Workspace et utilisez des tests contrôlés pour l’authentification, TLS, les quotas, les erreurs et la lecture des événements de livraison.

Sources

Continuer à apprendre

Comment évaluer un service de relais SMTPÉvaluez les services de relais SMTP selon la sécurité de la soumission, l’authentification, les files d’attente, le comportement des nouvelles tentatives, les limites, les événements de livraison, la suppression, l’isolation et l’adéquation à une migration.Le protocole SMTP : comment circulent les e-mails applicatifsDécouvrez comment la soumission SMTP, le relais, les enveloppes, les codes de réponse, TLS, les nouvelles tentatives et le contenu des messages façonnent un workflow d’e-mails applicatifs.Ports SMTP 25, 465 et 587 : guide pratiqueChoisissez le bon port SMTP selon le rôle et le mode TLS, puis diagnostiquez les échecs de connexion, de handshake, d’authentification et d’acceptation des messages.Comment évaluer un service de délivrabilité e-mailÉvaluez les services de délivrabilité e-mail selon leur périmètre, leurs preuves, l’authentification, les boucles de rétroaction, les suppressions, la confidentialité, la portabilité et l’adéquation opérationnelle.API Gmail : guide d’implémentation pour les équipes produitImplémentez l’accès à l’API Gmail avec OAuth au moindre privilège, une synchronisation fiable des boîtes aux lettres, un envoi sûr, des nouvelles tentatives bornées et un modèle de compte de service clair.