Mailserver voor meerdere domeinen: architectuur, isolatie en kosten

Je beheert een mailserver voor 30 klantdomeinen. Elk domein heeft een eigen MX, DKIM-sleutel, SPF-record, DMARC-beleid en quarantaineregels nodig. Ook moet je de verzendreputatie kunnen volgen. De vraag is niet of één server dit aankan: Postfix en Dovecot doen dat al twee decennia. De vraag is of je opzet standhoudt wanneer een uitgaande campagne van een klant de reputatie van je gedeelde IP-adres beschadigt.

Een mailserver voor meerdere domeinen is voor veel beheerders een geschikte architectuur. Voor anderen, die denken er goedkoper mee uit te zijn dan met een beheerde multitenantdienst, kan het juist de verkeerde keuze zijn. Deze gids behandelt de architectuur, configuraties die klanten helpen scheiden, de drie isolatieproblemen die bij groei kunnen ontstaan en de kostenafweging tussen zelfbeheer en een abonnement zoals TrekMail Agency.

Wat een mailserver voor meerdere domeinen precies is

Een mailserver voor meerdere domeinen is één mailtransportstack die op dezelfde infrastructuur mail ontvangt en verzendt voor verschillende domeinen. Eén Postfix-instantie ontvangt voor client1.com, client2.com en client3.com; één Dovecot-instantie bewaart de mailboxen van alle drie volgens de ingestelde scheidingsregels; één uitgaande wachtrij verstuurt berichten met een DKIM-handtekening per domein.

Dit is iets anders dan de commerciële term ‘emailhosting voor meerdere domeinen’, die meestal een abonnement betekent waarin je meerdere domeinen onder één factureringsaccount kunt toevoegen. De mailserver is de technische werkelijkheid daaronder: de Postfix- en Dovecot-configuratie die dat abonnement mogelijk maakt. Je kunt die zelf op een VPS beheren of onderbrengen bij een aanbieder zoals TrekMail Agency, die het beheer van de multitenantinfrastructuur overneemt.

Drie architecturen voor veel domeinen

Beheerders met 10 of meer domeinen kiezen doorgaans uit drie architecturen. Elke opzet maakt een andere afweging tussen kosten, controle en beheerlast. De beschikbare technische capaciteit telt daarbij net zo goed mee als de rekensom. Een passende keuze aan het begin kan voorkomen dat je na twee jaar een dure herinrichting nodig hebt omdat de eerdere opzet te klein is geworden.

Patroon 1: één mailserver per domein

De eenvoudigste opzet is een Postfix/Dovecot-instantie per klantdomein. Je hoeft dan geen klanten binnen dezelfde stack van elkaar te scheiden, maar besturingssysteem, netwerk en beheertoegang blijven beveiliging vereisen. Elk domein krijgt een eigen VPS, IP-adres en reputatieprofiel. Dat kan goed passen bij 3-5 domeinen die elk een zelfstandig bedrijf van betekenis vertegenwoordigen. Bij 20+ domeinen kan het beheer zwaar worden: updates, monitoring en certificaatvernieuwing nemen toe met het aantal servers.

Patroon 2: één multitenantmailserver voor alle domeinen

De gebruikelijke bureauopzet is één Postfix + Dovecot-stack voor alle klantdomeinen, met virtual_mailbox_domains, DKIM-sleutels per domein en een multitenantconfiguratie in Dovecot. Je beheert de infrastructuur van één server en bedient N domeinen. Als grove indicatie kan het economische voordeel rond 10 domeinen ontstaan en kan de beheerlast rond 200 domeinen merkbaar oplopen, afhankelijk van het verkeer. Sommige beheerders stappen dan over op een beheerde dienst of verdelen domeinen over servers op basis van hun reputatieprofiel.

Patroon 3: beheerde multitenantdienst, inkopen of zelf bouwen

