Envoyer les emails de son SaaS soi-même : retour d'expérience d'un SMTP souverain

Les emails transactionnels — confirmation d'inscription, réinitialisation de mot de passe, notification de lead — sont le système nerveux d'un SaaS. L'écrasante majorité des équipes les confie à un fournisseur spécialisé, et c'est un choix raisonnable. Nous avons pris l'autre route : notre propre relais SMTP, auto-hébergé, aligné avec le reste de notre infrastructure. Ce retour d'expérience documente ce que cette route demande vraiment — pour que vous choisissiez la vôtre en connaissance de cause.

Pourquoi sortir du provider

Trois raisons, cohérentes avec notre philosophie d'infrastructure :

• Cohérence de souveraineté : nos données restent sur nos machines européennes ; il était paradoxal que chaque email — qui contient des adresses, des noms, parfois des contenus métier — transite par un tiers.
• Coût à l'échelle : les fournisseurs facturent au volume ; un relais auto-hébergé coûte le prix d'un petit serveur, quel que soit le volume raisonnable.
• Maîtrise du chemin critique : quand un email n'arrive pas, nous voulons lire les journaux du bout en bout, pas ouvrir un ticket.

En face, ce que le provider apportait et qu'il faut reconstruire : la réputation d'envoi, la surveillance de la délivrabilité, et l'expertise anti-spam accumulée. C'est le vrai prix du choix — le logiciel, lui, est la partie facile.

La délivrabilité, ou l'art de prouver qu'on n'est pas un spammeur

Un email auto-envoyé sans configuration finit en spam, ou n'arrive pas du tout. Trois enregistrements DNS forment le socle de la confiance :

SPF déclare quels serveurs ont le droit d'envoyer pour votre domaine. DKIM signe cryptographiquement chaque message — le destinataire vérifie que le contenu vient bien de vous et n'a pas été altéré. DMARC dit quoi faire des messages qui échouent aux deux contrôles, et vous envoie des rapports.

; SPF : seul ce serveur envoie pour pykengine.example
@        IN TXT  "v=spf1 ip4:203.0.113.10 -all"

; DKIM : la clé publique qui vérifie nos signatures
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; DMARC : rejeter ce qui échoue, nous envoyer les rapports
_dmarc   IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@pykengine.example"

Deux pièges vécus, cadeaux au lecteur : le -all de SPF (strict) se vérifie après avoir inventorié tous les émetteurs légitimes — l'outil de newsletter oublié, et ses envois meurent silencieusement ; et certains registrars pré-remplissent des enregistrements qui entrent en conflit avec les vôtres. Vérifiez le résultat effectif (avec dig), pas l'intention dans l'interface.

Les surprises d'infrastructure

Le port 25 est fermé presque partout. Les fournisseurs d'accès grand public et la plupart des hébergeurs cloud bloquent le port d'envoi SMTP sortant par défaut, précisément pour lutter contre le spam. Selon l'hébergeur, l'ouverture se demande (avec justification) ou se contourne en relayant par un port soumis à authentification. À découvrir avant de promettre la mise en production, pas le soir de la bascule — nous en témoignons.

La réputation IP se construit et se surveille. Une adresse IP neuve n'a pas d'historique : les gros webmails la traitent avec méfiance. Il faut chauffer progressivement (volumes croissants), s'inscrire aux boucles de rétroaction des grands fournisseurs, et surveiller en continu les listes noires publiques. Chez nous, cette surveillance est branchée sur le même système d'alertes que le reste de la supervision : une IP listée est un incident, pas une découverte fortuite trois semaines plus tard.

La boîte de réception se teste en vrai. Nos recettes incluent l'envoi réel vers les principaux webmails et la lecture des en-têtes d'authentification reçus (spf=pass, dkim=pass, dmarc=pass) — pas seulement « le serveur a accepté le message ».

À qui nous déconseillons cette route

Le tableau honnête : si vos emails partent par dizaines de milliers, si votre équipe n'a personne pour surveiller une réputation d'envoi, ou si l'email est marketing (newsletters, campagnes — un métier en soi, avec des exigences de désinscription et de segmentation), un fournisseur spécialisé vous servira mieux. Le SMTP souverain a du sens pour du transactionnel à volume maîtrisé, adossé à une équipe qui opère déjà son infrastructure — notre cas. C'est un choix d'artisan, pas une économie de raccourci.

Ce qu'il faut retenir

Envoyer ses emails soi-même est parfaitement faisable en 2026, à trois conditions : un socle d'authentification complet (SPF, DKIM, DMARC — vérifié sur pièces), une infrastructure qui a réglé la question du port 25 et de la réputation IP, et une surveillance des blacklists intégrée à votre supervision. Si l'une des trois manque, le provider n'est pas une faiblesse : c'est le bon outil. Dans les deux cas, le principe qui reste : l'email transactionnel est un chemin critique — traitez-le avec le même sérieux que votre base de données.