Postal self-hosted : alternative SendGrid open-source — déploiement 2026

Introduction

Vous gérez une startup ou une PME en Afrique de l’Ouest et vous envoyez des emails transactionnels — confirmations de commande, réinitialisations de mot de passe, newsletters — via SendGrid ou Mailgun. Le modèle freemium vous laisse 100 emails par jour, puis la facture grimpe : 20 $ pour 50 000 emails, 90 $ pour 200 000. Pour une entreprise dont les revenus sont en FCFA et dont les marges sont serrées, cette dépendance à une infrastructure américaine facturée en dollars est une vulnérabilité réelle.

Postal change la donne. C’est un serveur MTA (Mail Transfer Agent) open-source écrit en Ruby on Rails, maintenu activement par la communauté sur github.com/postalserver/postal et documenté sur docs.postalserver.io. Postal gère aussi bien les emails transactionnels que les campagnes marketing, offre un tableau de bord web complet, une API HTTP, des webhooks de bounces, le suivi des ouvertures et des clics, le support multi-organisations — tout ce que font SendGrid ou Mailgun, mais installé sur votre propre serveur, pour le prix d’un VPS.

Ce tutoriel vous guide de zéro à un Postal fonctionnel en moins de 60 minutes : déploiement Docker Compose sur un Hetzner CX31, configuration DNS complète (SPF, DKIM, DMARC), création de votre premier serveur d’envoi, test via l’API, gestion des webhooks et plan de warming IP sur 30 jours. Niveau requis : sysadmin Linux intermédiaire, familier avec Docker et les enregistrements DNS.

Prérequis

Avant de commencer, vérifiez que vous disposez des éléments suivants. Certains sont bloquants si absents — ne sautez pas cette section.

Infrastructure : un VPS Hetzner CX31 (2 vCPU, 8 Go RAM, 80 Go SSD, Ubuntu 22.04 LTS) avec une adresse IPv4 dédiée et propre, jamais utilisée pour de l’envoi d’email. Hetzner est choisi ici car leur politique permet l’ouverture du port 25 sur demande explicite au support — contrairement à AWS, Google Cloud ou Azure qui bloquent le port 25 de façon permanente. Soumettez votre demande de déblocage du port 25 à Hetzner avant de commencer l’installation, car le délai de traitement peut prendre 24 à 48 heures.

DNS : un nom de domaine dont vous contrôlez les enregistrements DNS, avec un TTL que vous pouvez descendre à 300 secondes le temps de la configuration. Vous aurez besoin de créer des enregistrements A, MX, TXT (SPF, DKIM, DMARC) et PTR (reverse DNS). Le PTR — enregistrement de reverse DNS associant votre IP à un hostname — est configuré dans le panneau Hetzner Cloud directement sur l’interface réseau du serveur.

Logiciels : Docker Engine 24.x minimum et Docker Compose v2 (plugin, pas la version standalone). Vérifiez avec docker compose version — la commande doit répondre sans erreur. Git est requis pour cloner le dépôt d’installation officiel.

Temps estimé : environ 60 minutes pour un déploiement propre, DNS exclu (la propagation DNS peut prendre jusqu’à quelques heures selon votre registrar).

Étape 1 — Architecture de Postal : comprendre les composants

Avant de lancer le moindre conteneur, il est utile de comprendre ce que vous allez déployer. Postal n’est pas un service monolithique : c’est un ensemble de processus qui collaborent, chacun ayant un rôle précis. Confondre ces rôles, c’est s’exposer à des pannes difficiles à diagnostiquer.

L’application Rails est le cœur de Postal. Elle expose l’interface web d’administration (tableau de bord, organisations, serveurs, messages, statistiques) et l’API HTTP sur le port 5000 par défaut. C’est là que vous créez vos organisations, configurez vos domaines d’envoi, générez vos clés API et visualisez les logs de livraison en temps réel.