Veel bureaus merken dat eigen multidomeinmailbeheer aanzienlijk technisch werk vraagt, soms een voltijdse functie, en dat dit meer kost dan een passend beheerd abonnement. In het bronscenario kost TrekMail Agency $29 per maand, of $23.25/mo als maandbedrag bij jaarlijkse facturering, met ruimte voor 1,000 domeinen en hulpmiddelen voor DKIM-sleutelrotatie en SPF/DMARC-beheer. De bron noemt ook uitgaande wachtrijen per account: die betekenen niet automatisch scheiding per domein of een eigen IP-reputatie. Controleer actuele functies en voorwaarden. Je hoeft mogelijk geen Postfix-configuratie te schrijven, maar er blijft klantbeheer over. Vergelijk voor het omslagpunt de jaarlijkse beheertijd met de jaarlijkse abonnementsprijs; zelfs één uur specialistisch werk kan in die afweging zwaar wegen.

Postfix + Dovecot: de gebruikelijke basis

Bij zelfbeheer is een gebruikelijke stack in 2026 Postfix voor SMTP-transport en Dovecot voor IMAP-toegang, opslag en LMTP-aflevering. De onderstaande voorbeelden gaan uit van Debian of Ubuntu LTS. De principes zijn naar andere distributies te vertalen, maar de fragmenten zijn geen volledige configuratie en moeten bij de geïnstalleerde versies passen.

virtual_mailbox_domains en de mapbestanden

Postfix ondersteunt virtuele domeinen met de directive virtual_mailbox_domains. In plaats van domeinen rechtstreeks in main.cf op te nemen, bewaar je ze in een hash-map, of bij een grotere opzet in een SQL- of LDAP-backend:

# /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

Het bestand /etc/postfix/vhosts bevat de domeinen waarvoor de server mail accepteert, één per regel in hash-mapformaat: de domeinnaam als sleutel met een passende waarde, niet uitsluitend losse domeinnamen. Bij de LMTP-opzet hierboven gebruikt Postfix /etc/postfix/vmailbox om te controleren of een ontvanger bestaat; de waarde bepaalt hier niet het daadwerkelijke opslagpad, want Dovecot verzorgt de aflevering. /etc/postfix/valias bevat de aliassen, zoals info@client1.com → real-person@client1.com.

Directorystructuur voor meerdere tenants in Dovecot

Dovecot kan mailboxen onder afzonderlijke domeindirectory's opslaan. Een gebruikelijke structuur is /var/vmail/<domain>/<user>/. Een configuratievoorbeeld:

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

%d staat voor het domeindeel en %n voor het lokale deel van het adres. Zo staat de mail van elke gebruiker onder het eigen domein en kun je back-ups en beheertaken per klant uitvoeren. Met rsync kun je de gegevens van één klant kopiëren zonder die van andere klanten te selecteren. Aparte directory's bieden op zichzelf geen beveiligingsgarantie: authenticatie, autorisatie en bestandstoegang moeten de scheiding ook afdwingen.

LMTP voor de overdracht van Postfix naar Dovecot

Moderne stacks gebruiken vaak LMTP, Local Mail Transfer Protocol, voor de overdracht van Postfix naar Dovecot. Dat kan minder procesoverhead geven dan voor elk bericht apart dovecot-deliver starten en ondersteunt quota per ontvanger wanneer die zijn ingesteld. Laat Dovecot luisteren op een Unix-socket die Postfix met de juiste toegangsrechten kan benaderen.

SPF, DKIM en DMARC per domein op schaal

Het lastigste onderdeel is vaak niet het transport: Postfix heeft daar al lang voorzieningen voor. De uitdaging is SPF, DKIM en DMARC bij alle klanten op orde houden en DKIM-sleutels zo beheren dat een eventuele compromittering beperkt blijft. Dit kan bij zelfbeheer veel tijd kosten en is een relevant punt in de beoordeling van een dienst zoals TrekMail Agency.

SPF per domein

Elk domein dat wordt gebruikt voor de SMTP-identiteit waarop SPF controleert, heeft passend beleid voor zijn verzendbronnen nodig. Die records staan in de DNS van de domeinen, niet op je server. Voeg je een uitgaand IP-adres toe, werk dan de SPF-policies van betrokken domeinen bij als ze dat adres rechtstreeks autoriseren. Bij een goed beheerde include kan een aanpassing in het opgenomen beleid volstaan; niet altijd hoeven alle klanten hun record te wijzigen. Vaak moet dit via de DNS-aanbieder van de klant, waar jij misschien geen toegang toe hebt. De volledige uitleg staat in onze gids voor SPF-configuratie.

