Paramètres SMTP Gmail 2026 : ports, TLS, auth

Références de commandes utilisées dans ce guide : nylas email send pour envoyer sans SMTP, nylas auth login pour l'authentification OAuth, nylas auth config pour la configuration headless par clé API, et nylas email search pour rechercher des messages.

Quels sont les paramètres du serveur SMTP de Gmail ?

Le serveur de courrier sortant de Gmail est smtp.gmail.com. Il accepte les connexions sur le port 587 avec chiffrement STARTTLS et sur le port 465 avec SSL/TLS implicite. Les deux ports exigent une authentification par mot de passe d'application ou par token d'accès OAuth 2.0. Les connexions en clair sur le port 25 ne sont pas disponibles pour les comptes Gmail standard. Ces paramètres n'ont pas changé depuis que Google les a standardisés, mais les méthodes d'authentification se sont nettement restreintes depuis 2022.

Google exploite aussi un relais SMTP sur smtp-relay.gmail.com pour les comptes Workspace qui ont besoin d'un débit plus élevé. Le relais supporte jusqu'à 10 000 destinataires par jour et par utilisateur et permet une authentification par IP au lieu d'identifiants utilisateur. Selon la documentation Workspace de Google, le relais est destiné aux imprimantes, scanners et applications internes qui envoient depuis une plage IP connue.

La configuration la plus courante utilise le port 587 avec STARTTLS. Voici à quoi cela ressemble dans msmtp, un client SMTP léger que beaucoup de développeurs utilisent comme remplacement de sendmail. Le fichier de configuration est ~/.msmtprc et s'écrit en 2 minutes environ.

# ~/.msmtprc — Gmail SMTP via msmtp
account        gmail
host           smtp.gmail.com
port           587
tls            on
tls_starttls   on
auth           on
user           you@gmail.com
password       abcd-efgh-ijkl-mnop
from           you@gmail.com
logfile        ~/.msmtp.log

account default : gmail

Comment créer un mot de passe d'application Gmail pour SMTP ?

Un mot de passe d'application Gmail est un code de 16 caractères qui remplace le mot de passe de votre compte lors d'une connexion SMTP. Google le génère pour vous une fois la validation en deux étapes activée. Les mots de passe d'application sont actuellement la seule méthode d'authentification SMTP par mot de passe pour les comptes Gmail personnels. Google a commencé à désactiver l'accès des « applications moins sécurisées » (Less Secure Apps) le 30 septembre 2024 puis, après une pause du déploiement en octobre, a finalisé l'arrêt le 1er mai 2025 — supprimant l'ancienne option d'utiliser votre mot de passe Gmail habituel pour les connexions SMTP.

Créer un mot de passe d'application prend environ 3 minutes. Il faut d'abord activer la validation en deux étapes, que Google exige pour tous les nouveaux comptes depuis 2021. Voici les étapes :

1. Allez sur myaccount.google.com/security et confirmez que la validation en deux étapes est active.
2. Rendez-vous sur myaccount.google.com/apppasswords.
3. Saisissez un nom pour l'application (par exemple « SMTP script ») et cliquez sur Créer.
4. Copiez le mot de passe de 16 caractères. Il ne s'affiche qu'une seule fois — impossible de le récupérer plus tard.
5. Utilisez ce mot de passe comme mot de passe SMTP dans votre client. Le nom d'utilisateur est votre adresse e-mail complète.

Selon la documentation des mots de passe d'application de Google, les mots de passe d'application "aren't recommended and are unnecessary in most cases" (ne sont pas recommandés et sont inutiles dans la plupart des cas). Google privilégie la connexion OAuth 2.0. Les mots de passe d'application sont aussi révoqués automatiquement dès que vous changez le mot de passe de votre compte Google : toute intégration SMTP qui en utilise un cessera de fonctionner jusqu'à génération d'un nouveau code.

Vous pouvez tester le mot de passe d'application avec swaks, l'outil de test du protocole SMTP. Il envoie un seul message via le serveur SMTP de Gmail et affiche chaque étape du handshake SMTP, ce qui rend les échecs d'authentification faciles à repérer. Le test prend environ 5 secondes.

# Test Gmail SMTP auth with swaks
swaks --to recipient@example.com \
  --from you@gmail.com \
  --server smtp.gmail.com \
  --port 587 \
  --tls \
  --auth LOGIN \
  --auth-user you@gmail.com \
  --auth-password "abcd-efgh-ijkl-mnop"

# Expected output (successful):
# -> AUTH LOGIN
# <- 235 2.7.0 Accepted
# -> MAIL FROM:<you@gmail.com>
# <- 250 2.1.0 OK