Sidekiq est le gestionnaire de tâches asynchrones de Rails. Il traite en arrière-plan les files de messages à envoyer, les retries après échec temporaire (soft bounce), les mises à jour de statut et les appels de webhooks. Sans Sidekiq qui tourne, les emails restent en queue indéfiniment — c’est la première chose à vérifier si vos emails ne partent pas.

Le SMTP worker est le processus qui se connecte effectivement aux serveurs de destination (Gmail, Yahoo, Orange) via le port 25 et négocie la livraison SMTP. Il tourne en parallèle de Rails et gère les connexions sortantes, les timeouts, les erreurs de livraison et les logs de trace.

MariaDB est la base de données relationnelle qui stocke toutes les données persistantes : organisations, serveurs, domaines, messages, événements, webhooks. Postal supporte MariaDB 10.x — n’utilisez pas MySQL 8.x natif, des incompatibilités de collation peuvent survenir.

RabbitMQ est le broker de messages qui assure la communication entre les différents processus de Postal. Les messages à envoyer transitent par RabbitMQ avant d’être pris en charge par le SMTP worker. C’est le bus central — si RabbitMQ est down, toute la chaîne d’envoi s’arrête.

Étape 2 — Déployer Postal via Docker Compose

Postal fournit un dépôt d’installation officiel qui automatise la génération de la configuration Docker Compose et des secrets. C’est la méthode recommandée pour 2026 — elle évite de gérer manuellement les variables d’environnement et les volumes.

Commencez par cloner le dépôt d’installation sur votre serveur Hetzner en SSH :

# Cloner le dépôt d'installation officiel
git clone https://github.com/postalserver/install /opt/postal/install
cd /opt/postal/install

# Copier l'exemple de configuration
cp postal.example.yml postal.yml

Ouvrez postal.yml avec votre éditeur et renseignez au minimum : web_hostname (le FQDN de votre instance Postal, ex. mail.votredomaine.com), main_db (les credentials MariaDB) et message_db (base séparée pour les messages, Postal utilise deux bases distinctes). Générez des mots de passe forts pour les deux bases — vous ne les taperez pas à la main souvent, donc la complexité n’est pas un problème.

# Générer la configuration Docker Compose à partir de postal.yml
postal bootstrap

# Initialiser la base de données (migrations Rails)
postal initialize

# Créer le premier utilisateur administrateur
postal make-user

La commande postal bootstrap génère le fichier docker-compose.yml final dans /opt/postal/ avec tous les services préconfigurés : mariadb, rabbitmq, postal-web, postal-smtp-server, postal-worker. Elle génère également les clés de chiffrement nécessaires à Rails. La commande initialize exécute les migrations de base de données — elle prend environ 2 minutes à la première exécution. Enfin, make-user crée de façon interactive votre premier compte admin.

# Démarrer tous les services en arrière-plan
docker compose -f /opt/postal/docker-compose.yml up -d

# Vérifier que tous les conteneurs sont UP
docker compose -f /opt/postal/docker-compose.yml ps

# Suivre les logs en temps réel (Ctrl+C pour quitter)
docker compose -f /opt/postal/docker-compose.yml logs -f postal-web

Après le démarrage, attendez environ 30 secondes que Rails finisse son initialisation, puis accédez à https://mail.votredomaine.com. Vous devriez voir la page de connexion Postal. Si vous obtenez une erreur de connexion refusée, vérifiez que votre pare-feu autorise le port 443 (ou 5000 si vous n’avez pas encore configuré le reverse proxy HTTPS) et que le conteneur postal-web est bien en état Up.

Étape 3 — Configurer DNS SPF, DKIM et DMARC pour Postal

La configuration DNS est l’étape la plus critique pour la délivrabilité. Un email envoyé sans SPF valide ou sans signature DKIM finira systématiquement en spam chez Gmail et Yahoo depuis février 2024, et la tendance s’est durcie en 2026 avec l’adoption massive de DMARC strict par les grandes messageries. Postal génère automatiquement vos clés DKIM et vous indique exactement quels enregistrements créer — il suffit de les copier dans votre gestionnaire DNS.