DKIM per domein en driemaandelijkse rotatie

DKIM kan zelfbeheer op grote schaal arbeidsintensief maken. Elk domein gebruikt een eigen sleutelpaar. De privésleutel ondertekent uitgaande mail; de publieke sleutel staat in DNS onder een selector voor dat domein. Elk kwartaal roteren is een mogelijke beleidskeuze, geen universele verplichting. Kies je die aanpak, dan publiceer je voor elk domein ieder kwartaal een nieuwe selector, controleer je de beschikbaarheid en behoud je de oude publieke sleutel zolang dat nodig is. Voor 100 domeinen betekent het voorbeeld 400 handmatige DNS-aanpassingen per jaar. De gids voor DKIM-configuratie bespreekt het rotatieproces.

DMARC-rapportage op schaal

DMARC per domein betekent dat je aggregatierapporten aan de juiste klant moet koppelen. Die komen vaak dagelijks als XML-bestanden van ontvangende systemen die rapportage ondersteunen en toepassen; niet elke ontvanger rapporteert en een vaste dagelijkse levering is niet gegarandeerd. De bestanden verwerken en bruikbare signalen tonen, zoals mogelijke domeinspoofing of een verkeerd ingestelde verzender, kan een afzonderlijk technisch project worden. De gids voor DMARC-configuratie behandelt de verwerking.

Drie isolatieproblemen om rekening mee te houden

Een mailserver voor meerdere domeinen staat of valt mede met de scheiding tussen klanten. Drie soorten problemen kunnen die scheiding bij groei onder druk zetten, en worden soms pas door een incident zichtbaar. Houd er vooraf rekening mee: foutzoeken tijdens een lopend afleveringsprobleem is veel moeilijker.

Probleem 1: reputatieschade aan het gedeelde uitgaande IP-adres

Klanten die hetzelfde uitgaande IP-adres gebruiken, delen een deel van het reputatierisico. Als één klant koude acquisitiemail stuurt naar slecht onderhouden lijsten, kan het IP-adres worden gemarkeerd en kunnen andere klanten bij Gmail of andere ontvangers beperkingen ondervinden. Afzonderlijke IP-adressen voor klanten met een aantoonbare behoefte kunnen helpen, mits je opwarming en reputatiebeheer organiseert. Anders behandel je misbruik als een incident voor de hele pool. IP-adressen roteren om blokkades of antispamcontroles te ontwijken lost de oorzaak niet op. Eén problematische klant kan alle klanten in dezelfde pool raken.

Probleem 2: vertraging door een gedeelde wachtrij

Wanneer de Postfix-wachtrij groeit, bijvoorbeeld door een reeks tijdelijke 4xx-weigeringen van een ontvanger, kunnen ook andere klanten vertraging oplopen als resources gedeeld worden. Postfix heeft begrenzing per bestemming, maar daarnaast zijn er globale resources die je moet dimensioneren. Bij 50 domeinen zou een nieuwsbrief van 500K berichten de transactionele mail van andere klanten uren kunnen vertragen, afhankelijk van configuratie en belasting.

Probleem 3: authenticatie tegen gegevens van een andere klant

Als de authenticatiedatabase van Dovecot domeinen niet strikt onderscheidt, kan een gebruiker van klant A onbedoeld worden vergeleken met gegevens van klant B wanneer het lokale gebruikersdeel overeenkomt. Maak gebruikersnaamvalidatie, backendzoekopdrachten en autorisatie overal domeinbewust. De instelling auth_username_format met %u, het volledige emailadres, in plaats van %n, alleen het lokale deel, kan bij de juiste versie onderdeel van de oplossing zijn. Die ene regel is niet voldoende zonder correct ingericht backend- en toegangsbeleid. De gevolgen van een fout kunnen voor gebruikers ernstig zijn. De volledige risicoanalyse staat in de risico's van emailhosting voor meerdere domeinen.

Zelf beheren of een beheerde dienst kiezen