Quelles sont les limites d'envoi SMTP de Gmail ?

Les comptes Gmail personnels peuvent envoyer 500 e-mails par fenêtre glissante de 24 heures. Les comptes Google Workspace disposent de 2 000 messages par jour. Lorsque vous dépassez la limite, Gmail renvoie une erreur temporaire et suspend l'envoi sortant pendant jusqu'à 24 heures. Le courrier entrant continue de fonctionner pendant la suspension. Les comptes Workspace en période d'essai sont plafonnés à 500 messages par jour tant que le cumul des paiements n'atteint pas 100 USD.

La limite de 100 destinataires par message sur les connexions SMTP est plus basse que les 500 autorisés via l'interface web de Gmail. Selon la documentation des limites d'envoi Workspace de Google, les utilisateurs SMTP, POP et IMAP sont plafonnés à 100 destinataires par message quel que soit le type de compte. Si votre script envoie à plus de 100 adresses, répartissez les destinataires en lots.

Pour les expéditeurs en masse qui envoient plus de 5 000 messages par jour à des destinataires Gmail, Google exige l'authentification SPF, DKIM et DMARC sur le domaine d'envoi, plus un en-tête de désabonnement en un clic. Ces exigences sont entrées en vigueur en février 2024. Les expéditeurs qui dépassent leur quota voient le code d'erreur SMTP 4.7.28 — un rejet temporaire qui disparaît une fois la fenêtre de 24 heures réinitialisée.

Pourquoi l'authentification SMTP Gmail échoue-t-elle ?

L'authentification SMTP Gmail échoue pour 4 raisons courantes : mot de passe d'application manquant, identifiants erronés, validation en deux étapes désactivée ou trop de connexions simultanées. Google renvoie un code d'erreur SMTP spécifique pour chaque cas. Le message d'erreur indique exactement ce qui n'a pas fonctionné si vous savez où regarder. Voici les codes que vous rencontrerez le plus souvent.

L'erreur la plus courante en 2026 est 534-5.7.9. Les développeurs copient des exemples SMTP issus d'anciens tutoriels qui utilisent un mot de passe Gmail classique. Ces exemples fonctionnaient tant que Google autorisait encore l'accès des applications moins sécurisées, dont l'arrêt a commencé le 30 septembre 2024 et s'est achevé définitivement le 1er mai 2025. Désormais, toute connexion SMTP à Gmail exige un mot de passe d'application ou un token OAuth 2.0.

Pour diagnostiquer les erreurs SMTP de manière interactive, utilisez openssl pour ouvrir une connexion TLS brute. Cela affiche la bannière SMTP exacte et la réponse d'erreur du serveur de Google, ce qui est utile quand les clients de plus haut niveau masquent le code d'erreur d'origine. La commande se connecte au port 465 en TLS implicite.

# Open a raw TLS connection to Gmail SMTP
openssl s_client -connect smtp.gmail.com:465 -quiet

# You'll see the SMTP banner:
# 220 smtp.gmail.com ESMTP ... - gsmtp

# Authenticate manually:
EHLO localhost
AUTH LOGIN
# Enter base64-encoded username and password
# Google returns 235 on success or 535-5.7.8 on failure

Le SMTP de Gmail est-il en cours de dépréciation ?

Le SMTP de Gmail lui-même n'est pas déprécié. Le serveur smtp.gmail.com accepte toujours les connexions sur les ports 587 et 465 en mai 2026. Ce qui a changé, c'est la façon de s'authentifier. Google a systématiquement supprimé les méthodes d'authentification les plus simples au cours des 4 dernières années, ne laissant que les mots de passe d'application et OAuth 2.0. La direction est claire : OAuth est la voie prévue.

Voici la chronologie de ce que Google a arrêté :

Les mots de passe d'application restent disponibles aujourd'hui, mais la propre documentation de Google les qualifie de "not recommended" (non recommandés). Ils comportent un risque : quiconque détient le code de 16 caractères a un accès SMTP complet au compte, et il est impossible de restreindre un mot de passe d'application à des actions spécifiques. OAuth 2.0 vous permet de ne demander que les scopes nécessaires (par exemple https://mail.google.com/ pour SMTP) et les tokens expirent après 3 600 secondes. Si vous construisez quelque chose de nouveau, utilisez OAuth.

Pour les administrateurs Workspace, le billet de blog de septembre 2023 de Google a confirmé le chemin de migration : les applications qui ont besoin d'un accès au courrier doivent utiliser OAuth ou l'API Gmail. Les imprimantes et scanners incapables de faire OAuth doivent utiliser le relais smtp-relay.gmail.com avec authentification par IP à la place.

