11 min de lecture Diesen Artikel auf Deutsch lesen Read this article in English Ler este artigo em português

Relais SMTP : services, Google et DNS

La réponse en bref

Un relais SMTP est un serveur qui prend en charge vos e-mails sortants et les livre au serveur de messagerie du destinataire. Votre application se connecte à l'hôte du relais sur son port de soumission et passe en TLS avec STARTTLS. Elle s'authentifie ensuite avec des identifiants ou se connecte depuis une IP autorisée. Il faut aussi autoriser le relais dans le DNS : l'ajouter à votre enregistrement SPF et lui faire signer DKIM avec votre propre domaine, pour que l'alignement DMARC passe.

Dans cet article

Qu'est-ce qu'un relais SMTP ?

Un relais SMTP est un serveur de messagerie qui reçoit un message d'un client et le transmet à un autre serveur, généralement l'hôte MX du destinataire. Il s'appuie sur SMTP, le Simple Mail Transfer Protocol, que l'IETF publie comme standard ouvert. Le client peut être un CRM, un formulaire de contact de site web, une imprimante qui numérise vers l'e-mail ou un outil commercial. Le client ne livre pas lui-même le courrier sur Internet. Il confie chaque message au relais, et c'est le relais qui gère les requêtes DNS, les nouvelles tentatives et les rebonds.

Prenons un exemple. Votre boutique en ligne envoie une confirmation de commande depuis commandes@votredomaine.fr. Le serveur de la boutique se connecte au port de soumission de votre relais, s'authentifie et soumet le message. Le relais consulte l'enregistrement MX du domaine de l'acheteur, ouvre une connexion SMTP de serveur à serveur vers cet hôte et livre le message. Si le serveur de réception est surchargé et renvoie un code d'échec temporaire, le relais met le message en file d'attente et réessaie plus tard. Votre boutique n'a jamais à s'en occuper.

Ensuite, le serveur de réception vérifie si le relais a le droit d'envoyer pour votredomaine.fr. C'est la vérification que la plupart des configurations ratent. La section DNS plus bas y est consacrée.

Comment fonctionne un relais SMTP, étape par étape ?

  1. Soumission : le client se connecte au port de soumission du relais. La page de configuration du relais l'indique, souvent accompagné d'un port en TLS implicite. La livraison de serveur à serveur utilise un port distinct.
  2. Chiffrement : sur le port de soumission, le client envoie la commande STARTTLS. La connexion passe ainsi en TLS avant qu'aucun identifiant ne soit transmis.
  3. Authentification : le client se connecte via SMTP AUTH, avec un nom d'utilisateur et un mot de passe ou des identifiants de type clé API. Sinon, le relais accepte la connexion parce qu'elle provient d'une adresse IP enregistrée.
  4. Enveloppe et message : le client envoie MAIL FROM, un RCPT TO par destinataire, puis DATA avec les en-têtes et le corps. L'adresse MAIL FROM est l'expéditeur d'enveloppe, et elle devient le Return-Path.
  5. Signature : le relais ajoute une signature DKIM. Idéalement, la valeur d= est votre propre domaine.
  6. Livraison : le relais consulte l'enregistrement MX du domaine du destinataire et livre. Les échecs temporaires sont mis en file d'attente et retentés. Les échecs définitifs génèrent un message de rebond.

C'est la troisième étape qui distingue un relais d'un relais ouvert. Un relais ouvert accepte le courrier de n'importe qui et l'envoie n'importe où. Les considérations de sécurité du standard SMTP citent explicitement ce risque. Les spammeurs repèrent vite les relais ouverts, et l'IP du relais finit alors sur des listes de blocage DNS. Tous les services de la section suivante exigent une authentification ou une liste d'IP autorisées.

Qu'est-ce qu'un service de relais SMTP, et lesquels existent ?