De keuze tussen inkopen en zelf bouwen draait om de werkelijke waarde van je tijd. Zelfbeheer lijkt goedkoop als je alleen VPS en bandbreedte telt. Dat verandert zodra je uren voor Postfix-afstelling, verzoeken tot verwijdering uit blokkeerlijsten, DKIM-rotatie en een mogelijk afleveringsincident om 3 uur 's nachts meerekent. De volgende drie omslagpunten geven richting aan de afweging; de bedragen zijn voorbeelden, geen actuele offertes.

In de geschetste kostenvoorbeelden kan een beheerde dienst op veel schalen onder 5,000 domeinen voordelig zijn, maar belasting, expertise en vereisten blijven bepalend. Een uitzondering is een compliance-eis waaraan geen beschikbare aanbieder voldoet, zoals fysieke gegevensopslag in een rechtsgebied waar die niet actief is. Ook dan past vaak een hybride aanpak: zelfbeheer voor de uitzonderlijke klant en een beheerde dienst voor de rest, in plaats van een volledige eigen stack.

Wat een beheerde multitenantdienst daadwerkelijk oplevert

Een beheerde dienst kan vier groepen voorzieningen bieden die je dan niet zelf hoeft te bouwen: DKIM-sleutelrotatie per domein met controleerbare registratie; SPF/DMARC-wizards en DNS-integraties waar ondersteund en geautoriseerd; opwarming van de uitgaande IP-pool en reputatiemonitoring; verwerking van DMARC-aggregatierapporten tot begrijpelijke signalen in plaats van alleen XML. Elk onderdeel kan maanden eigen ontwikkelwerk vragen. De bron noemt ze als dashboardfuncties van TrekMail Agency. Controleer welke functies werkelijk beschikbaar zijn en wat je zelf moet doen; een wizard betekent niet automatisch dat correcte DNS-records zonder verdere actie worden gepubliceerd.

Beheerde diensten voor meerdere domeinen vergelijken

Als je kiest voor inkopen, kun je onder meer TrekMail, Migadu en Workspace voor grotere organisaties vergelijken. Hun modellen verschillen. Het voorbeeld hieronder gaat uit van 50 klantdomeinen met ~10 mailboxen per domein, dus 500 mailboxen: een mogelijk profiel van een middelgroot bureau. Prijzen en functies zijn aannames uit de bron, geen gecontroleerd actueel aanbod. Domeinen toevoegen aan één Workspace-organisatie maakt onafhankelijke klanten niet vanzelf geïsoleerd: controleer domeinbeheer, beheerdersrechten en organisatorische gegevensscheiding.

Met deze aannames zou TrekMail Agency ongeveer 13× goedkoper zijn dan het aan Migadu toegeschreven domeinmodel en 240× goedkoper dan het aan Workspace toegeschreven gebruikersmodel. Dat zijn illustratieve verhoudingen, geen algemeen bewijs van lagere kosten. Controleer vooral het echte Migadu-factureringsmodel en de voorwaarden van alle abonnementen. Het verschil tussen gedeelde uitgaande IP-adressen en dedicated IP-adressen per domein hangt af van de daadwerkelijke aanbieding en het verzendprofiel. Een eigen IP-adres kan de reputatie helpen scheiden, maar vraagt opwarming en beheer en garandeert geen inboxplaatsing.

Wanneer zelfbeheer van een multidomeinmailserver wel passend is

De eerdere voorbeelden wijzen vaak richting een beheerde dienst. Toch zijn er drie specifieke situaties waarin zelfbeheer ondanks de extra beheerlast geschikt kan zijn. Weten wanneer je van de gebruikelijke keuze moet afwijken is net zo belangrijk als die standaardkeuze kennen.

Eerste situatie: wettelijke vereisten waaraan geen onderzochte aanbieder voldoet. Moeten de gegevens van een klant fysiek blijven in een rechtsgebied waar TrekMail, Migadu en de overwogen cloudsuites niet werken, dan kan zelfbeheer nodig zijn. De beheerlast is reëel. Veel bureaus kiezen hier voor hybride: die ene klant zelf hosten en de overige klanten bij een beheerde dienst onderbrengen. Eén uitzondering hoeft niet te betekenen dat je de hele stack zelf beheert.

