Serveur mail multidomaine : architecture et coûts

Vous exploitez un serveur mail multidomaine pour 30 domaines clients. Chacun nécessite ses enregistrements MX, sa clé DKIM, son enregistrement SPF, sa politique DMARC, ses règles de quarantaine et un suivi de sa réputation d'envoi. La question n'est pas de savoir si un serveur peut tout gérer : Postfix et Dovecot le font depuis deux décennies. Il faut plutôt savoir comment réagira votre installation lorsqu'une campagne client dégradera la réputation de votre IP partagée.

Le serveur mail multidomaine convient à de nombreux exploitants. Pour d'autres, qui espèrent économiser par rapport à une offre hébergée mutualisée, le résultat peut être décevant. Ce guide présente l'architecture, les configurations qui contribuent à séparer les clients, trois défaillances importantes à grande échelle et les coûts à comparer avec une offre comme TrekMail Agency. Les extraits de configuration sont incomplets et dépendent des versions ; les tarifs et fonctionnalités correspondent au scénario de l'article, sans garantie de disponibilité actuelle.

Ce qu'est réellement un serveur mail multidomaine

Un serveur mail multidomaine est une pile de transport qui reçoit et envoie des messages pour plusieurs domaines sur une même infrastructure. Une instance de Postfix reçoit le courrier de client1.com, client2.com et client3.com ; une instance de Dovecot conserve les boîtes des trois avec des contrôles de séparation ; une file sortante envoie les messages avec une signature DKIM propre à chaque domaine.

Ce n'est pas tout à fait synonyme d'« hébergement mail multidomaine », expression commerciale qui désigne souvent une offre permettant d'ajouter plusieurs domaines à un même compte de facturation. Le serveur multidomaine est l'infrastructure sous-jacente : la configuration de Postfix et Dovecot qui rend cette offre possible. Vous pouvez l'exploiter sur votre VPS ou utiliser un fournisseur comme TrekMail Agency, qui prend en charge l'exploitation de la plateforme mutualisée.

Trois architectures pour gérer plusieurs domaines

À partir de 10 domaines, on retrouve souvent trois modèles d'architecture. Chacun arbitre différemment entre coût, maîtrise et complexité opérationnelle. Le choix dépend autant du temps technique disponible que du budget. Une décision anticipée peut éviter une refonte coûteuse deux ans plus tard, lorsque l'installation initiale ne suffit plus.

Modèle 1 : un serveur par domaine

L'architecture la plus simple consiste à déployer une instance Postfix/Dovecot par domaine client. Aucun client ne partage cette pile, mais les risques liés au système d'exploitation, à l'hyperviseur et à l'administration subsistent. Chaque domaine dispose de son VPS, de son IP et de sa gestion de réputation. Cette approche peut convenir à 3-5 domaines correspondant chacun à une activité importante. Avec 20+ domaines, les correctifs, la supervision et le renouvellement des certificats multiplient presque linéairement le travail.

Modèle 2 : un serveur multidomaine mutualisé

C'est le modèle courant des agences : une pile Postfix + Dovecot gère tous les domaines clients avec virtual_mailbox_domains, des clés DKIM par domaine et une configuration Dovecot adaptée à la séparation des clients. L'exploitant administre une infrastructure pour N domaines. À titre indicatif, l'intérêt économique peut apparaître autour de 10 domaines et la complexité devenir importante vers 200. Certains passent alors à une offre hébergée ou répartissent les domaines entre plusieurs serveurs selon leurs besoins et leurs profils de réputation.

Modèle 3 : une offre hébergée mutualisée, acheter ou construire

Exploiter une messagerie multidomaine peut mobiliser beaucoup de temps technique, parfois pour un coût supérieur à celui d'un service hébergé. Le scénario de l'article présente TrekMail Agency à $29 par mois, ou $23.25/mois avec facturation annuelle, pour 1,000 domaines, avec gestion DKIM et SPF/DMARC et contrôles des files sortantes. Vérifiez la portée actuelle de ces fonctions : une file par compte n'est pas une file isolée par domaine, ni une réputation IP indépendante. L'agence n'administre plus Postfix, mais continue à gérer utilisateurs, DNS et politiques. Le seuil de rentabilité dépend des heures réellement économisées sur l'année, pas d'une équivalence automatique avec une seule heure d'ingénierie.