Commencez par configurer l’enregistrement PTR (reverse DNS). Dans le panneau Hetzner Cloud, allez dans votre serveur → Réseaux → IPv4 → modifier le PTR. Saisissez le FQDN de votre serveur Postal, par exemple mail.votredomaine.com. Ce PTR doit correspondre exactement à ce que votre serveur annonce dans la commande HELO/EHLO SMTP — c’est une condition sine qua non pour ne pas être rejeté par les serveurs stricts.

Ensuite, dans l’interface Postal, naviguez vers votre serveur d’envoi → DNS. Postal vous affiche les enregistrements à créer, avec les valeurs exactes :

# Enregistrement A — pointe votre hostname vers l'IP du serveur
mail.votredomaine.com.    IN  A     X.X.X.X

# Enregistrement MX — nécessaire si vous recevez aussi des bounces
votredomaine.com.         IN  MX    10  mail.votredomaine.com.

# SPF — autorise votre serveur à envoyer pour votre domaine
# Postal génère un sous-domaine spf centralisé pour les organisations
spf.postal.votredomaine.com.  IN  TXT  "v=spf1 ip4:X.X.X.X ~all"
votredomaine.com.         IN  TXT  "v=spf1 include:spf.postal.votredomaine.com ~all"

# DKIM — clé publique générée par Postal (nom de sélecteur fourni dans l'interface)
postal._domainkey.votredomaine.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIj..."

# DMARC — politique d'alignement
_dmarc.votredomaine.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@votredomaine.com; ruf=mailto:dmarc@votredomaine.com; fo=1"

# Return-Path — domaine de rebond pour les bounces
return.votredomaine.com.  IN  MX    10  mail.votredomaine.com.
return.votredomaine.com.  IN  TXT  "v=spf1 mx ~all"

Une fois les enregistrements propagés (attendez au minimum 15 minutes, idéalement 1 heure), retournez dans Postal → serveur → DNS et cliquez sur le bouton de vérification. Postal interroge lui-même les serveurs DNS pour confirmer que chaque enregistrement est correct. Tous les voyants doivent passer au vert avant de continuer — un DKIM invalide ou un SPF mal aligné rendra tous vos emails suspects dès le premier envoi.

Étape 4 — Créer votre première organisation et premier serveur

Postal structure l’envoi en deux niveaux : les organisations et les serveurs. Une organisation correspond typiquement à une entité cliente ou à un projet (ex. « Boutique Dakar », « Newsletter IT »). Un serveur est une configuration d’envoi au sein d’une organisation, avec son propre pool d’IP, ses propres domaines, ses propres clés API et ses propres limites de débit. Cette architecture multi-tenant est l’une des grandes forces de Postal par rapport à une installation Postfix nue.

Dans l’interface web Postal, connectez-vous avec le compte admin créé à l’étape 2. Cliquez sur New Organization, donnez-lui un nom court (sans espaces), puis cliquez sur New Server dans l’organisation nouvellement créée. Choisissez le mode Live (pas Development qui envoie tout vers un piège local). Assignez-lui le pool d’IP disponible (celui de votre VPS Hetzner).

Dans la configuration du serveur, ajoutez votre domaine d’envoi sous l’onglet Domains. Postal vous montrera alors les enregistrements DNS spécifiques à ce domaine — notamment le sélecteur DKIM propre à ce serveur. Ajoutez également un Return Path Domain : c’est le domaine qui apparaîtra dans l’en-tête Return-Path de vos emails et qui recevra les bounces. Utilisez un sous-domaine dédié (ex. return.votredomaine.com) pour isoler les bounces du domaine principal.

Étape 5 — Générer une clé API et envoyer via curl

Postal expose une API HTTP simple qui permet d’envoyer des emails programmatiquement depuis n’importe quel langage ou outil. C’est cette API que vos applications Rails, Laravel, Node.js ou Python utiliseront en remplacement du SDK SendGrid.

Pour générer une clé API, allez dans votre serveur Postal → Credentials → New API Credential. Donnez-lui un nom descriptif (ex. « app-production »), choisissez le type API et copiez la clé générée — elle n’est affichée qu’une seule fois.