Tweede situatie: dedicated IP-adressen per klant met afleveringsvereisten die beschikbare aanbieders niet ondersteunen. Sommige klanten, bijvoorbeeld nieuwsbriefverzenders met veel verkeer of transactionele diensten, kunnen werkelijk baat hebben bij reputatiescheiding. Veel beheerde multitenantabonnementen gebruiken gedeelde pools, maar controleer het beschikbare aanbod. Als het verzendprofiel eigen IP-adressen en gedisciplineerde opwarming rechtvaardigt, kan een VPS met IP-adressen per reputatieprofiel passend zijn. Dat is geen standaardbehoefte: veel klanten die een dedicated IP-adres vragen, hebben geen volume of verzendpatroon waarvoor het verstandig is.

Derde situatie: interne technische capaciteit die al voor andere werkzaamheden bestaat. Heb je om andere redenen al een mailspecialist in dienst, dan kunnen de extra kosten voor multidomeinbeheer beperkt zijn. Die uren zijn niet gratis: kijk ook naar beschikbare capaciteit, bereikbaarheidsdiensten en werk dat hierdoor moet wijken. Bestaande personeelskosten veranderen de afweging, maar nemen de beheerlast niet weg.

Beveiliging van een mailserver voor meerdere domeinen versterken

Een multidomeinmailserver is een aantrekkelijk aanvalsdoel. Een compromittering kan een aanvaller controle geven over de mailstromen van alle gehoste klanten. De checklist hieronder richt zich op maatregelen die het risico daadwerkelijk helpen beperken, niet op indrukwekkend ogende voorzieningen zonder veel effect. Het is geen garantie op volledige beveiliging.

Bied geauthenticeerde SMTP-submission aan op poort 587 met STARTTLS of poort 465 met impliciete TLS. Vereis een geldige TLS-verbinding vóór authenticatie en verstuur geen inloggegevens onversleuteld. Poort 25 blijft open voor inkomende mail van andere servers. Blokkeer daar ongeautoriseerde relay en onjuist gebruik als submissionpad, maar weiger niet alle lokale mail naar lokale ontvangers: dat kan legitieme bezorging zijn. Een poort 25 die als sluiproute voor ongeautoriseerde verzending werkt, vergroot het risico.

Uitgaande verzendlimieten per klant kunnen beperken hoeveel reputatieschade een gekaapte mailbox in 20 minuten veroorzaakt, maar sluiten schade niet uit. Stem limieten per mailbox per uur en per account per dag af op echte verzendpatronen. Zonder begrenzing kan één gestolen wachtwoord in het beschreven scenario 100K spamberichten via het gedeelde IP versturen voordat monitoring ingrijpt. De bron noemt TrekMail-limieten zoals 1,000 berichten per mailbox per dag en 6,000 per account per dag op Starter, en 50 berichten per uur via SMTP-submission op Nano. Verifieer actuele waarden. Dit zijn dezelfde soorten controles die je zelf in een Postfix-opzet moet aanbrengen, geen complete bescherming tegen misbruik.

Beheertoegang vraagt sterke wachtwoorden en 2FA. Ook 2FA voor mailboxen blijft belangrijk: een gekaapte mailbox kan gegevens blootstellen en herstel van andere accounts mogelijk maken. De 2FA van een beheeraccount beschermt toegang met een nog grotere reikwijdte, die de scheiding tussen alle klanten kan raken. Gebruik aanvullende authenticatie waar ondersteund en aparte appwachtwoorden voor IMAP waar van toepassing; bescherm beide niveaus volgens hun risico.

Operationele checklist voor een multidomeinmailserver

Als je zelf gaat beheren, zijn dagelijkse en wekelijkse taken minstens zo belangrijk als de eerste configuratie. Een goed ingerichte Postfix + Dovecot-stack kan met updates en onderhoud jarenlang draaien. Het doorlopende beheer bepaalt of de multitenantomgeving betrouwbaar blijft. Hieronder staat een praktische checklist om aan je omgeving aan te passen.

