Paramètres SMTP Gmail : ports, auth et alignement

Quelle méthode choisir ?

Utilisez les trois méthodes ainsi :

• Service de relais SMTP (recommandé) : utilisez smtp-relay.gmail.com sur le port 25, 465 ou 587. Google authentifie les messages par IP : l’administrateur doit configurer la politique de relais et peut avoir besoin d’une IP publique statique. Choisissez-le pour des appareils ou applications gérés qui envoient dans et hors de l’organisation. Google documente jusqu’à 10,000 destinataires par utilisateur et par jour.
• Serveur SMTP Gmail : utilisez smtp.gmail.com avec TLS sur le port 587 ou SSL sur le port 465, puis connectez-vous avec l’adresse Gmail ou Google Workspace complète et un identifiant approuvé par le compte. Choisissez-le si une application envoie comme une seule boîte. Google documente une limite de 2,000 messages par jour.
• Serveur SMTP Gmail restreint : utilisez aspmx.l.google.com sur le port 25. Il n’exige ni authentification SMTP ni TLS, mais n’envoie qu’à des destinataires Gmail ou Google Workspace. Google demande aux administrateurs de vérifier l’IP de l’appareil ou de l’application et de l’ajouter à la liste d’autorisation. Réservez-le aux anciens appareils incapables de suivre l’authentification ou le TLS des autres méthodes, sans autres destinataires à joindre.

Ces réglages et limites viennent de l’aide Google Workspace Admin. Ne changez pas d’hôte en gardant les mêmes hypothèses d’authentification, de destinataires et de politique.

La documentation actuelle de Google sépare les choix et leurs valeurs.

Choisissez la méthode selon le compte et le mode d’envoi, pas selon le seul port.

Si le logiciel prend en charge un flux OAuth Google actuel, suivez les instructions officielles d’intégration Google du produit au lieu de convertir un exemple de mot de passe d’application en paramètres OAuth. Clients OAuth, scopes, consentements et jetons sont propres au compte et sortent d’un simple tableau hôte-port.

Configurer le serveur SMTP Gmail

1. Identité et portée du test

Utilisez une boîte contrôlée et une seule adresse From visible. Par exemple, supposons que l’application envoie depuis alerts@example.com, s’authentifie en tant que alerts@example.com, envoie moins de 300 avis transactionnels par jour, et livre un test à un destinataire Gmail et un autre à une boîte contrôlée par l’organisation. Ne commencez pas par une liste de diffusion de production.

2. Saisissez l’hôte et le transport

Pour une soumission authentifiée, saisissez l’hôte smtp.gmail.com, le port 587 et STARTTLS ou le réglage équivalent de passage à TLS du client. Si le client exige le SSL implicite, utilisez le port 465. Exigez l’authentification et saisissez l’adresse complète du compte comme nom d’utilisateur. N’utilisez pas le port 25 pour cet exemple de soumission authentifiée.

3. Utilisez un identifiant approuvé

Suivez la politique d’authentification actuelle du compte. Si Google et l’application acceptent explicitement un mot de passe d’application, créez-le pour elle après activation de la validation en 2 étapes et gardez-le secret. Ne collez jamais votre mot de passe Google dans un appareil non compatible, et ne mettez pas de mot de passe d’application dans un dépôt ni sur une capture. Si la politique bloque la méthode, passez à une intégration ou un relais compatible.

4. Autorisez l’expéditeur visible

Gardez la même boîte authentifiée et la même adresse From visible pour le premier test. Une autre identité From peut exiger un alias vérifié, une délégation, une politique de relais ou une autorisation propre à l’application. Un succès d’authentification 235 ou une acceptation SMTP 250 n’accorde pas le droit Send As pour un domaine quelconque.

5. Envoyez un message traçable

Utilisez un objet comme SMTP validation 2026-08-25 14:30 UTC et un identifiant d’exécution non secret comme gmail-smtp-630184. Notez l’heure de l’application, l’hôte, le port, l’adresse From, le destinataire et la réponse du serveur. N’y mettez ni identifiants ni données client.

Quel effet sur DMARC ?

L’authentification SMTP dit si l’application peut utiliser le service de soumission de Google. DMARC dit si un domaine authentifié est aligné sur le domaine de l’adresse From visible. Ce sont deux contrôles distincts.

Si Google Workspace est le seul expéditeur de example.com, les consignes SPF de Google partent de v=spf1 include:_spf.google.com ~all (SPF dans Google Workspace). Un domaine avec d’autres expéditeurs doit bâtir une seule politique SPF combinée dans la limite de requêtes, sans publier de second enregistrement SPF.

Le DKIM de Google Workspace utilise une valeur TXT générée par le tenant. Google propose par défaut une clé de 2048 bits et le sélecteur google. Copiez le nom d’hôte et la valeur générés depuis votre console d’administration. Ne réutilisez jamais la valeur d’exemple ni la clé d’un autre compte. Selon Google, un tenant Gmail récemment activé peut attendre 24 à 72 heures avant de pouvoir générer une clé DKIM (DKIM dans Google Workspace).

