L'équipe d'ingénierie d'une startup a conçu son application pour envoyer des emails directement depuis ses serveurs web. En développement, tout fonctionnait bien. En production, les emails ont commencé à disparaître. Gmail les a rejetés. Microsoft les a limités. Leurs adresses IP n'avaient aucune réputation, leurs serveurs n'étaient pas configurés pour la livraison d'email, et ils découvraient à leurs dépens qu'envoyer des emails est plus difficile qu'il n'y paraît.
Ils sont passés à un service de relais de messagerie. En vingt-quatre heures, leurs problèmes de délivrabilité ont disparu. Le relais a géré l'authentification, maintenu la réputation des IP, traité la limitation de débit et les nouvelles tentatives, et, de façon générale, a pris en charge tout ce que leurs serveurs web ne faisaient pas bien.
Les relais de messagerie existent parce qu'envoyer des emails de manière fiable est un problème spécialisé. La plupart des applications ne devraient pas essayer de le résoudre elles-mêmes.
Ce que fait réellement un relais
Un relais de messagerie accepte les emails d'un système et les transmet à un autre. Votre application envoie l'email au relais; le relais l'envoie au serveur de messagerie du destinataire. Le relais est au milieu et prend en charge la complexité de la livraison réelle.
Cela peut sembler une indirection inutile, mais le relais fournit des services essentiels. Il entretient des relations avec les principaux fournisseurs d'email. Il gère la réputation des IP à travers tous ses clients. Il traite correctement l'authentification (SPF, DKIM, DMARC). Il implémente une logique de reprise adéquate pour les échecs temporaires. Il gère la limitation de débit pour éviter de submerger les serveurs des destinataires.
Votre application n'a qu'à remettre l'email. Le relais s'occupe du reste.
Le terme « relais » peut désigner différentes choses selon le contexte. Un relais SMTP est tout serveur qui transfère des emails. Un smart host est un relais qu'un serveur de messagerie est configuré pour utiliser afin d'acheminer tout l'email sortant. Les services d'email transactionnel comme SendGrid, Mailgun ou Amazon SES sont essentiellement des services de relais managés avec des fonctionnalités supplémentaires.
Pourquoi les applications ont besoin de relais
Envoyer des emails directement depuis des serveurs d'application engendre des problèmes que les relais résolvent.
L'enjeu principal est la réputation des IP. Les fournisseurs d'email évaluent les expéditeurs d'après l'historique de leurs adresses IP. Une nouvelle IP sans historique est traitée avec suspicion. Une IP qui a envoyé du spam (même via des locataires précédents dans un environnement cloud) est bloquée. Construire et maintenir une réputation d'IP exige un volume d'envoi constant et de bonnes pratiques dans le temps — ce que la plupart des applications ne peuvent pas fournir.
La configuration de l'authentification est complexe. Les enregistrements SPF doivent autoriser vos IP d'envoi. DKIM nécessite la génération de clés, des enregistrements DNS et une signature correcte. DMARC rassemble le tout. Réussir cela sur des serveurs d'application, surtout dans des environnements cloud dynamiques où les IP changent, est difficile.
La gestion de la délivrance demande de la sophistication. Quand un serveur destinataire retourne une erreur temporaire, il faut réessayer avec un backoff approprié. Quand il vous limite, il faut ralentir. Quand il rejette de manière permanente, il faut arrêter d'essayer. Implémenter cela correctement n'est pas trivial.
La supervision et le debugging exigent de l'infrastructure. Quand les emails échouent, il faut savoir pourquoi. Les relais fournissent des logs, des analyses et des outils de debugging qui seraient coûteux à construire soi-même.
Types de relais de messagerie
Différentes configurations de relais répondent à des besoins distincts.
Les services d'email transactionnel managés (SendGrid, Mailgun, Postmark, Amazon SES) sont le choix le plus courant pour les applications. Ils proposent des API et des endpoints SMTP, prennent en charge toute la complexité de la livraison et offrent des outils d'analyse et de debugging. Vous payez en fonction du volume.
Les relais auto-hébergés (Postfix, Exim configurés en relais) vous donnent du contrôle mais demandent de l'expertise. Vous gérez les serveurs, maintenez la réputation, configurez l'authentification. Cela a du sens pour des organisations avec des exigences de conformité spécifiques ou des volumes très élevés où les coûts des services managés deviennent significatifs.
Les relais des FAI ou des hébergeurs sont parfois disponibles dans des offres d'hébergement. La qualité varie énormément. Certains sont bien maintenus; d'autres sont partagés avec des spammeurs et ont une réputation catastrophique. Évaluez soigneusement avant de vous y fier.
Les relais internes au sein des organisations acheminent les emails entre les systèmes internes et l'extérieur. Ils peuvent ajouter des en-têtes de conformité, analyser les données sensibles ou appliquer des politiques. Ils transfèrent généralement vers un autre relais ou directement vers les destinataires.
Relais SMTP vs API
Les services d'email modernes offrent deux façons d'envoyer : relais SMTP et API HTTP. Les deux atteignent le même objectif mais fonctionnent différemment.
Le relais SMTP utilise le protocole de messagerie traditionnel. Votre application se connecte au serveur SMTP du relais, s'authentifie et envoie l'email à l'aide des commandes SMTP standard. Cela fonctionne avec tout système capable d'envoyer des emails — applications legacy, plugins WordPress, équipements réseau, tout ce qui supporte SMTP.
Les API HTTP sont plus modernes. Votre application effectue une requête HTTP POST avec le contenu de l'email en JSON ou en données de formulaire. C'est souvent plus facile à intégrer dans des applications web, fournit des réponses d'erreur plus riches et peut offrir des fonctionnalités au-delà de l'envoi d'email basique.
Pour les nouvelles applications, les API sont généralement préférables. Elles sont plus simples à utiliser, fournissent de meilleurs retours et s'intègrent naturellement aux pratiques de développement modernes. Pour les systèmes legacy ou les équipements qui ne supportent que SMTP, l'accès relais est essentiel.
De nombreux services proposent les deux, vous laissant choisir selon vos besoins. Certaines fonctionnalités peuvent n'être disponibles qu'à travers une des interfaces ou l'autre.
Configurer les applications pour utiliser des relais
La plupart des applications et frameworks ont une configuration de relais simple.
Pour un relais SMTP, vous configurez généralement : le nom d'hôte du relais, le port (habituellement 587 pour la soumission avec TLS), les identifiants d'authentification (nom d'utilisateur et mot de passe ou clé API), et les paramètres TLS. L'application envoie ensuite tout l'email sortant via ce relais.
Pour une intégration API, vous utilisez le SDK du service ou effectuez des requêtes HTTP directement. La configuration implique des clés API et des URLs d'endpoint. L'intégration demande généralement plus de code mais offre plus de contrôle et un meilleur traitement des erreurs.
La configuration spécifique à l'environnement est importante. Les environnements de développement peuvent utiliser un service comme Mailtrap qui capture les emails sans les délivrer. La préproduction peut utiliser le relais de production mais envoyer vers des adresses de test. La production utilise le vrai relais avec une livraison réelle.
La gestion des identifiants compte. Les clés API et les mots de passe SMTP doivent être stockés de manière sécurisée, pas en dur dans le code. Utilisez des variables d'environnement ou des systèmes de gestion de secrets. Renouvelez les identifiants périodiquement.
Quand utiliser votre propre relais
La plupart des applications devraient utiliser des services de relais managés. Mais certaines situations justifient d'exploiter le vôtre.
Un volume extrême peut rendre les services managés coûteux. Si vous envoyez des centaines de millions d'emails par mois, les coûts par email s'additionnent. Exploiter votre propre infrastructure peut être plus économique, mais vous échangez de l'argent contre de la complexité opérationnelle.
Des exigences de conformité imposent parfois le contrôle de l'infrastructure d'email. Les organisations de santé, de finance et gouvernementales peuvent devoir garantir que les emails ne passent jamais par des systèmes tiers, ou avoir besoin de capacités d'audit spécifiques que les services managés n'offrent pas.
Des exigences techniques spécifiques peuvent ne pas être satisfaites par les services managés. Des schémas d'authentification personnalisés, des protocoles inhabituels ou une intégration à des systèmes legacy peuvent nécessiter une solution auto-hébergée.
Si vous exploitez votre propre relais, attendez-vous à une charge opérationnelle significative. Vous devrez gérer la réputation des IP, traiter les problèmes de listes noires, maintenir la configuration d'authentification, superviser la délivrance et rester à jour des normes d'email en évolution. C'est un ensemble de compétences spécialisé.
Considérations de sécurité pour les relais
Les relais sont des cibles attrayantes pour les abus. Un relais compromis peut envoyer du spam qui endommage votre réputation et peut vous faire inscrire sur des listes noires.
L'authentification est essentielle. Ne faites jamais fonctionner un relais ouvert qui accepte les emails de n'importe qui. Exigez une authentification pour tous les envois. Utilisez des identifiants robustes et renouvelez-les périodiquement.
La limitation de débit empêche les abus en cas d'identifiants compromis. Si un attaquant obtient un jeu d'identifiants, les limites de débit contiennent les dégâts pendant que vous répondez.
La supervision des anomalies permet de détecter rapidement les problèmes. Des pics soudains de volume, des schémas de destinataires inhabituels ou des envois à des heures anormales peuvent indiquer une compromission. Déclenchez des alertes sur ces schémas.
La vérification des expéditeurs garantit que seules les adresses autorisées peuvent envoyer. Si votre relais est censé envoyer depuis @yourcompany.com, rejetez les tentatives d'envoi depuis d'autres domaines.
Frequently asked questions
Utiliser un relais, est-ce la même chose que le transfert d'email ?
Pas tout à fait. Le transfert prend un email reçu et l'envoie ailleurs. Le relais prend un email d'une application ou d'un serveur et le délivre aux destinataires. Le relais fait partie du chemin d'envoi, pas du chemin de réception.
Utiliser un relais va-t-il améliorer ma délivrabilité ?
Généralement oui, de façon significative. Les bons services de relais maintiennent une forte réputation d'IP, gèrent correctement l'authentification et pilotent la livraison de manière professionnelle. Cela surpasse presque toujours ce que des serveurs d'application peuvent faire directement.
Puis-je utiliser Gmail ou Outlook comme relais ?
Les services d'email grand public ont des limites d'envoi strictes et ne sont pas conçus pour un usage applicatif. Google Workspace et Microsoft 365 proposent des fonctionnalités de relais SMTP pour leurs clients, mais avec des limitations. Pour de l'email applicatif sérieux, utilisez un service dédié.
Quelle est la différence entre un relais et un MTA ?
Un MTA (Mail Transfer Agent) est tout serveur qui transfère des emails. Un relais est un MTA spécifiquement configuré pour transmettre les emails provenant d'autres systèmes, plutôt que d'être l'origine ou la destination finale. Tous les relais sont des MTA, mais tous les MTA ne sont pas des relais.