Postfix + Dovecot : la combinaison habituelle

Pour une installation autohébergée, une combinaison courante en 2026 associe Postfix au transport SMTP et Dovecot à IMAP, au stockage et à la remise LMTP. Les exemples suivants supposent Debian ou Ubuntu LTS. Les principes s'appliquent ailleurs, mais chemins, permissions et directives doivent être adaptés à la distribution et aux versions.

virtual_mailbox_domains et les tables de correspondance

Postfix prend en charge les domaines virtuels avec la directive virtual_mailbox_domains. Plutôt que d'inscrire tous les domaines dans main.cf, vous pouvez les conserver dans une table hash ou, à plus grande échelle, dans un backend SQL ou LDAP :

# /etc/postfix/main.cf
virtual_mailbox_domains = hash:/etc/postfix/vhosts
virtual_mailbox_maps    = hash:/etc/postfix/vmailbox
virtual_alias_maps      = hash:/etc/postfix/valias
virtual_transport       = lmtp:unix:private/dovecot-lmtp

Le fichier /etc/postfix/vhosts répertorie les domaines acceptés, un par ligne, avec le domaine comme clé et la valeur requise par le format hash, plutôt qu'une simple liste sans valeurs. /etc/postfix/vmailbox sert à vérifier les destinataires virtuels ; avec ce transport LMTP, sa valeur ne définit pas à elle seule l'emplacement final de la boîte, que Dovecot détermine. /etc/postfix/valias gère les alias, par exemple info@client1.com → real-person@client1.com.

Organisation des répertoires Dovecot par domaine

Dovecot peut conserver les boîtes dans des répertoires distincts par domaine. Une arborescence habituelle est /var/vmail/<domain>/<user>/. Voici l'exemple de configuration :

# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/vmail/%d/%n
mail_uid = vmail
mail_gid = vmail

%d représente le domaine et %n la partie locale de l'adresse. Cette organisation facilite les sauvegardes et les interventions par client : rsync peut cibler un répertoire précis. Elle ne constitue pas, à elle seule, une frontière de sécurité. Permissions, authentification, autorisation et processus accédant au stockage doivent aussi être contrôlés.

LMTP pour la remise de Postfix à Dovecot

Les installations modernes utilisent souvent LMTP, Local Mail Transfer Protocol, pour remettre les messages de Postfix à Dovecot. Selon la configuration, cela peut éviter de lancer un processus dovecot-deliver pour chaque message et permettre l'application de quotas par destinataire. Dovecot doit écouter sur un socket Unix accessible à Postfix avec les permissions adaptées.

SPF, DKIM et DMARC par domaine à grande échelle

La difficulté dépasse le transport : il faut maintenir SPF, DKIM et DMARC correctement pour tous les clients et gérer les clés DKIM selon une politique adaptée aux risques. Une rotation préparée peut réduire l'exposition d'une clé compromise, mais ne répare pas à elle seule une réputation dégradée. Ces tâches expliquent une partie du coût de l'autohébergement et de l'intérêt potentiel d'une offre hébergée.

SPF par domaine

Les domaines utilisés comme identités SMTP doivent autoriser leurs émetteurs avec les enregistrements SPF correspondants, publiés dans le DNS et non sur le serveur mail. L'ajout d'une IP sortante impose de revoir les identités et mécanismes SPF concernés. Il n'est pas toujours nécessaire de modifier chaque domaine lorsqu'ils utilisent un include commun correctement mis à jour. Vous devez aussi disposer de l'accès DNS ou de la coopération du client. Le détail figure dans notre guide de configuration SPF.

DKIM par domaine, avec une rotation trimestrielle comme exemple

DKIM demande du travail lorsque les domaines se multiplient. Chaque domaine signataire utilise sa paire de clés : la clé privée signe les messages sortants, la clé publique est publiée dans le DNS sous un sélecteur. Une rotation trimestrielle est une politique possible, pas une obligation générale. Il faut publier les nouveaux sélecteurs, vérifier leur disponibilité et conserver les anciens tant que des messages portant leurs signatures peuvent encore arriver. Pour 100 domaines, ce calendrier représente 400 mises à jour DNS par an si tout est manuel. Le guide DKIM décrit cette rotation.

