Chaque jour, des milliards de courriels transitent entre organisations qui ne partagent ni la même infrastructure, ni le même fournisseur de messagerie. Le protocole qui rend ce transit possible porte un nom : SMTP. Mais réduire la réussite d’un flux de courrier électronique interorganisationnel à ce seul protocole serait ignorer les couches d’authentification et de chiffrement qui conditionnent désormais la délivrabilité réelle des messages.
Cet article examine pourquoi SMTP reste le socle, comment les exigences récentes de Google ont redéfini les règles du jeu, et ce qui distingue un flux technique fonctionnel d’un flux réellement fiable entre deux domaines.
A lire également : Comment décrypter un fichier PDF ?
SMTP et TLS : le socle technique du flux de courrier interorganisationnel
SMTP (Simple Mail Transfer Protocol) est le protocole de transfert utilisé depuis les débuts d’Internet pour acheminer un courriel d’un serveur expéditeur vers un serveur destinataire. Quand un collaborateur envoie un message à un partenaire extérieur, c’est SMTP qui prend en charge le routage entre les deux domaines, en s’appuyant sur les enregistrements DNS (notamment les enregistrements MX) pour localiser le serveur de réception.
SMTP gère l’acheminement, pas la consultation. La récupération des messages par le destinataire repose sur d’autres protocoles : IMAP, qui synchronise les courriels entre le serveur et le client de messagerie, ou POP3, qui les télécharge localement. Cette distinction compte, parce qu’un problème de flux entre organisations concerne presque toujours la couche SMTP, pas la couche de consultation.
A lire en complément : Quel est le meilleur traitement de texte gratuit ?
En revanche, SMTP seul ne chiffre pas le contenu du trajet entre serveurs. C’est TLS (Transport Layer Security) qui assure le chiffrement du canal de communication. Sans TLS, les messages circulent en clair entre les relais, exposant potentiellement les données à une interception. Les recommandations actuelles de délivrabilité, y compris celles de Gmail, traitent TLS comme une exigence opérationnelle distincte de l’authentification.
Authentification SPF, DKIM et DMARC : ce que Google impose depuis 2024
Depuis le 1er février 2024, Google exige au minimum SPF ou DKIM pour tout expéditeur envoyant des courriels vers des adresses Gmail personnelles. Pour les expéditeurs en volume, les trois mécanismes (SPF, DKIM et DMARC) sont requis, avec un alignement du domaine visible dans le champ From:. Google a renforcé les rejets des messages non conformes à partir de novembre 2025.
Ces trois protocoles d’authentification remplissent des fonctions complémentaires :
- SPF (Sender Policy Framework) déclare dans un enregistrement DNS la liste des serveurs autorisés à envoyer des courriels pour un domaine donné. Le serveur de réception vérifie si l’adresse IP expéditrice figure dans cette liste.
- DKIM (DomainKeys Identified Mail) appose une signature cryptographique sur chaque message sortant. Le serveur destinataire vérifie cette signature via une clé publique publiée dans le DNS du domaine expéditeur, ce qui garantit que le contenu n’a pas été altéré en transit.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) lie SPF et DKIM au domaine affiché dans le champ
From:. Il définit une politique de traitement (aucune action, quarantaine, rejet) et génère des rapports qui permettent à l’organisation expéditrice de surveiller les tentatives d’usurpation.
Sans cette chaîne d’authentification, un domaine expéditeur risque de voir ses messages classés en spam ou rejetés, même si la configuration SMTP est techniquement correcte.
Réputation du domaine et taux de plaintes : la couche invisible du flux de courrier
La conformité technique ne garantit pas la délivrabilité. Google recommande de maintenir le taux de spam signalé par les destinataires sous 0,10 % et considère 0,30 % comme un seuil critique. Dépasser ce seuil peut entraîner des limitations ou des rejets, même lorsque SPF, DKIM et DMARC sont correctement déployés.
Ce point change la nature du problème. Un flux de courrier entre organisations ne dépend plus uniquement de la bonne configuration des protocoles. Il dépend aussi de la manière dont les destinataires perçoivent les messages reçus. Un volume élevé de signalements de spam dégrade la réputation du domaine expéditeur auprès des fournisseurs de messagerie.
Supervision et outils Postmaster
Google met à disposition des outils comme Postmaster Tools, qui permettent de suivre la réputation d’un domaine, le taux de plaintes et les erreurs d’authentification. Pour une organisation qui échange régulièrement des courriels avec des partenaires, surveiller ces indicateurs fait partie du protocole opérationnel au même titre que la configuration DNS.
Les retours terrain divergent sur l’impact exact de chaque facteur. Une organisation peut voir ses messages rejetés malgré une authentification parfaite si sa réputation s’est dégradée à cause d’un incident antérieur. À l’inverse, un domaine avec une réputation solide tolère mieux les erreurs ponctuelles de configuration.
Configuration des connecteurs Exchange et flux hybrides
Dans les environnements Microsoft 365 ou Exchange hybride, le flux de courrier entre organisations passe souvent par des connecteurs. Ces connecteurs personnalisent le routage SMTP pour des scénarios précis : envoi vers un serveur de messagerie local, application de restrictions de sécurité avec un partenaire commercial, ou relais de messages depuis des applications internes.
La plupart des organisations Microsoft 365 n’ont pas besoin de connecteurs pour le flux de courrier standard. Les connecteurs interviennent quand le flux sort du cas classique, par exemple pour éviter les listes grises liées à un volume élevé d’échanges réguliers entre deux environnements, ou pour forcer le chiffrement TLS avec un partenaire spécifique.
Enregistrements DNS et routage MX
La configuration DNS reste le socle de tout flux interorganisationnel. Les enregistrements MX déterminent vers quel serveur un courriel doit être dirigé. Les enregistrements SPF et DKIM sont publiés dans le DNS. Une erreur dans les enregistrements DNS peut bloquer un flux entier sans qu’aucune alerte ne soit générée côté expéditeur.
Vérifier la cohérence entre les enregistrements MX, SPF et la politique DMARC d’un domaine constitue le diagnostic de base quand un flux de courrier entre deux organisations échoue.
Ce qui distingue un flux fonctionnel d’un flux fiable entre organisations
Un flux fonctionnel, c’est un serveur SMTP qui accepte et transmet les messages. Un flux fiable entre organisations suppose une pile complète :
- SMTP avec TLS pour le transport chiffré
- SPF, DKIM et DMARC correctement alignés pour l’authentification
- Une réputation de domaine surveillée et maintenue sous les seuils de plaintes
- Des enregistrements DNS cohérents et régulièrement vérifiés
- Des connecteurs configurés si l’architecture l’exige (environnements hybrides, partenaires avec contraintes de sécurité)
SMTP reste le protocole fondamental du courrier électronique entre organisations, celui sans lequel aucun message ne transite. La délivrabilité réelle dépend toutefois de l’ensemble de la chaîne.
Les exigences de Google, appliquées progressivement depuis 2024 et renforcées fin 2025, ont transformé l’authentification et la gestion de réputation en prérequis opérationnels. Un domaine qui néglige SPF, DKIM ou DMARC ne rencontre pas un problème de protocole SMTP. Il rencontre un problème de confiance entre serveurs, et ce problème se traduit par des messages qui n’arrivent jamais.