Testez l’envoi immédiatement avec curl pour valider l’ensemble de la chaîne :

curl -X POST https://mail.votredomaine.com/api/v1/send/message \
  -H "X-Server-API-Key: votre-cle-api" \
  -H "Content-Type: application/json" \
  -d '{
    "mail_from": "noreply@votredomaine.com",
    "rcpt_to": ["test@exemple.com"],
    "subject": "Test Postal self-hosted",
    "plain_body": "Bonjour, ceci est un email de test envoyé via Postal.",
    "html_body": "
Bonjour, ceci est un email de test envoyé via Postal.
"
  }'

Si tout fonctionne, l’API renvoie un JSON contenant un message_id et le statut queued. Cela signifie que l’email a été accepté par Postal et remis à la queue Sidekiq pour livraison. Retournez dans l’interface web → Messages pour suivre le statut en temps réel : queued → sending → delivered (ou soft-fail / hard-fail avec le message d’erreur SMTP complet). Si vous voyez le statut rester bloqué sur queued plusieurs minutes, vérifiez que le conteneur Sidekiq tourne bien et que RabbitMQ est accessible.

Étape 6 — Configurer les webhooks bounces et complaints

Gérer les bounces et les plaintes est indispensable pour maintenir une bonne réputation d’envoyeur. Un taux de hard bounce supérieur à 2 % ou un taux de plaintes supérieur à 0,1 % suffisent pour déclencher des limitations chez Gmail et Yahoo en 2026. Postal gère nativement les bounces via le Return-Path et les plaintes via les FBL (Feedback Loop), et il peut vous notifier en temps réel via webhooks HTTP.