Rapports DMARC à grande échelle

DMARC permet de demander des rapports agrégés par domaine. De nombreux destinataires participants les transmettent sous forme XML, souvent chaque jour, mais tous ne produisent pas de rapports et leur fréquence varie. Les analyser, les attribuer au bon client et en tirer des informations utiles, comme une usurpation possible ou un émetteur mal configuré, peut devenir un projet technique à part entière. Le guide DMARC présente cette analyse.

Trois défaillances de séparation à anticiper

Un serveur multidomaine dépend de la séparation des clients et de la maîtrise des ressources communes. Les trois défaillances suivantes peuvent rester invisibles jusqu'à un incident. Mieux vaut les rechercher lors des revues et des tests que pendant un problème de remise en production.

Défaillance 1 : dégradation de la réputation d'une IP partagée

Lorsque plusieurs clients envoient depuis une même IP, une campagne mal maîtrisée peut affecter les autres. Une liste de mauvaise qualité ou des messages non sollicités peuvent entraîner blocages et limitations, notamment chez Gmail. Séparer certains émetteurs sur des IP différentes peut réduire une partie du risque, mais exige volume adapté, montée en charge progressive et supervision. Changer d'IP ne résout pas l'abus et ne doit pas servir à contourner les blocages. Une IP dédiée ne garantit pas non plus la remise ; réputation du domaine et comportement de l'émetteur restent déterminants.

Défaillance 2 : engorgement de la file partagée

Lorsque la file Postfix grossit, par exemple après de nombreux refus temporaires 4xx pour un client, les ressources disponibles pour les autres peuvent diminuer. Les contrôles par destination n'éliminent pas la concurrence sur les ressources globales. Avec 50 domaines, une campagne de 500K messages pourrait retarder pendant plusieurs heures les messages transactionnels d'autres clients, selon la capacité et les protections mises en place.

Défaillance 3 : confusion des identités d'authentification

Si la base d'authentification Dovecot ne distingue pas les domaines de façon cohérente, un utilisateur du client A pourrait être associé à des entrées du client B lorsque leurs noms coïncident. Toute la chaîne doit prendre le domaine en compte. Régler auth_username_format sur %u, l'adresse complète, plutôt que %n, la seule partie locale, peut contribuer à la solution. Cette ligne ne suffit pas : requêtes d'authentification, normalisation, autorisation et accès aux boîtes doivent appliquer la même séparation. L'inventaire figure dans les risques de l'hébergement mail multidomaine.

Serveur autohébergé ou service hébergé

La décision dépend du coût réel de votre temps. L'autohébergement semble abordable si l'on compte seulement VPS et bande passante ; la comparaison change en ajoutant réglages Postfix, demandes de retrait de listes de blocage, rotations DKIM et incidents de remise à 3 heures du matin. Le tableau propose des scénarios indicatifs, pas des devis ni des seuils universels.

Dans ces exemples, une offre hébergée peut être avantageuse en dessous de 5,000 domaines, à condition de vérifier capacité, conditions et heures réellement économisées. Des obligations de conformité peuvent changer le choix, notamment si les données doivent résider physiquement dans une juridiction non couverte par le fournisseur. Une architecture hybride permet de gérer un client exceptionnel sur votre infrastructure sans forcément autohéberger toute la pile.

Ce que peut apporter une offre hébergée mutualisée

Évaluez quatre capacités : gestion et traçabilité des rotations DKIM par domaine ; assistants SPF/DMARC avec publication par intégration DNS lorsqu'elle est disponible et autorisée ; suivi des pools IP et de la réputation des domaines ; analyse des rapports DMARC agrégés. Tous les fournisseurs ne proposent pas tout, ni avec la même portée. Vérifiez les fonctions actuelles de TrekMail Agency, conservez un accès au DNS et contrôlez les enregistrements publiés. L'hébergement peut éviter de développer ces outils, sans supprimer la responsabilité de vérifier émetteurs et politiques.

Comparatif des services multidomaines hébergés

TrekMail, Migadu et Workspace peuvent entrer dans une évaluation multidomaine, sans représenter tout le marché. Leurs modèles et capacités diffèrent. Le tableau conserve le scénario illustratif de l'article : 50 domaines clients avec ~10 boîtes chacun, soit 500 boîtes. Tarifs, facturation et contrôles doivent être vérifiés avant d'en tirer une décision d'achat.