Un service de relais SMTP est un relais hébergé. Vous obtenez un nom d'hôte, un port et des identifiants, et le fournisseur exploite l'infrastructure d'envoi. Google Workspace, Amazon SES, Brevo, Mailgun, Mailjet, MailerSend, SMTP2GO et SocketLabs publient tous une documentation de relais SMTP. Le protocole est le même partout. Ce qui change, c'est le public visé par chaque service et ce que sa politique d'utilisation acceptable autorise. Le tableau compare les services selon les mêmes critères, d'après la documentation de chaque éditeur.

Service Conçu pour Mode d'authentification Limites
Relais SMTP Google Workspace Les appareils et applications d'une organisation qui utilise déjà la messagerie Workspace Adresses IP enregistrées, SMTP AUTH avec un compte Workspace, ou les deux (Aide Administrateur Google Workspace) Réservé aux clients Workspace, et c'est l'administrateur qui décide quelles adresses d'expéditeur sont autorisées
Interface SMTP d'Amazon SES Les développeurs et applications qui tournent déjà sur AWS Identifiants SMTP propres à SES, créés dans la console SES. Ils sont distincts des clés d'accès AWS (Amazon SES Developer Guide) Les nouveaux comptes démarrent dans une sandbox. Tant que l'accès production n'est pas accordé, ils ne peuvent envoyer qu'à des adresses vérifiées
Relais SMTP Brevo Les expéditeurs marketing et transactionnels qui veulent les outils de campagne dans le même compte Un identifiant et une clé SMTP issus des paramètres SMTP du compte Brevo L'envoi est encadré par la politique d'utilisation acceptable de Brevo et par l'offre du compte
Mailgun, Mailjet, MailerSend, SMTP2GO, SocketLabs Le courrier transactionnel des applications : reçus, réinitialisations de mot de passe, notifications Identifiants SMTP ou clés API par domaine, selon la documentation de chaque éditeur La politique d'utilisation acceptable de chaque éditeur contient des règles sur les e-mails non sollicités. Lisez-la avant d'utiliser le service pour de la prospection
Situation en octobre 2026. D'après la documentation de relais SMTP publiée par chaque éditeur. Les offres et quotas évoluent : vérifiez les pages de l'éditeur.

Pour votre réputation d'expéditeur, la question clé est de savoir si le service signe avec votre domaine et vous permet de définir un Return-Path personnalisé sur un sous-domaine qui vous appartient. Si c'est le cas, la réputation se construit sous votre domaine. Sinon, le serveur de réception voit le domaine du fournisseur à la place.

Relais SMTP Google : comment fonctionne le service Workspace ?

Le relais SMTP de Google est une fonctionnalité Workspace qui permet à un administrateur de faire passer le courrier sortant des appareils et applications par les serveurs de Google. Google la documente dans l'Aide Administrateur Google Workspace, dans l'article « Acheminer les messages sortants via le service de relais SMTP de Google ». Dans la console d'administration, allez dans Applications > Google Workspace > Gmail > Routage et ouvrez le paramètre Service de relais SMTP. Vous y configurez trois éléments :

  • Expéditeurs autorisés : uniquement les utilisateurs Workspace enregistrés, uniquement les adresses de vos domaines, ou n'importe quelle adresse.
  • Authentification : n'accepter le courrier que depuis des adresses IP spécifiées, exiger l'authentification SMTP avec un compte Workspace, ou exiger les deux.
  • Chiffrement : exiger TLS pour la connexion.

Les clients se connectent à smtp-relay.gmail.com sur l'un des ports indiqués dans cet article de l'Aide Administrateur. Une panne fréquente : une imprimante ou une application qui se connecte depuis une IP dynamique jamais enregistrée. Google rejette le courrier, et l'appareil n'affiche qu'une erreur d'envoi générique. Le courrier envoyé via le relais est décompté des limites d'envoi du relais Google, qui sont distinctes des limites par utilisateur, avec leurs quotas propres et les erreurs de rebond qu'ils provoquent. Votre enregistrement SPF doit aussi contenir include:_spf.google.com. Sans lui, le courrier relayé échoue au contrôle SPF.