Dans votre serveur Postal → Webhooks → New Webhook, saisissez l’URL de votre endpoint applicatif (ex. https://votre-app.com/webhooks/postal) et sélectionnez les événements à écouter. Les événements les plus importants sont : MessageDelivered, MessageBounced, MessageDelayed, MessageHeld.

Côté réception, votre endpoint doit répondre avec un HTTP 200 en moins de 5 secondes. Postal envoie un POST JSON de cette forme :

{
  "event": "MessageBounced",
  "timestamp": 1714204800,
  "payload": {
    "message": {
      "id": 1234,
      "token": "abc123",
      "rcpt_to": "destinataire@exemple.com",
      "subject": "Votre commande",
      "status": "HardFail",
      "last_delivery_attempt": 1714204750,
      "output": "550 5.1.1 The email account does not exist"
    }
  }
}

À la réception d’un bounce de type HardFail (code SMTP 5xx), votre application doit immédiatement marquer l’adresse comme invalide dans votre base de données et ne plus jamais tenter de lui envoyer un email. Pour un SoftFail (code 4xx), vous pouvez planifier une nouvelle tentative après 24 heures, mais limitez-vous à 3 essais avant de traiter l’adresse comme invalide. Cette discipline de gestion des listes est le pilier d’une bonne délivrabilité long terme.

Étape 7 — Plan de warming IP sur 30 jours

Une adresse IP fraîche — même sur un excellent hébergeur comme Hetzner — n’a aucune réputation auprès des filtres anti-spam. Si vous envoyez 50 000 emails le premier jour, Gmail et Yahoo vont immédiatement brider ou bloquer votre IP, et Spamhaus va l’inscrire sur sa liste SBL (Spamhaus Block List) dans les heures qui suivent. Le warming IP est un processus incontournable qui consiste à augmenter progressivement le volume d’envoi sur 4 semaines pour que les grandes messageries apprennent à reconnaître votre IP comme une source légitime.

Voici le plan de progression recommandé. Envoyez uniquement vers vos adresses les plus engagées (contacts qui ont ouvert ou cliqué dans les 90 derniers jours) pendant toute la période de warming :

• Semaine 1 : 500 emails/jour maximum. Divisez en 2-3 envois de 150-200 emails répartis dans la journée. Surveillez le dashboard Postal pour détecter tout blocage.
• Semaine 2 : 2 000 emails/jour. Augmentez progressivement si le taux de livraison reste au-dessus de 95 %.
• Semaine 3 : 8 000 emails/jour. À ce stade, vous pouvez commencer à inclure des contacts légèrement moins récents (ouverts dans les 180 jours).
• Semaine 4 : 25 000 emails/jour. Si tout va bien, votre IP a une réputation établie.
• Mois 2 : volume libre, en maintenant un taux de bounces < 2 % et de plaintes < 0,1 %.

Surveillez chaque jour votre réputation IP sur MXToolbox Blacklist Check et Barracuda Central. Consultez également Google Postmaster Tools après avoir vérifié votre domaine — vous y verrez la réputation de votre IP et de votre domaine telle que Google la perçoit, ce qui est l’indicateur le plus fiable disponible gratuitement.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Déployer Postal en Afrique de l’Ouest ou pour une clientèle ouest-africaine implique quelques adaptations spécifiques que les tutoriels européens ignorent systématiquement. La première réalité à intégrer est celle du warming IP obligatoire de 30 jours. Les adresses IP des datacenters Hetzner (Frankfurt, Nuremberg, Helsinki) sont fréquemment neuves ou ayant eu des locataires précédents aux pratiques d’envoi inégales. En 2026, Spamhaus a durci sa politique concernant les requêtes DNS provenant de resolvers Hetzner : assurez-vous de configurer votre serveur pour utiliser un resolver DNS externe de confiance (Cloudflare 1.1.1.1 ou Google 8.8.8.8) plutôt que le resolver par défaut de Hetzner, pour éviter des faux positifs dans les vérifications de blacklist.

La stratégie de fallback est indispensable en production. Si votre IP Postal se retrouve sur une blacklist pendant la période de warming ou après un incident, vous avez besoin d’une solution de secours pour continuer à livrer les emails transactionnels critiques (confirmations de commande, mots de passe). Brevo (anciennement Sendinblue) est recommandé comme fallback car il dispose d’une offre gratuite généreuse (300 emails/jour), d’une API compatible, et fonctionne bien depuis l’Afrique de l’Ouest sans les problèmes de facturation en devises étrangères qui affectent parfois SendGrid ou Mailgun. Configurez votre application pour basculer automatiquement sur Brevo si Postal renvoie une erreur de connexion ou un taux d’échec supérieur à 10 % sur une période d’une heure.

Pour les newsletters, évitez d’utiliser Postal seul — son interface n’est pas optimisée pour la gestion de listes d’abonnés, les désabonnements RGPD et les campagnes. Couplé à Listmonk (application Go open-source de gestion de newsletters, auto-hébergeable sur le même VPS), vous obtenez une stack email complète : Listmonk gère les listes, les templates, les segments, les campagnes et les désabonnements — et utilise Postal comme SMTP de livraison. C’est la combinaison Listmonk + Postal qui remplace le plus efficacement Mailchimp ou Brevo en auto-hébergement.

Pensez également à la bande passante : les pièces jointes lourdes (PDF, images haute résolution) dans les emails transactionnels augmentent vos coûts de transfert et ralentissent la livraison. Hébergez les assets sur un stockage objet (MinIO auto-hébergé ou Cloudflare R2) et incluez des liens dans les emails plutôt que des pièces jointes inline — c’est aussi une meilleure pratique pour la délivrabilité car les emails lourds sont traités avec plus de suspicion par les filtres anti-spam.

Tutoriels frères

• Configurer SPF, DKIM et DMARC sur VPS : guide complet 2026 — tout ce qu’il faut savoir sur les enregistrements DNS d’authentification email, leur logique et leur vérification
• Listmonk self-hosted : gérer vos newsletters open-source — déployer et configurer Listmonk pour vos campagnes email, couplé à Postal comme MTA

Pour aller plus loin

• Retour au pilier : Email pro deliverability 2026 : SPF, DKIM, DMARC, MTA-STS, BIMI, ARC
• Documentation officielle Postal : docs.postalserver.io — référence complète sur l’installation, la configuration, les API et les webhooks
• Code source : github.com/postalserver/postal — issues, changelog, discussions communautaires
• Google Postmaster Tools : postmaster.google.com — monitorer la réputation de votre IP et domaine chez Gmail
• Prochaine étape dans le cluster : après Postal opérationnel, configurez MTA-STS et DANE pour renforcer le chiffrement en transit — tutoriel disponible dans le cluster Email Deliverability.

FAQ

Q : Postal est-il vraiment gratuit ? Y a-t-il des limites d’envoi ?
R : Oui, Postal est entièrement open-source sous licence MIT. Il n’y a aucune limite logicielle d’envoi imposée par l’application — les seules limites sont celles de votre serveur (CPU, RAM, bande passante) et de votre réputation IP. Vous payez uniquement le VPS et le nom de domaine.

Q : Puis-je migrer mes listes SendGrid vers Postal facilement ?
R : Postal ne gère pas les listes d’abonnés directement — c’est intentionnel, son rôle est celui d’un MTA (livraison), pas d’un ESP (gestion de campagnes). Pour migrer, exportez vos listes SendGrid en CSV, importez-les dans Listmonk, et configurez Listmonk pour utiliser Postal comme SMTP. La migration technique prend moins d’une heure ; la période de warming IP prend 30 jours.

Q : Que faire si mon IP est blacklistée sur Spamhaus pendant le warming ?
R : Suspendez immédiatement tous les envois. Identifiez la cause (volume trop élevé, trop de bounces, contenu suspect) et corrigez-la. Soumettez une demande de suppression sur check.spamhaus.org en expliquant les mesures correctives prises. Le délai de suppression est généralement de 24 à 48 heures si la demande est bien motivée. Pendant ce temps, basculez sur votre fallback Brevo pour les emails critiques.

Q : Postal peut-il recevoir des emails en plus d’en envoyer ?
R : Postal est principalement conçu pour l’envoi sortant et la gestion des bounces entrants. Il peut techniquement recevoir des emails (il a un serveur SMTP entrant), mais il n’est pas un serveur IMAP/POP3 — vos utilisateurs ne peuvent pas consulter leur boîte mail via Postal. Pour un serveur email entrant complet, des solutions comme Stalwart Mail Server ou Maddy sont plus adaptées, et peuvent coexister avec Postal sur la même machine avec une gestion soigneuse des ports.

Q : Est-il possible d’utiliser plusieurs IPs d’envoi avec Postal ?
R : Oui, Postal supporte nativement les pools d’IP. Vous pouvez ajouter plusieurs adresses IPv4 à votre serveur Hetzner (en commandant des IPs additionnelles dans le panneau Cloud) et les assigner à différents serveurs Postal ou les utiliser en rotation. Cette fonctionnalité est précieuse pour séparer les flux transactionnels (priorité haute, réputation critique) des newsletters (volume plus élevé, acceptable d’être parfois thottlé).

Q : Comment mettre à jour Postal sans perdre les données ?
R : Avant toute mise à jour, sauvegardez les volumes Docker contenant MariaDB (docker compose exec mariadb mysqldump -u postal -p postal > backup.sql). Tirez la nouvelle image (docker compose pull), relancez (docker compose up -d), puis exécutez les migrations si nécessaire (docker compose exec postal postal upgrade). Consultez le changelog sur GitHub avant chaque mise à jour pour identifier les migrations de base de données ou les changements de configuration incompatibles.

Q : Postal est-il adapté pour envoyer de gros volumes (1 million d’emails/mois) ?
R : Oui, à condition d’avoir le matériel correspondant. Pour 1 million d’emails/mois (environ 33 000/jour), un Hetzner CX41 (4 vCPU, 16 Go RAM) avec un disque SSD rapide est recommandé. Le goulot d’étranglement est généralement MariaDB (optimisez innodb_buffer_pool_size) et le nombre de workers Sidekiq. La documentation officielle donne des recommandations de tuning pour les grandes installations.