Les hypothèses du tableau produisent des écarts d'environ 13× par rapport au calcul attribué à Migadu et 240× par rapport à Workspace. Il s'agit de résultats arithmétiques, pas d'une comparaison vérifiée des offres actuelles, notamment pour le modèle Migadu. Une tarification forfaitaire et une tarification à l'unité peuvent fortement diverger avec le volume. Il faut aussi comparer capacité, administration et exposition à la réputation partagée ; aucune de ces offres n'implique par défaut une IP dédiée par domaine. Lorsqu'elles conviennent, ces IP demandent une gestion propre et ne garantissent pas la remise. Réunir des domaines indépendants dans une organisation Workspace ne garantit pas non plus des frontières administratives ou de données équivalentes : vérifiez les domaines et les besoins de séparation de chaque client.

Quand l'autohébergement multidomaine peut être préférable

Les exemples précédents favorisent souvent l'hébergement, mais trois situations peuvent justifier le coût opérationnel d'un serveur propre. Comprendre ces exceptions permet de décider selon les besoins, plutôt que d'appliquer une recommandation générale à tous les clients.

Premier cas : des contraintes réglementaires que les offres étudiées ne satisfont pas. Si un client exige une localisation physique absente des offres TrekMail, Migadu et des suites cloud considérées, une infrastructure propre ou un autre fournisseur peut être nécessaire. Beaucoup d'agences choisissent une approche hybride : une infrastructure spécifique pour ce client, un service hébergé pour les autres. Inutile de déplacer toute la pile pour un seul cas particulier.

Deuxième cas : un besoin justifié d'IP dédiées ou de gestion de réputation non couvert par les offres disponibles. Certains services transactionnels ou expéditeurs de lettres d'information à fort volume peuvent bénéficier d'une séparation des IP. Beaucoup d'offres mutualisées utilisent des pools partagés. Un VPS avec des IP et une montée en charge adaptées peut convenir, à condition de maîtriser consentement, abus et supervision. Tous les clients qui demandent une IP dédiée n'en ont pas réellement besoin.

Troisième cas : des compétences internes déjà disponibles pour d'autres activités. Si un spécialiste mail travaille déjà dans l'entreprise, lui confier des domaines supplémentaires peut présenter un coût marginal plus faible. Son temps conserve néanmoins un coût d'opportunité et une capacité limitée : un salaire déjà budgété ne rend pas ce travail supplémentaire gratuit.

Renforcer la sécurité d'un serveur multidomaine

Un serveur multidomaine est une cible précieuse : une compromission suffisamment privilégiée peut affecter le flux de courrier de plusieurs clients. La liste suivante rassemble des contrôles pratiques. Leur efficacité dépend de leur mise en œuvre, de leur supervision et de leur validation avec le reste de l'architecture.

La soumission par les clients doit utiliser le port 587 avec STARTTLS ou le port 465 avec TLS implicite, avec une authentification protégée par un TLS valide, sans identifiants en clair ni soumission anonyme. Le port 25 doit continuer à accepter les messages légitimes entre serveurs, généralement sans authentification utilisateur. Ne rejetez pas systématiquement les échanges entre adresses locales : bloquez le relais non autorisé et empêchez ce port de contourner les règles de soumission authentifiée. Vérifiez notamment que le port 25 ne sert pas de voie de repli pour contourner ces contrôles.

Des limites d'envoi par client peuvent réduire les dégâts d'une boîte compromise, sans garantir la protection d'une IP en 20 minutes. Associez des plafonds par boîte et par heure et par compte et par jour à des alertes et une réaction rapide. Sans contrôles, un mot de passe volé pourrait permettre une rafale de 100K messages indésirables, selon les ressources disponibles. L'article cite pour TrekMail des limites de 1,000 messages par boîte et par jour et 6,000 par compte et par jour sur Starter, ou 50 messages soumis par SMTP et par heure sur Nano. Vérifiez valeurs et portée actuelles : ce sont des repères de conception, pas une garantie contre les abus.