Peut-on utiliser Gmail comme service de relais SMTP ?

Un compte Gmail personnel n'inclut pas le service de relais Workspace. Il dispose en revanche d'un serveur SMTP sortant, smtp.gmail.com, auquel un client de messagerie ou un script peut se connecter avec les identifiants du compte. Selon l'Aide Compte Google, les applications qui ne prennent pas en charge la connexion Google ont besoin d'un mot de passe d'application, et ces mots de passe ne fonctionnent qu'une fois la validation en deux étapes activée. smtp.gmail.com est donc un serveur de soumission pour une seule boîte aux lettres, pas un relais pour un bureau ou une application. Chaque message part au nom de ce compte unique et est décompté de ses limites d'envoi.

Cela convient pour un script qui vous envoie des alertes. Pas pour le courrier de votre domaine d'entreprise. Un compte gmail.com ne peut pas signer DKIM pour votredomaine.fr, donc DMARC ne peut pas s'aligner sur votre domaine. Pour envoyer depuis votre propre domaine via Google, il vous faut un abonnement Workspace et smtp-relay.gmail.com. Notre guide sur les enregistrements DNS Google Workspace couvre la partie DNS.

Existe-t-il un relais SMTP gratuit ?

Plusieurs fournisseurs transactionnels proposent des offres gratuites ou des volumes d'essai. Les plafonds varient selon l'éditeur et changent avec le temps, nous ne les citons donc pas ici. Consultez la page tarifs de chaque éditeur le jour de votre inscription. Pour comparer les options gratuites, regardez les points ci-dessous. Ce sont eux qui déterminent si une offre gratuite est réellement utilisable et ce que vous paierez une fois que vous l'aurez dépassée :

  • Les plafonds de volume par jour ou par mois. Les messages au-delà du plafond sont généralement rejetés ou retenus en file d'attente, pas livrés.
  • La signature DKIM sur domaine personnalisé et le Return-Path personnalisé. Vérifiez s'ils sont inclus dans l'offre gratuite ou réservés aux offres payantes.
  • IP partagées ou dédiées. Les offres gratuites envoient généralement depuis des pools partagés : le comportement des autres expéditeurs pèse sur la réputation de l'IP.
  • La conservation des logs et les webhooks de rebond. Vous en avez besoin pour retirer les hard bounces avant votre prochain envoi.
  • La politique d'utilisation acceptable. Elle est la même pour les comptes gratuits et payants et contient généralement des règles sur les e-mails non sollicités.

Faire tourner votre propre serveur Postfix ne coûte rien en licences, mais le travail vous revient : DNS inverse, certificats TLS, surveillance des files d'attente et contrôle des listes de blocage. De nombreux fournisseurs cloud bloquent par défaut le trafic SMTP sortant de serveur à serveur sur les nouvelles instances. Tant que le fournisseur n'a pas levé ce blocage, un relais auto-hébergé ne peut souvent rien livrer.

Quels enregistrements DNS un relais SMTP exige-t-il ?

C'est le serveur de réception qui décide d'accepter ou non le courrier relayé, et la première chose qu'il vérifie, c'est votre DNS. Voici chaque enregistrement concerné, et la façon dont il échoue typiquement :

Enregistrement Son rôle pour le courrier relayé Erreur typique
SPF (TXT à la racine ou sur le domaine du Return-Path) Autorise les IP du relais à envoyer pour le domaine d'enveloppe L'include du relais manque, ou quelqu'un ajoute un second enregistrement SPF. La spécification SPF traite plusieurs enregistrements SPF comme une erreur permanente (permerror)
DKIM (TXT ou CNAME sur selecteur._domainkey) Permet au relais de signer avec d=votredomaine.fr Le relais signe avec son propre domaine. DKIM passe, mais ne s'aligne pas sur votre domaine From
DMARC (TXT sur _dmarc) Exige que SPF ou DKIM passe et s'aligne sur le domaine From, comme le définit la spécification DMARC Les deux contrôles passent sur le domaine du fournisseur, aucun ne s'aligne sur le vôtre, et DMARC échoue
Return-Path personnalisé (CNAME) Place l'expéditeur d'enveloppe sur votre sous-domaine pour que SPF puisse s'aligner Il n'est pas configuré : les rebonds et le contrôle SPF portent sur le domaine du fournisseur

