Pourquoi les agences ont besoin d'une plateforme SMTP
Gérer l'envoi email d'un portefeuille client avec Postfix, c'est naviguer sans instruments. Le MTA fait passer le message ou non, mais il ne dit pas pourquoi un bounce se produit, quelle campagne a dégradé la réputation d'un domaine, ni quel client consomme le plus de ressources d'envoi.
Pour une agence qui gère 10, 20 ou 50 domaines clients, cette opacité est un risque opérationnel direct. Un seul client mal configuré peut entraîner la mise en liste noire de l'IP partagée et pénaliser l'ensemble du portefeuille. Et lorsque le client appelle pour signaler un problème, vous n'avez rien à lui montrer.
Postal résout ce problème en ajoutant une couche de contrôle complète au-dessus du pipeline SMTP.
Ce que Postal apporte à votre agence
- Interface web multi-serveurs : créez un serveur d'envoi isolé par client ou par projet, avec ses propres credentials SMTP et API.
- Statistiques par serveur d'envoi : volumes entrant et sortant et bounces, en graphes sur 24 h, 48 h ou 30 jours — un serveur par client donne une vue par client.
- Gestion des bounces en temps réel : chaque échec de livraison est enregistré et classé (
SoftFailtemporaire,HardFaildéfinitif), chaque bounce reçu est rattaché au message d'origine, consultable dans l'interface et transmis via webhook à votre application. - API REST et webhooks : intégrez Postal à votre CRM, votre plateforme e-commerce ou votre outil de facturation — un endpoint d'envoi, des événements en retour.
- Files de messages : les envois sont mis en file d'attente et traçables jusqu'à l'accusé de réception ou l'erreur finale, sans boîte noire.
- Isolation des clients : chaque serveur Postal peut recevoir son propre pool d'IP (option
use_ip_pools) et sa propre limite d'envoi — avec des IP distinctes, un client en difficulté n'affecte pas la réputation des autres. - Licence MIT : code source ouvert, aucun coût par email, aucune dépendance à un prestataire tiers.
Prérequis : VPS, port 25 et IPv4 dédiée
Postal v3.3.7 s'installe via Docker. Les prérequis officiels sont les suivants :
Ressources : au moins 2 vCPU et 4 Go de RAM. La documentation recommande fortement un serveur dédié à Postal, sans autre logiciel. Prévoir au moins 25 Go de stockage SSD — les logs de messages peuvent croître rapidement selon la durée de rétention configurée.
Système d'exploitation : toute distribution qui exécute Docker Engine et le plugin Docker Compose (ce guide utilise Ubuntu 24.04 LTS), avec git, curl et jq.
Base de données : MariaDB 10.6 ou supérieur — la branche 10.6 n'étant plus maintenue par la communauté depuis juillet 2026, visez 10.11 ou plus récent. MySQL n'est explicitement pas supporté. Le paramètre innodb_log_file_size doit être configuré à au moins 10 fois la taille maximale d'un message.
Port 25 : c'est le point critique. Le port 25 outbound doit être ouvert pour que Postal puisse livrer les messages aux serveurs destinataires. De nombreux hébergeurs cloud le bloquent par défaut — vérifiez que votre VPS dispose d'une IPv4 dédiée et d'un port 25 débloqué avant de commencer l'installation.
rDNS : le reverse DNS de votre IPv4 doit pointer vers votre hostname Postal (ex. postal.votre-agence.com). Un PTR absent ou incorrect fait rejeter vos messages : Gmail exige depuis février 2024 un PTR valide pour toute IP d'envoi.
Installation de Postal sur VPS
Préparer le serveur et installer Docker
Connectez-vous en root sur votre VPS Ubuntu 24.04, mettez à jour les paquets, puis installez Docker Engine et le plugin Compose :
apt update && apt upgrade -y curl -fsSL https://get.docker.com | sh apt install -y git curl jq docker --version && docker compose versionVérifiez que le port 25 est bien ouvert en sortie depuis votre serveur :
nc -zv smtp.gmail.com 25. Si la connexion échoue, contactez votre hébergeur pour le débloquer.Configurer le DNS de votre serveur Postal
Avant le bootstrap, créez les enregistrements DNS pour le domaine de votre installation Postal (ex.
postal.votre-agence.com) :- Enregistrement A :
postal.votre-agence.com→ IP de votre VPS
- rDNS (PTR) : configurez-le dans votre espace client pour que votre IP pointe verspostal.votre-agence.com
- SPF global (TXT surspf.postal.votre-agence.com) :v=spf1 ip4:<IP_VPS> ~all
- Return path :rp.postal.votre-agence.comavec un A vers l'IP, un MX10 postal.votre-agence.com, un TXTv=spf1 a mx include:spf.postal.votre-agence.com ~allet, après le bootstrap, le DKIM affiché parpostal default-dkim-recordsurpostal._domainkey.rp.postal.votre-agence.comAttendez la propagation DNS (15 à 30 minutes) avant de continuer.
Bootstrapper la configuration Postal
Clonez le dépôt d'installation officiel, qui fournit la commande
postal, puis générez la configuration :git clone https://github.com/postalserver/install /opt/postal/install ln -s /opt/postal/install/bin/postal /usr/bin/postal postal bootstrap postal.votre-agence.comCette commande génère dans
/opt/postal/configles fichierspostal.yml(configuration principale),signing.key(clé de signature) etCaddyfile, ainsi qu'undocker-compose.yml(dans/opt/postal/install) épinglé sur la dernière version publiée. Ouvrezpostal.ymlet renseignez les credentials MariaDB, le SMTP de notification et les noms DNS de votre installation (sectiondns).Démarrer MariaDB et initialiser la base
Lancez un conteneur MariaDB dédié, joignable uniquement en local et protégé par un mot de passe généré, puis initialisez le schéma Postal :
openssl rand -hex 24 > /root/postal-db.pass && chmod 600 /root/postal-db.pass docker run -d --name postal-mariadb \ -p 127.0.0.1:3306:3306 \ -e MARIADB_ROOT_PASSWORD="$(cat /root/postal-db.pass)" \ -e MARIADB_DATABASE=postal \ --restart always mariadb:10.11 postal initializeReportez ce mot de passe dans les sections
main_dbetmessage_dbdepostal.ymlavantpostal initialize. Cette étape crée les tables, les index et la configuration initiale en base.Créer le premier utilisateur admin
Créez votre compte administrateur pour accéder à l'interface web :
postal make-userSaisissez l'adresse email, le nom et le mot de passe de l'administrateur. Ces identifiants permettront de se connecter à
https://postal.votre-agence.com.Démarrer Postal et configurer le reverse proxy
Lancez tous les services Postal (web, workers, SMTP) :
postal start postal statusPostal expose l'interface web sur
127.0.0.1:5000, injoignable depuis Internet. Placez un reverse proxy (Caddy ou nginx) devant pour terminer le TLS. Exemple minimal avec Caddy et leCaddyfilegénéré par le bootstrap :docker run -d --name postal-caddy \ --restart always --network host \ -v /opt/postal/config/Caddyfile:/etc/caddy/Caddyfile \ -v /opt/postal/caddy-data:/data \ caddy:latestAccédez à
https://postal.votre-agence.comet connectez-vous avec les identifiants créés à l'étape précédente.Créer une organisation et un premier serveur d'envoi
Dans l'interface Postal, créez une organisation (votre agence), puis un serveur d'envoi pour votre premier client. Chaque serveur dispose de ses propres credentials SMTP, de sa propre clé API et de ses propres domaines expéditeurs — c'est l'unité d'isolation par client.
Notez le nom d'hôte SMTP, le port (25 par défaut, modifiable via
smtp_server.default_port) et les credentials générés : ce sont les informations à transmettre à l'application cliente ou à configurer dans son panel d'envoi.
Configuration d'un domaine expéditeur
Dans chaque serveur d'envoi Postal, ajoutez les domaines depuis lesquels vos clients enverront des emails. Pour chaque domaine, Postal génère automatiquement une paire de clés RSA 1024 bits et un sélecteur DKIM unique (format postal-XXXXXX._domainkey).
Les enregistrements DNS à publier pour chaque domaine client :
SPF — ajoutez include:spf.postal.votre-agence.com dans le TXT apex du domaine :
v=spf1 include:spf.postal.votre-agence.com ~allDKIM — publiez la valeur TXT affichée dans l'interface au sous-domaine généré :
postal-XXXXXX._domainkey.domaine-client.com TXT "v=DKIM1; t=s; h=sha256; p=<clé publique>"Return Path (recommandé) — un CNAME qui reçoit les bounces et aligne le SPF pour DMARC :
psrp.domaine-client.com CNAME rp.postal.votre-agence.comPostal vérifie automatiquement ces enregistrements toutes les heures et signale dans l'interface si l'un d'eux est manquant ou incorrect. Le bouton Vérifier mes enregistrements permet une vérification manuelle immédiate.
DMARC : la dernière pièce de la délivrabilité
SPF et DKIM en place, ajoutez une politique DMARC sur chaque domaine client pour signaler aux récepteurs la conduite à tenir en cas d'échec d'alignement. Commencez en mode surveillance (p=none) pour collecter les rapports sans risque de blocage, puis durcissez progressivement vers p=quarantine et p=reject :
_dmarc.domaine-client.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"L'attribut rua envoie les rapports agrégés quotidiens à votre adresse — vous y verrez quelles sources envoient en votre nom, légitimes ou non. Postal signe chaque message avec la clé DKIM du domaine dès que son enregistrement est validé, et le return path psrp aligne le SPF : sur vos domaines correctement configurés, le DMARC passera dès le premier jour.
Gestion des bounces et statistiques
C'est la différence la plus visible entre Postal et un Postfix brut. Dans l'onglet Messages de chaque serveur d'envoi, chaque email envoyé est tracé avec son statut : Pending, Sent, Held, SoftFail, HardFail, Bounced.
Lorsqu'une livraison échoue ou qu'un bounce revient, Postal :
1. Enregistre la raison exacte du rejet dans le journal du message (ex. 550 5.1.1 The email account does not exist)
2. Met à jour le statut de l'envoi dans l'interface (HardFail si le serveur destinataire refuse pendant la session SMTP, Bounced si un message de retour arrive après coup)
3. Déclenche un événement webhook (MessageDeliveryFailed ou MessageBounced) vers l'endpoint HTTP que vous avez configuré
Schématiquement, l'échec d'une livraison se lit ainsi (exemple simplifié) :
[2026-10-15 09:14:22] Delivery attempt to mx1.example.com (203.0.113.10:25)
[2026-10-15 09:14:22] << 550 5.1.1 <[email protected]> User unknown
[2026-10-15 09:14:22] Message marked as HardFail (permanent)Les statistiques par serveur d'envoi affichent, sur 24 h, 48 h ou 30 jours, le volume entrant, le volume sortant et les bounces. Ces données permettent de détecter un problème de délivrabilité avant que le client ne le remarque lui-même.
Postal vs solutions SaaS vs Postfix relay
Faites défiler le tableau
| Critère | Postal (self-hosted) | Mailgun / Postmark | SMTP relay Postfix |
|---|---|---|---|
| Visibilité | Interface complète : journal par message, bounce log, statistiques par serveur d'envoi | Dashboard SaaS, durée de rétention des logs selon le plan | Aucune interface — logs système uniquement |
| Coût | VPS + temps d'administration (aucun coût par email) | Facturation selon le volume d'envoi (voir la grille de chaque prestataire) | VPS uniquement (aucun coût logiciel) |
| Contrôle | Total : IP, rétention, politique de bounce, isolation par client | Partiel : politiques imposées par le prestataire, IP mutualisées par défaut | Complet sur le routage, zéro sur la visibilité |
| Limite d'envoi | Limitée par les ressources du VPS et la réputation des IP — scalable | Quotas selon le plan, montée en charge facturée | Limitée par le VPS — pas de gestion native des quotas par domaine |
Une infrastructure email que vous contrôlez
Postal est l'outil que les agences cherchent quand elles réalisent que Postfix ne suffit plus à opérer un portefeuille client. La plateforme apporte la visibilité qui manque — logs structurés, bounces tracés, statistiques par serveur d'envoi — sans les contraintes tarifaires et les dépendances des SaaS.
Un VPS avec 2 vCPU, 4 Go de RAM et une IPv4 dédiée suffit pour démarrer. Le port 25 débloqué et un rDNS correctement configuré sont les deux prérequis que beaucoup d'hébergeurs ne remplissent pas d'office — vérifiez-les avant de commander.
Les articles SMTP relay Postfix sur VPS et délivrabilité sur VPS : port 25, DKIM et PTR complètent ce guide pour couvrir la délivrabilité dans son ensemble.