Dagelijks: volg de wachtrijdiepte en verzendsnelheid per klant. Een plotselinge toename tot 10× het normale niveau kan een campagne of compromittering zijn; beide vragen aandacht. Controleer uitgaande IP-adressen op blokkeerlijsten met MX Toolbox of vergelijkbare hulpmiddelen. Kijk of nachtelijke cron-taken, zoals logrotatie, inlezen van DMARC-rapporten en back-uprotatie, goed zijn afgerond.

Wekelijks: bekijk de beschikbare DMARC-aggregatierapporten voor elk klantdomein. Nieuwe nieuwsbriefdiensten, betaalproviders en verkooptools kunnen nieuwe verzendbronnen toevoegen. Autoriseer die passend via SPF en DKIM voor de gebruikte identiteiten. Controleer opslaggroei per klant: mailboxen boven 30 GB kunnen in het beschreven standaardabonnement om archiefbeleid of een abonnementswijziging vragen. Volg de IMAP-verbindingscounters van Dovecot per klant. Bij het naderen van een ingestelde limiet kunnen synchronisaties haperen en komen er ondersteuningsvragen.

Elk kwartaal: roteer de DKIM-sleutels per domein als dat je gekozen beleid is. Het voorbeeldproces publiceert de nieuwe selector in de DNS van de klant, wacht 48 uur, wijzigt de Postfix-ondertekening en houdt de oude selector nog 48 uur beschikbaar voordat die verdwijnt. Dit zijn voorbeeldvensters, geen zekerheid over DNS-propagatie. Controleer TTL, zichtbaarheid van de nieuwe sleutel en mail die nog onderweg is; houd zo nodig langer overlap. Voor 100 domeinen schat de bron 8-12 uur per kwartaal, of ongeveer 40 uur per jaar voor DKIM-beheer. Een beheerd abonnement zoals TrekMail Agency kan onderdelen automatiseren, afhankelijk van de beschikbare functies. Sleutelrotatie beperkt sleutelrisico, maar herstelt niet vanzelf een beschadigde verzendreputatie.

Jaarlijks: beoordeel het SSL/TLS-certificaatbeheer voor SMTP en IMAP, controleer back-ups volledig door de mail van één klant terug te zetten in een schone Dovecot-instantie en audit de authenticatiebackends. De bron gebruikt Let's Encrypt-certificaten met een looptijd van 90 dagen als voorbeeld; controleer actuele geldigheid en automatisch vernieuwen en monitor die ook door het jaar heen, niet alleen jaarlijks. Handmatig ingrijpen kan alsnog nodig zijn. Dovecot-backends kunnen verouderde vermeldingen verzamelen, bijvoorbeeld voormalige klanten wier domeinen uit Postfix zijn verwijderd maar wier gebruikers nog mogen inloggen.

Volgende stappen

Een mailserver voor meerdere domeinen zelf beheren is technisch haalbaar, maar kan operationeel veel vragen. Postfix en Dovecot zijn gevestigde onderdelen; DKIM-rotatie per domein en DMARC-analyse kunnen jaarlijks weken werk kosten. Voor veel bureaus kan een beheerde dienst voordelig zijn, zolang je vereisten, belasting en resterende klanttaken meerekent.

In de bron kost TrekMail Agency $29 per maand, of $23.25 als maandbedrag bij jaarlijkse betaling, voor 1,000 domeinen × 1,000 mailboxen per domein, 200 GB gedeelde opslag voor email en TrekMail Drive, hulpmiddelen voor DKIM-rotatie per domein, een Sieve-editor voor eigen mailfilters, specifieke ondersteuning, 100 aliassen per mailbox en bulkimport van 50 klantdomeinen met één CSV-bestand. Controleer actuele beschikbaarheid, quota en voorwaarden; de aantallen garanderen niet dat iedere combinatie binnen de inbegrepen opslag past. De beschreven gratis proefperiode van 14 dagen vereist een creditcard. Het gratis Nano-niveau wordt zonder kaart en zonder proefperiode beschreven en omvat 10 domeinen × 10 mailboxen om het dashboard te verkennen voordat je Agency kiest. Zie voor de risico's per domein ook onze gids voor emailhosting met meerdere domeinen. De volledige abonnementsvergelijking en actuele prijzen staan op trekmail.net/pricing.