--- title: Construire son propre serveur d'e-mailing : architecture, files et réputation source: https://synapx.fr/blog/serveur-emailing-postfix-mailcow-mailu/ date: 2026-07-14 category: Email site: SynapxLab --- # Construire son propre serveur d'e-mailing : architecture, files et réputation Installer Postfix prend moins de temps que construire un programme d'envoi fiable. Le MTA sait accepter un message, le placer en file, résoudre un MX, négocier TLS et réessayer après un échec temporaire. Il ne sait pas, à lui seul, pourquoi Alice est dans la liste, si elle s'est désabonnée, quel commercial a importé le fichier ni quelle commande doit être attribuée à la campagne. Ce billet ne répète donc pas [l'installation de Postfix sous Linux](/blog/postfix/) ni [l'architecture d'une boîte mail avec Dovecot](/blog/boite-mail/). Il traite la couche absente : **l'exploitation d'une plateforme d'envoi**, avec politique, files, retours, réputation et arrêt d'urgence. Il constitue le volet infrastructure du [guide de l'e-mailing professionnel en 2026](/blog/emailing-professionnel-2026/). ## Un serveur d'e-mailing est au moins sept systèmes ```mermaid flowchart LR A["Contacts, preuve,
préférences"] --> B["Segmentation et
planification"] B --> C["Génération MIME
HTML + texte"] C --> D["Passerelle de
soumission"] D --> E["Politique, quotas,
suppression"] E --> F["DKIM et file MTA"] F --> G["Pools sortants
et Internet"] G --> H["MX destinataires"] H --> I["DSN, plaintes,
retraits, événements"] I --> J["Normalisation et
observabilité"] J --> A J --> K["Alertes et
arrêt automatique"] ``` Si la base de contacts parle directement à `sendmail` sans suppression centrale ni retour structuré, ce n'est pas une plateforme : c'est un script qui peut détruire rapidement une réputation. ## Séparer les responsabilités | Composant | Responsabilité | Exemple de panne à contenir | |---|---|---| | Référentiel contacts | preuve, préférences, opposition, durée | réimport d'un désabonné | | Orchestrateur | ciblage, calendrier, pression, idempotence | double envoi après redémarrage | | Générateur MIME | en-têtes, texte, HTML, pièces jointes | message cassé dans Outlook | | Passerelle de soumission | authentifier applications et expéditeurs | compte compromis ou usurpation interne | | MTA | file, DNS, TLS, cadence, livraison | saturation ou tempête de réessais | | Collecteur de retours | DSN, plaintes, unsubscription, webhooks | hard bounce jamais supprimé | | Observabilité | métriques, journaux, alertes, audit | incident invisible pendant des heures | Le même logiciel peut remplir plusieurs rôles, mais les données et les décisions doivent rester explicites. ## Postfix, Exim, Haraka et PowerMTA ### Postfix Postfix est un MTA généraliste, mature et largement documenté. Il convient à la soumission, au relais, à la signature via composants associés, aux filtres de contenu et à la livraison directe ou par smart host. Sa file est robuste, et sa séparation en processus limite la portée de nombreux défauts. Il devient une bonne brique d'e-mailing lorsque l'application située devant lui gère les listes et que l'exploitation sait : - lire `postqueue`/`postcat` et les journaux ; - appliquer des transports et limites par destination ; - distinguer réponse temporaire et échec définitif ; - relier l'identifiant de campagne à l'identifiant de file ; - empêcher tout relais non autorisé ; - mettre à jour sans casser le spool. ### Exim Exim est également un MTA complet, particulièrement configurable avec ses routeurs, transports, ACL et mécanismes de réécriture. Son *queue runner* inspecte périodiquement les messages en attente et tente les livraisons selon la configuration. Cette souplesse est une force pour des règles complexes et un risque si la configuration devient impossible à expliquer. Une plateforme doit versionner les ACL, tester les changements et documenter l'ordre réel des routeurs plutôt que copier une configuration générique. ### Haraka Haraka est un serveur SMTP Node.js construit autour de plugins. Sa documentation décrit une file sortante sur disque, des réessais après échecs temporaires, des connexions mises en pool et des hooks pour choisir un MX, une IP ou un comportement par message. Il convient lorsque l'équipe veut intégrer profondément la logique SMTP en JavaScript et accepte d'exploiter cet écosystème. Haraka n'est pas un serveur IMAP ni une boîte mail ; il s'assemble avec d'autres composants ou sert de passerelle spécialisée. ### PowerMTA PowerMTA est un MTA propriétaire orienté grands volumes. Ses *virtual MTAs*, pools, files par domaine/MX, limites et sorties structurées facilitent l'isolation des flux et le pilotage de cadence. Il ne rend pas une liste légitime et ne fournit pas à lui seul le produit de campagne. Son intérêt apparaît lorsque le volume, le multi-tenant, les SLA et l'équipe délivrabilité justifient la licence et l'exploitation spécialisée. Sans processus de suppression et surveillance, un moteur plus rapide accélère seulement l'incident. ## Tableau de choix | Solution | Nature | Bon cas d'usage | Attention | |---|---|---|---| | Postfix | MTA libre généraliste | Relais, transactionnel, plateforme maîtrisée | Assembler retours, analytics et politique | | Exim | MTA libre très configurable | Routage et ACL complexes | Complexité de configuration | | Haraka | SMTP Node.js à plugins | Passerelle programmable, intégration JS | Ce n'est pas un magasin IMAP | | PowerMTA | MTA propriétaire haut volume | Multi-flux et exploitation industrielle | Licence, expertise, aucune permission marketing incluse | | mailcow | Suite mail conteneurisée | Héberger boîtes, SMTP/IMAP, webmail et antispam | Plus large qu'un besoin sortant ; pas un campaign manager | | Mailu | Suite mail libre en conteneurs | Serveur de messagerie administrable et modulaire | Même distinction entre boîte mail et plateforme marketing | | Relais cloud | Service SMTP/API exploité par un tiers | Déléguer le dernier kilomètre et les pools | Contrat, dépendance, données, quotas et réputation partagée | ## mailcow et Mailu : suites de messagerie, pas moteurs marketing mailcow assemble notamment Postfix, Dovecot, Rspamd et une interface d'administration dans des conteneurs. Mailu suit aussi une philosophie de composants conteneurisés avec frontal central, administration et services SMTP/IMAP associés. Ces projets sont pertinents pour fournir des **boîtes mail** et un environnement de messagerie complet. Pour un expéditeur uniquement sortant, ils peuvent ajouter : - une surface d'attaque IMAP/webmail inutile ; - des volumes et sauvegardes de boîtes qui n'ont rien à voir avec la campagne ; - des composants entrants à mettre à jour ; - une confusion entre courrier humain et marketing. Ils peuvent néanmoins servir de relais pour un petit environnement maîtrisé, à condition d'ajouter l'application de campagne, la suppression, les retours et les politiques de volume. ## Docker ne supprime pas l'exploitation Les conteneurs facilitent la reproductibilité et l'isolation des composants, mais le courrier impose des états persistants : - spool de la file ; - clés DKIM ; - certificats TLS ; - base des comptes et des domaines ; - liste de suppression ; - journaux et événements ; - configuration DNS externe. Un `docker compose down` mal préparé ne doit ni perdre la file ni réenvoyer tous les messages. Les images doivent être épinglées, les migrations lues, les volumes sauvegardés puis restaurés en test. Le PTR reste configuré par l'hébergeur de l'IP, hors de Docker. ## DNS et identité avant le premier message Chaque identité sortante doit disposer de : - une IP stable avec port 25 sortant autorisé si livraison directe ; - un PTR contrôlé et cohérent avec un nom `A/AAAA` ; - un nom `EHLO` valide ; - SPF pour le domaine d'enveloppe ; - DKIM avec clé privée protégée et procédure de rotation ; - DMARC aligné et rapports surveillés ; - TLS correctement négocié ; - adresses `postmaster@` et `abuse@` opérationnelles ; - domaines de liens et de tracking cohérents. Les détails cryptographiques et la progression DMARC sont traités dans [le guide de sécurité e-mail](/blog/securite-email-spf-dkim-dmarc/). DNSSEC et DANE font l'objet du [dossier DNSSEC, KSK et ZSK](/blog/dnssec-ksk-zsk/). ## Concevoir la file par destination Une file n'est pas un simple dossier. Elle doit éviter qu'un fournisseur lent bloque tous les autres et qu'une campagne marketing retarde les mots de passe oubliés. ```mermaid flowchart TD A["File d'admission"] --> B["Transactionnel prioritaire"] A --> C["Marketing"] B --> D["MX Google"] B --> E["MX Microsoft"] B --> F["Autres MX"] C --> G["MX Google
cadence marketing"] C --> H["MX Microsoft
cadence marketing"] C --> I["Autres MX"] ``` Paramètres à piloter par groupe de MX : - connexions simultanées ; - messages par connexion ; - débit par minute ; - délai après un `4xx` ; - durée maximale de rétention ; - priorité du flux ; - IP ou pool autorisé ; - seuil d'ouverture du circuit après erreurs. Ne réessayez pas immédiatement mille fois après une limitation. Respectez l'espacement du MTA, ajoutez du *backoff* et ralentissez la source qui remplit la file. ## Idempotence : ne jamais envoyer deux fois après une panne L'orchestrateur attribue une clé unique à chaque couple campagne/destinataire : ```text send_key = sha256(campaign_id + ":" + contact_id + ":" + variant_id) ``` Avant soumission, il réserve cette clé dans une transaction. Après acceptation par le MTA, il enregistre l'identifiant de file. Si le processus redémarre entre les deux, un état `unknown` déclenche une réconciliation, pas un nouvel envoi aveugle. La clé ne doit pas être construite à partir de l'adresse brute si elle apparaît dans les journaux ou URL. Un identifiant interne opaque réduit les fuites. ## Traiter les retours comme des données de production La RFC 3464 normalise la forme des notifications d'état de livraison, mais les réponses réelles restent hétérogènes. Conservez le code étendu et le texte d'origine avant de les classer : ```json { "message_id": "msg_01J2...", "queue_id": "4F8C21A03B", "attempt": 3, "remote_mx": "mx.example.net", "smtp_code": 550, "enhanced_status": "5.1.1", "response": "recipient address rejected: user unknown", "occurred_at": "2026-07-14T11:04:38Z" } ``` Le pipeline doit ingérer : - DSN et bounces ; - plaintes des boucles de retour disponibles ; - désabonnements visibles et RFC 8058 ; - délais de livraison ; - réponses automatiques sans les confondre avec un rebond ; - rapports DMARC ; - alertes de réputation et de blocklist. Un hard bounce ou une plainte doit atteindre la suppression avant le prochain lot, pas après le bilan mensuel. ## Journaux : assez pour comprendre, pas assez pour exposer Champs techniques utiles : - identifiants campagne, message et file ; - flux et tenant ; - domaine destinataire, avec adresse pseudonymisée lorsque possible ; - IP locale, nom EHLO, MX distant et IP distante ; - tentative, temps d'attente et durée de conversation ; - version TLS et résultat de vérification ; - résultat SPF/DKIM/DMARC lorsqu'observé ; - code SMTP complet ; - version du modèle et de la politique ; - timestamps en UTC. Évitez de journaliser le corps, les jetons de désabonnement, les pièces jointes et les adresses en clair dans chaque système. Définissez des durées distinctes pour l'exploitation, l'audit et les agrégats. ## Warm-up et IP : stabilité avant vitesse Une nouvelle IP ou un nouveau domaine n'a pas d'historique. Commencez par les destinataires récents et attendus, augmentez selon les réponses SMTP et les plaintes, et gardez une cadence régulière. Aucun logiciel ne connaît un calendrier universel. La **rotation d'IP** est légitime lorsqu'elle correspond à : - des tenants réellement isolés ; - des flux transactionnels et marketing distincts ; - de la capacité redondante testée ; - des contraintes contractuelles ou géographiques documentées. Elle devient une pratique abusive lorsqu'elle sert à abandonner une IP dès que sa réputation baisse. Les domaines, liens et comportements restent corrélables, et les nouvelles IP froides aggravent l'instabilité. ## Arrêt d'urgence et garde-fous La plateforme doit pouvoir suspendre : - une campagne ; - un segment ; - une application source ; - un tenant ; - un domaine d'envoi ; - une IP ou un fournisseur destinataire. Déclencheurs possibles : hausse de hard bounces, plainte, rejet d'authentification, taille de file, volume inattendu, malware sortant, échec du désabonnement ou écart par rapport au plan de trafic. Le [dossier sur les campagnes de masse et le spam](/blog/campagnes-email-masse-spam-delivrabilite/) explique les signaux à surveiller ; [la construction d'une liste de qualité](/blog/liste-emails-qualite-opt-in-segmentation/) définit les suppressions en amont. ## Exploiter soi-même ou déléguer le dernier kilomètre ? | Question | Si la réponse est non | |---|---| | L'équipe sait-elle intervenir sur une file 24/7 ? | Utiliser un relais géré | | Peut-elle obtenir et maintenir PTR, TLS et IP stables ? | Utiliser un relais géré | | Traite-t-elle automatiquement bounces et plaintes ? | Ne pas livrer directement | | Le volume est-il assez stable pour une réputation dédiée ? | Préférer un pool partagé de qualité | | Existe-t-il une liste de suppression centrale ? | Ne pas lancer de campagnes | | Les transferts de données et sous-traitants sont-ils maîtrisés ? | Corriger le cadre avant de choisir l'hébergement | Une architecture hybride est souvent raisonnable : garder en interne consentements, segmentation, modèles et événements métier, puis remettre le message à un prestataire SMTP/API. Changer de relais reste alors possible sans reconstruire toute l'application. ## Recette avant production - [ ] Aucun relais ouvert ; chaque source et chaque expéditeur sont autorisés explicitement. - [ ] La file survit à un redémarrage et ne produit pas de doublons. - [ ] Les `4xx` ralentissent le bon domaine sans bloquer tout le système. - [ ] Les `5xx` qualifiés alimentent la suppression. - [ ] SPF, DKIM et DMARC sont testés sur le message réellement reçu. - [ ] PTR, EHLO, TLS et adresses postmaster/abuse fonctionnent. - [ ] Le désabonnement visible et RFC 8058 est idempotent. - [ ] Les clés, secrets et volumes persistants sont sauvegardés et restaurables. - [ ] Les alertes connaissent le flux, le tenant et la campagne fautifs. - [ ] Un bouton d'arrêt limite le périmètre sans couper les messages critiques. - [ ] La montée en charge utilise des destinataires récents et des seuils observés. - [ ] Un plan permet de basculer temporairement vers un smart host sans casser l'alignement. Le vrai coût d'un serveur d'e-mailing n'est pas le CPU. C'est la capacité à expliquer chaque message, ralentir au premier signal faible, restaurer la file sans doublon et faire respecter une opposition dans tous les chemins d'envoi.