Une fois votre DNS modifié, envoyez un message de test et examinez l'en-tête Authentication-Results. Vous cherchez spf=pass, dkim=pass avec votre propre domaine dans header.d, et dmarc=pass. Notre vérificateur SPF, DKIM et DMARC interroge les enregistrements que vous avez publiés. Le guide SPF, DKIM et DMARC pour le cold emailing approfondit la question de l'alignement.

Comment EmailFlow OS envoie : depuis votre propre compte Brevo et votre domaine

La prospection vidéo avec EmailFlow OS ne passe pas par un expéditeur partagé de la plateforme. Vous enregistrez une seule vidéo et la téléversez dans EmailFlow OS. Vous connectez votre propre compte Brevo et votre domaine d'envoi. Puis vous importez votre liste de prospects dans EmailFlow OS, et c'est là qu'elle réside. EmailFlow OS crée une version personnalisée de cet unique enregistrement pour chaque destinataire, et non une par entreprise. Chaque version part de votre propre boîte d'envoi, via votre compte Brevo et votre domaine d'envoi.

Vos enregistrements SPF, DKIM et DMARC, la réputation de votre domaine et votre compte Brevo restent sous votre contrôle. Cela signifie aussi que le travail DNS décrit plus haut vous revient toujours. C'est le serveur de réception qui décide d'accepter chaque message et du dossier dans lequel il arrive. La page consacrée à l'e-mail vidéo IA personnalisé d'EmailFlow OS montre comment le processus s'articule.

Questions fréquentes

Quel port utiliser pour un relais SMTP ?
Utilisez le port de soumission du relais avec STARTTLS, ou son port en TLS implicite si votre client ne gère que celui-là. Le port de serveur à serveur sert à la livraison entre serveurs de messagerie, et de nombreux réseaux cloud et FAI le bloquent en sortie. Chaque service indique ses ports sur sa propre page de configuration : Google dans l'Aide Administrateur Google Workspace, Amazon dans l'Amazon SES Developer Guide.
Quelle différence entre un relais SMTP et un relais ouvert ?
Un relais SMTP ne transmet le courrier que des clients qui s'authentifient via SMTP AUTH ou se connectent depuis une IP autorisée. Un relais ouvert transmet le courrier de n'importe qui vers n'importe quelle destination. Les spammeurs recherchent les relais ouverts, et leurs IP finissent sur des listes de blocage DNS. C'est pourquoi tous les services de relais hébergés exigent des identifiants ou des IP enregistrées.
Un service de relais SMTP améliore-t-il la délivrabilité ?
Un relais ne décide pas où arrive un message. C'est le serveur de réception qui le décide. Le relais met les messages en file d'attente, les retente et signale les rebonds. Le serveur de réception tient compte de l'alignement SPF et DKIM avec votre domaine From, de la réputation de votre domaine, des plaintes et de la qualité de la liste. Un relais qui signe avec son propre domaine au lieu du vôtre peut faire échouer DMARC.
Peut-on utiliser un relais SMTP transactionnel pour du cold emailing ?
Lisez d'abord la politique d'utilisation acceptable du fournisseur. Les services transactionnels comme Amazon SES, Mailgun et Mailjet publient des règles sur les e-mails non sollicités, et les enfreindre peut entraîner la suspension de votre compte. Dans l'UE, des règles de consentement, comme celles de l'UWG en Allemagne, s'appliquent aussi, quel que soit le relais utilisé. Renseignez-vous sur ce qu'exige votre prospection avant d'envoyer.

Partager

LinkedIn X

À lire aussi

Tous les articles