Exigez des mots de passe robustes et la 2FA pour l'accès administratif. La 2FA des boîtes compte également, notamment lorsqu'elles permettent de récupérer d'autres comptes. IMAP classique peut nécessiter des mots de passe d'application ou d'autres mécanismes compatibles, plutôt qu'un défi interactif. La 2FA administrative mérite une attention particulière, car cet accès dispose d'un pouvoir large sur la séparation des clients.

Liste de contrôle opérationnelle d'un serveur multidomaine

Si vous choisissez l'autohébergement, les tâches quotidiennes et hebdomadaires comptent autant que la configuration initiale. Postfix et Dovecot peuvent fonctionner pendant des années avec un entretien adapté, mais continuité et remise dépendent de la discipline d'exploitation. La liste suivante est un point de départ, à adapter à votre installation.

Chaque jour : surveillez la profondeur de file et les volumes sortants par client. Une hausse soudaine de 10× par rapport à l'habitude peut correspondre à une campagne prévue ou à une compromission ; les deux méritent un examen. Vérifiez les listes de blocage de vos IP avec MX Toolbox ou un outil équivalent. Contrôlez les tâches cron nocturnes : rotation des journaux, réception des rapports DMARC et sauvegardes.

Chaque semaine : examinez les rapports DMARC disponibles pour chaque domaine. Plateformes de lettres d'information, prestataires de paiement et outils commerciaux peuvent ajouter de nouveaux émetteurs. Vérifiez leur autorisation SPF, leur signature DKIM et l'alignement applicable. Suivez la croissance du stockage ; une boîte dépassant 30 GB peut nécessiter une politique d'archivage ou une révision de capacité, selon l'offre. Consultez les compteurs de connexions IMAP Dovecot par client : approcher une limite peut provoquer des interruptions de synchronisation et des demandes d'assistance.

Chaque trimestre : si cette fréquence fait partie de votre politique, renouvelez les clés DKIM par domaine. L'exemple consiste à publier le nouveau sélecteur, attendre 48 heures, changer la signature Postfix et conserver l'ancien sélecteur encore 48 heures. Ces fenêtres ne constituent pas une garantie : vérifiez TTL, caches, publication et messages signés encore en transit avant de retirer les clés. Pour 100 domaines, l'article estime 8-12 heures par trimestre, soit environ 40 heures par an. Ce sont des ordres de grandeur ; l'automatisation d'offres comme TrekMail Agency doit être vérifiée et surveillée.

Chaque année : révisez la gestion des certificats SSL/TLS SMTP et IMAP, en utilisant une version actuelle de TLS et sans attendre cette revue pour les renouveler. L'article prend l'exemple de certificats Let's Encrypt de 90 jours renouvelés automatiquement ; leur validité et l'automatisation doivent être vérifiées et suivies en continu. Testez les sauvegardes en restaurant le courrier d'un client sur une instance Dovecot propre, puis auditez les backends d'authentification. Recherchez les entrées obsolètes, dont les utilisateurs de domaines retirés de Postfix qui peuvent encore s'authentifier.

Pour aller plus loin

Un serveur multidomaine associe une pile technique éprouvée à une exploitation parfois exigeante. La gestion DKIM par domaine et l'analyse DMARC peuvent occuper plusieurs semaines par an, selon l'échelle et l'automatisation. Une offre hébergée mérite souvent d'être étudiée lorsqu'elle évite ce travail, mais la décision doit reposer sur les coûts, contraintes et capacités réels.

Le scénario de l'article présente TrekMail Agency à $29 par mois, $23.25/mois avec facturation annuelle, pour 1,000 domaines × 1,000 boîtes par domaine et 200 GB partagés entre courrier et TrekMail Drive. Il décrit aussi la rotation DKIM par domaine, un éditeur Sieve, une assistance dédiée, 100 alias par boîte et l'import de 50 domaines par CSV. L'essai de 14 jours nécessite une carte dans ce scénario ; Nano est présenté comme gratuit, sans carte ni essai limité, pour 10 domaines × 10 boîtes. Vérifiez tarifs, fonctions, conditions et quotas actuels, ainsi que l'effet réel d'une extension Drive sur le stockage mail. Pour approfondir les risques, consultez notre guide de l'hébergement multidomaine. Les offres et tarifs actuels figurent sur trekmail.net/pricing.