Le flux actuel publié par le fournisseur montre où le tenant génère l’enregistrement.

Utilisez les valeurs du compte. Ne copiez pas l’exemple du schéma.

La RFC 9989 définit l’alignement souple et strict pour DKIM et SPF. DMARC réussit quand au moins un mécanisme pris en charge s’authentifie et que son identifiant est aligné sur le domaine From RFC5322 (RFC 9989, section 4.4). Un message signé par Google peut donc être accepté en SMTP mais échouer à DMARC pour example.com si ni le domaine de signature DKIM ni le domaine authentifié par SPF n’est aligné.

Valider la configuration

Vérifier le DNS

Interrogez SPF, le sélecteur DKIM et _dmarc.example.com sur plusieurs résolveurs publics. Comparez exactement l’hôte et la valeur DKIM générés par le tenant. Leur présence dans le DNS ne prouve pas que Google signe le message de test.

Statut du fournisseur

Dans la console d’administration Google, vérifiez que le domaine voulu affiche l’authentification DKIM activée une fois le DNS publié. Selon Google, il faut utiliser Start authentication, et le statut affiché est Authenticating email with DKIM (validation DKIM Google). Les libellés peuvent changer : suivez les consignes actuelles du tenant plutôt qu’une capture de mémoire.

En-têtes du message livré

Ouvrez la source brute du message contrôlé et repérez l’en-tête Authentication-Results ajouté par le destinataire. La section 1.2 de la RFC 8601 explique pourquoi un champ ajouté hors du périmètre de confiance du destinataire ne fait pas foi (RFC 8601, section 1.2). Confirmez spf=pass, dkim=pass et dmarc=pass, puis comparez smtp.mailfrom, header.d et header.from au lieu de lire les seuls pass. L’analyseur d’en-têtes de Palisade lit les en-têtes que vous fournissez ; il ne peut ni tester l’identifiant ni garantir le placement.

Rapports DMARC et livraison

Confirmez que la source Google autorisée apparaît dans les données DMARC agrégées du domaine From et que les sources inattendues n’augmentent pas après le lancement. Comparez ensuite la livraison et le placement Gmail du trafic prévu. Selon ses consignes actuelles, Google exige SPF ou DKIM de tous les expéditeurs vers des comptes Gmail personnels, et SPF, DKIM et DMARC au-delà de 5,000 messages par jour vers des comptes Gmail (consignes Google pour les expéditeurs).

Si le test réussit mais que l’équipe ne voit pas toutes les sources de production, l’agent DMARC de Palisade peut organiser les preuves DMARC agrégées du domaine. Smart DNS Deployment ne peut écrire que des changements DNS approuvés par un humain. Il ne configure pas les identifiants Google, ne teste pas une application qui n’a rien envoyé et ne garantit pas le placement. Commencez avec Palisade quand le test d’en-têtes montre que le besoin restant est la visibilité continue.

Dépannage

Authentification refusée

Vérifiez l’adresse complète, le type d’identifiant approuvé, la validation en 2 étapes, l’accès au mot de passe d’application et la politique Workspace. Ne réessayez pas en boucle un identifiant verrouillé ou bloqué.

Échec de négociation TLS

Associez le port 587 à STARTTLS et le port 465 au SSL implicite. Mettez à jour un client incapable d’assurer la sécurité de transport requise au lieu de désactiver la vérification TLS ou du certificat.

Le message part mais DMARC échoue

Comparez le domaine From visible avec header.d et smtp.mailfrom. Corrigez la signature, l’autorisation d’alias ou la configuration à la source réelle. Le guide d’authentification Gmail couvre les contrôles DNS.

Le serveur accepte mais la livraison se dégrade

Vérifiez les limites de débit et quotidiennes, les plaintes, les changements d’envoi et Google Postmaster. L’acceptation du serveur ne promet pas le placement. Ne changez ni port ni contenu au hasard tant que la source d’envoi reste inexpliquée.

Limites de cette configuration

La procédure couvre le serveur SMTP Gmail authentifié. Ce guide compare le relais et la méthode restreinte, mais ne fournit pas de déploiement complet de politique de relais, de livraison directe non authentifiée vers un MX, d’architecture marketing à fort volume, de réglages Gmail entrants ni de récupération de compte grand public. Un appareil qui ne peut respecter la politique de la méthode authentifiée peut avoir besoin du relais géré par l’administrateur ou du chemin restreint aux destinataires internes, pas d’un compte Gmail affaibli.

Preuve

Sources et pour aller plus loin

• Options SMTP Google pour appareils
• SPF dans Google Workspace
• DKIM dans Google Workspace
• Consignes Google aux expéditeurs
• RFC 9989, DMARC
• RFC 8601, Authentication-Results