Comment envoyer un e-mail sans configurer SMTP ?

Nylas CLI envoie des e-mails via l'API Nylas sans configuration SMTP, sans mot de passe d'application et sans gestion de tokens OAuth. Une seule commande authentifie via un flux OAuth dans le navigateur, et les envois suivants utilisent des identifiants stockés qui se renouvellent automatiquement toutes les 3 600 secondes. La mise en place complète, de l'installation au premier e-mail envoyé, prend moins de 2 minutes. Le tout fonctionne avec Gmail, Outlook, Exchange, Yahoo, iCloud et les fournisseurs IMAP.

Installez le CLI avec Homebrew, puis lancez la configuration guidée. La commande nylas init vous accompagne dans la création du compte, la configuration de la clé API et la connexion de la boîte mail. Si vous avez déjà une clé API Nylas, vous pouvez passer directement à nylas auth config. Consultez le guide de démarrage pour les autres méthodes d'installation (script shell, PowerShell, Go).

# Install Nylas CLI
brew install nylas/nylas-cli/nylas

# Guided setup (creates account, API key, connects mailbox)
nylas init

# Or, if you already have an API key
nylas auth config --api-key nyl_abc123
nylas auth login

# Send an email — no SMTP, no app password, no port config
nylas email send \
  --to recipient@example.com \
  --subject "Sent without SMTP" \
  --body "No smtp.gmail.com, no port 587, no app password."

# Send non-interactively (for scripts and cron jobs)
nylas email send \
  --to ops@company.com \
  --subject "Deploy complete" \
  --body "Build #1847 deployed at $(date)" \
  --yes

La différence entre l'envoi SMTP et l'envoi par API est significative pour les scripts qui tournent sans surveillance. Avec SMTP, vous gérez les identifiants (des mots de passe d'application qui cassent quand le mot de passe du compte change), le pooling de connexions (Gmail vous limite à 10 sessions SMTP simultanées) et la négociation TLS. Avec le CLI, une seule commande gère tout cela. L'outil stocke les tokens OAuth dans le trousseau de clés de votre système et les renouvelle avant leur expiration.

Pour les scripts Python qui utilisent actuellement smtplib avec les paramètres SMTP de Gmail, vous pouvez remplacer le bloc SMTP par un appel subprocess. Cela élimine entièrement la configuration SMTP et le mot de passe d'application de votre code. Le guide Envoyer un e-mail depuis Python sans SMTP couvre le schéma de migration complet.

# Before: 15 lines of smtplib + Gmail SMTP config
import smtplib
from email.mime.text import MIMEText

msg = MIMEText("Hello from Python")
msg["Subject"] = "Test"
msg["From"] = "you@gmail.com"
msg["To"] = "recipient@example.com"

with smtplib.SMTP("smtp.gmail.com", 587) as server:
    server.starttls()
    server.login("you@gmail.com", "abcd-efgh-ijkl-mnop")  # app password
    server.send_message(msg)

# After: 1 subprocess call, no SMTP, no password in code
import subprocess
subprocess.run([
    "nylas", "email", "send",
    "--to", "recipient@example.com",
    "--subject", "Test",
    "--body", "Hello from Python",
    "--yes"
], check=True)

Si votre cas d'usage exige SMTP (tests de serveur mail, intégration d'imprimantes, applications héritées qui ne peuvent pas appeler de sous-processus), les paramètres en haut de cette page sont ce qu'il vous faut. Pour tout le reste, l'envoi via une API supprime les pièces mobiles : pas de port à retenir, pas de TLS à négocier, pas de mot de passe d'application à faire tourner.

Étapes suivantes

• Mots de passe d'application Gmail : création et pièges — créez-en un, ou sautez l'étape avec OAuth
• API e-mail vs SMTP — quand SMTP suffit et quand il ne suffit pas
• Référence complète des commandes — chaque flag, sous-commande et exemple du CLI Nylas
• Envoyer un e-mail depuis le terminal — workflows d'envoi détaillés pour Gmail, Outlook, Exchange, Yahoo, iCloud et IMAP
• Envoyer un e-mail depuis Python sans SMTP — remplacez smtplib par un seul appel subprocess
• Wrapper Python smtplib : le construire ou s'en passer — schémas de connexion, TLS et retry pour les scripts qui gardent SMTP
• Bien démarrer — installation sur macOS, Linux ou Windows en moins de 2 minutes
• SPF, DKIM, DMARC : déboguer la délivrabilité e-mail — diagnostiquez les en-têtes d'authentification et les bounces depuis la ligne de commande
• Comparatif des outils e-mail en CLI — comparez Nylas CLI, Himalaya, msmtp, NeoMutt et 3 autres outils