Mailserver für mehrere Domains: Architektur und Betrieb

Sie betreiben einen Mailserver für 30 Kundendomains. Jede benötigt eigene MX-Einträge, einen eigenen DKIM-Schlüssel, einen SPF-Eintrag, eine DMARC-Richtlinie, Quarantäneregeln und eine gepflegte Absenderreputation. Die Frage lautet nicht, ob ein Server das schafft: Postfix und Dovecot unterstützen solche Umgebungen seit zwei Jahrzehnten. Entscheidend ist, was passiert, wenn die Versandkampagne eines Kunden die Reputation Ihrer gemeinsam genutzten IP-Adresse belastet.

Für viele Betreiber ist ein Mailserver für mehrere Domains die passende Architektur. Für andere, die damit gegenüber einem gehosteten Mehrmandantenangebot Geld sparen wollen, ist er es nicht. Dieser Leitfaden erläutert die Architektur, Konfigurationsmuster für die Mandantentrennung, drei typische Fehler bei wachsender Last und die Kostenabwägung zwischen Eigenbetrieb und einem Hostingtarif wie TrekMail Agency. Getrennte Verzeichnisse und Zuordnungstabellen allein garantieren dabei keine sichere Isolation.

Was ein Mailserver für mehrere Domains tatsächlich ist

Ein Mailserver für mehrere Domains empfängt und versendet E-Mails für verschiedene Domains auf derselben Infrastruktur. Eine Postfix-Instanz nimmt Nachrichten für client1.com, client2.com und client3.com an; eine Dovecot-Instanz verwaltet die Postfächer aller drei mit entsprechend konfigurierter Zugriffstrennung; eine gemeinsame Ausgangswarteschlange versendet Nachrichten mit domainspezifischen DKIM-Signaturen.

Das ist nicht dasselbe wie der Werbebegriff „E-Mail-Hosting für mehrere Domains“. Dieser bezeichnet meistens einen Hostingtarif, bei dem mehrere Domains einem Rechnungskonto zugeordnet werden können. Der Mailserver ist die technische Grundlage darunter: die Postfix- und Dovecot-Konfiguration, die das Angebot ermöglicht. Beide Betriebsformen sind möglich: selbst gehostet auf einem eigenen VPS oder bei einem Anbieter wie TrekMail Agency, der den technischen Mehrmandantenbetrieb übernimmt.

Drei Architekturmuster für mehrere Domains

Für Betreiber mit 10 oder mehr Domains kommen insbesondere drei Architekturmuster infrage. Sie gewichten Kosten, Kontrolle und Betriebsaufwand unterschiedlich. Die Entscheidung hängt ebenso von der verfügbaren technischen Kapazität wie von den reinen Infrastrukturkosten ab. Eine vorausschauende Wahl kann einen kostspieligen Umbau vermeiden, wenn das bisherige Modell nach zwei Jahren nicht mehr ausreicht.

Muster 1: ein Mailserver je Domain

Die einfachste Variante ist eine eigene Postfix-/Dovecot-Instanz für jede Kundendomain. Innerhalb der Instanz gibt es keine gemeinsam untergebrachten Mandanten; gemeinsame Verwaltungszugänge und andere übergreifende Komponenten müssen dennoch abgesichert werden. Jede Domain erhält einen eigenen VPS, eine eigene IP-Adresse und eine eigene IP-Reputation. Für 3-5 eigenständige Unternehmen kann das gut passen. Ab 20+ Domains wird der Aufwand häufig erheblich, weil Updates, Überwachung und Zertifikatserneuerungen mit der Serverzahl wachsen.

Muster 2: ein gemeinsamer Mailserver mit Mandantentrennung

Das klassische Agenturmodell besteht aus einem Postfix- und Dovecot-Stack für alle Kundendomains, mit virtual_mailbox_domains, eigenen DKIM-Schlüsseln je Domain und einer mandantenfähigen Dovecot-Konfiguration. Der Betreiber verwaltet eine gemeinsame Infrastruktur für N Domains. Als grobe Orientierung kann dieses Modell ab etwa 10 Domains wirtschaftlich interessant werden; um etwa 200 Domains kann die betriebliche Komplexität deutlich zunehmen. Diese Schwellen sind keine festen Grenzen. Je nach Last und Anforderungen kommen danach ein gehostetes Angebot oder mehrere Server für unterschiedliche Reputationsgruppen infrage.

Muster 3: gehosteter Mehrmandantenbetrieb statt Eigenentwicklung

Viele Agenturen stellen fest, dass der interne Betrieb eines solchen Mailservers erhebliche Arbeitszeit bindet und mehr kosten kann als ein vergleichbarer Hostingtarif. Im zugrunde liegenden Tarifbeispiel kostet TrekMail Agency $29 pro Monat oder rechnerisch $23.25/mo bei jährlicher Abrechnung und sieht 1,000 Domains sowie Funktionen für DKIM, SPF/DMARC und getrennte Ausgangswarteschlangen vor. Verfügbarkeit und Umfang müssen anhand der aktuellen Bedingungen geprüft werden; Warteschlangen je Konto bedeuten keine Trennung je Kundendomain oder eigene IP-Reputation. Die Agentur muss dabei keine Postfix-Konfiguration selbst schreiben. Für die Wirtschaftlichkeitsrechnung zählt die jährliche Gesamtsumme der technischen Arbeitszeit, nicht nur eine einzelne Stunde.

Postfix + Dovecot: der klassische Softwarestack

Für den Eigenbetrieb ist Postfix für SMTP-Transport zusammen mit Dovecot für IMAP-Zugriff, Postfachspeicherung und LMTP-Zustellung auch 2026 ein verbreiteter Stack. Die folgenden Ausschnitte setzen Debian oder Ubuntu LTS voraus. Die Prinzipien sind auf andere Distributionen übertragbar; die Beispiele sind jedoch unvollständig und versionsabhängig und dürfen nicht ungeprüft als einsatzfertige Konfiguration übernommen werden.

virtual_mailbox_domains und die Zuordnungstabellen

Postfix unterstützt mehrere virtuelle Domains über die Direktive virtual_mailbox_domains. Statt die Domainliste fest in main.cf zu hinterlegen, können Sie eine Hash-Tabelle verwenden, bei größeren Installationen auch ein SQL- oder 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

Die Datei /etc/postfix/vhosts enthält die Domains, für die der Server Nachrichten annimmt, jeweils als Domainschlüssel mit geeignetem Wert pro Zeile im erwarteten Hash-Tabellenformat, nicht bloß als nackte Domainliste. Mit /etc/postfix/vmailbox prüft Postfix in dieser LMTP-Konfiguration, ob ein virtueller Empfänger vorhanden ist; der Tabellenwert bestimmt hier nicht den tatsächlichen Speicherpfad. Die Zustellung und Speicherung übernimmt Dovecot. Die Datei /etc/postfix/valias verwaltet Aliase, beispielsweise info@client1.com → real-person@client1.com.

Domainspezifische Verzeichnisstruktur in Dovecot

Dovecot kann Postfächer in getrennten Verzeichnissen je Domain ablegen. Ein übliches Schema lautet /var/vmail/<domain>/<user>/. Ein entsprechender Konfigurationsausschnitt ist:

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

%d steht für den Domainteil, %n für den lokalen Teil der Adresse. So liegen die Nachrichten jedes Benutzers im Verzeichnis seiner Domain. Das erleichtert domainspezifische Sicherungen und Verwaltungsaufgaben, etwa das Kopieren eines einzelnen Mandanten mit rsync. Die Verzeichnisstruktur allein ist allerdings keine Sicherheitsgrenze; Authentifizierung, Berechtigungen und Zugriffswege müssen ebenfalls stimmen.

LMTP für die Übergabe von Postfix an Dovecot

Moderne Installationen verwenden häufig LMTP, das Local Mail Transfer Protocol, für die Übergabe von Postfix an Dovecot. Das kann gegenüber einem getrennten dovecot-deliver-Prozess je Nachricht Prozessaufwand sparen und ermöglicht mit geeigneter Konfiguration die Quotenprüfung je Empfänger. Dovecot muss dafür auf einem Unix-Socket lauschen, auf den Postfix mit passenden Berechtigungen zugreifen kann.

SPF, DKIM und DMARC je Domain im größeren Maßstab

Die schwierigste Aufgabe ist oft nicht der Nachrichtentransport, sondern die konsistente Pflege von SPF, DKIM und DMARC für alle Mandanten. Dazu gehört eine angemessene DKIM-Schlüsselrotation, die Risiken durch kompromittierte Schlüssel begrenzen kann, aber keine belastete Absenderreputation repariert. Hier entsteht im Eigenbetrieb ein erheblicher Teil des Aufwands, den ein geeignetes Hostingangebot übernehmen kann.

SPF je Domain

Domains, die über Ihren Server versenden, benötigen eine passende SPF-Autorisierung der verwendeten Versandquellen. Die Einträge befinden sich im DNS der jeweiligen Domain, nicht auf dem Mailserver. Kommt eine ausgehende IP-Adresse hinzu, müssen die betroffenen Autorisierungen angepasst werden. Bei gepflegten zentralen include-Einträgen kann eine Änderung dort ausreichen; nicht immer ist ein eigener Eingriff beim DNS-Anbieter jedes Mandanten nötig. Eine ausführliche Anleitung finden Sie in unserem SPF-Leitfaden.

DKIM je Domain und vierteljährliche Rotation als Betriebsmodell

DKIM kann bei vielen selbst gehosteten Domains aufwendig werden. Jede Domain erhält ein eigenes Schlüsselpaar: Der private Schlüssel signiert ausgehende Nachrichten, der öffentliche wird unter einem Selektor im DNS veröffentlicht. Eine vierteljährliche Rotation ist ein mögliches Sicherheitskonzept, keine allgemeingültige Pflicht. Dabei veröffentlichen Sie für jede Domain einen neuen Selektor und berücksichtigen DNS-Caches und noch unterwegs befindliche Nachrichten, bevor alte Schlüssel entfernt werden. Bei 100 Domains ergeben sich im Beispiel 400 DNS-Änderungen pro Jahr, sofern alles manuell erfolgt. Der DKIM-Leitfaden erläutert den Ablauf.

DMARC-Berichte für viele Domains

Domainspezifisches DMARC kann zu vielen aggregierten Berichten führen, die teilnehmende Empfänger häufig täglich als XML-Dateien senden. Nicht jeder Empfänger liefert Berichte, und der Rhythmus ist nicht überall gleich. Die Auswertung, Zuordnung zum richtigen Mandanten und Aufbereitung handlungsrelevanter Hinweise, etwa auf gefälschte Absender oder falsch konfigurierte Versanddienste, kann bei größerem Umfang ein eigenes Entwicklungsprojekt werden. Der DMARC-Leitfaden beschreibt die Auswertung.

Drei typische Schwachstellen der Mandantentrennung

Die Qualität eines gemeinsamen Mailservers hängt wesentlich von seiner Mandantentrennung ab. Die folgenden drei Fehlerbilder können bei wachsendem Betrieb auftreten und bleiben manchmal bis zu einem Vorfall unbemerkt. Prüfen Sie sie frühzeitig. Während einer akuten Zustellstörung sind sie wesentlich schwieriger zu untersuchen.

Fehler 1: beschädigte Reputation der gemeinsamen Versand-IP

Nutzen mehrere Mandanten dieselbe ausgehende IP-Adresse, teilen sie deren Reputation. Eine schlecht gepflegte Empfängerliste oder unerwünschte Akquise eines Mandanten kann Beschwerden und Sperren auslösen, die auch andere Mandanten treffen, beispielsweise durch Drosselung bei Gmail. Geeignete getrennte Versandressourcen können den Schadensradius begrenzen; IP-Adressen einfach auszutauschen ist aber weder eine Behebung von Missbrauch noch eine zulässige Umgehung von Empfängerregeln. Ursachen, Einwilligung und Versandqualität müssen geklärt werden. Im ungünstigen Fall ist der gesamte gemeinsame Kundenpool betroffen.

Fehler 2: Rückstau in einer gemeinsamen Warteschlange

Wächst die Postfix-Warteschlange, etwa weil ein Empfänger die Nachrichten eines Mandanten mit 4xx-Antworten vorübergehend abweist, können gemeinsam genutzte Ressourcen auch den Versand anderer Mandanten verlangsamen. Postfix bietet Drosselung je Ziel, doch die Infrastruktur bleibt gemeinsam. Bei 50 Domains kann ein Newsletter mit 500K Nachrichten unter ungünstigen Bedingungen die Transaktionsnachrichten anderer Mandanten über Stunden beeinträchtigen; das ist ein Lastszenario, kein unvermeidbares Verhalten jeder Installation.

Fehler 3: mandantenübergreifende Verwechslung bei der Anmeldung

Berücksichtigt die Authentifizierungsdatenbank von Dovecot die Domain nicht eindeutig, könnte ein Benutzer von Mandant A bei gleichem lokalem Benutzernamen gegen Datensätze von Mandant B geprüft werden. Benutzernamen müssen deshalb im gesamten Authentifizierungs- und Berechtigungsweg domainspezifisch behandelt werden. Für auth_username_format kann %u, die vollständige Adresse, statt %n, nur des lokalen Teils, erforderlich sein. Diese Einstellung allein behebt aber keine falschen Datenbankabfragen, uneindeutigen Konten oder unzureichenden Zugriffsprüfungen. Weitere Risiken beschreibt der Leitfaden zu Risiken beim Hosting mehrerer Domains.

Eigenbetrieb oder gehosteter Mailserver

Die Entscheidung hängt vom tatsächlichen Wert Ihrer Arbeitszeit ab. Betrachtet man nur VPS und Bandbreite, wirkt Eigenbetrieb günstig. Rechnet man Postfix-Abstimmung, Einsprüche gegen Sperrlisten, DKIM-Rotation und die unvermeidlich ungünstig gelegene Zustellstörung um 3 Uhr morgens ein, sieht die Rechnung anders aus. Die folgende Tabelle zeigt drei Kostenübergänge als Beispielrechnung, nicht als aktuelle Tarifzusage.

In dieser Modellrechnung kann Hosting unterhalb von 5,000 Domains häufig günstiger sein. Das hängt jedoch von Tarifgrenzen, Arbeitskosten, Last und Anforderungen ab. Eine Ausnahme sind etwa Vorschriften zur physischen Datenhaltung in einer Rechtsordnung, in der kein geeigneter Anbieter tätig ist. Auch dann kann eine Mischform sinnvoller sein: Hosting für die meisten Mandanten, Eigenbetrieb für den Sonderfall, statt die gesamte Infrastruktur selbst zu betreiben.

Was gehosteter Mehrmandantenbetrieb übernehmen kann

Ein geeignetes Hostingangebot kann vier Aufgaben übernehmen, die Sie sonst selbst entwickeln und betreiben müssten: nachvollziehbare DKIM-Schlüsselrotation je Domain, Hilfen für SPF/DMARC, Verwaltung und behutsamer Aufbau von Versand-IP-Reputation sowie Auswertung aggregierter DMARC-Berichte. DNS-Assistenten veröffentlichen Einträge nicht zwangsläufig selbst; dafür müssen passende Integrationen und Berechtigungen tatsächlich vorhanden sein. Auch domainspezifische Auswertung bedeutet keine getrennte IP-Reputation. Diese Funktionen können im Eigenbetrieb viel Entwicklungszeit beanspruchen. Ob und in welchem Umfang TrekMail Agency sie im Dashboard anbietet, ist anhand der aktuellen Produktdokumentation zu prüfen.

Vergleich gehosteter Angebote für mehrere Domains

Wer sich für Hosting entscheidet, kann unter anderem TrekMail, Migadu und Google Workspace prüfen. Die Modelle unterscheiden sich. Die folgende historische Beispielrechnung setzt 50 Kundendomains mit jeweils ~10 Postfächern voraus, also insgesamt 500 Postfächer: ein mögliches Profil einer mittelgroßen Agentur. Preise, Abrechnungseinheiten und Funktionsumfang müssen vor einer Entscheidung aktuell geprüft werden. Bei Workspace sind außerdem Domainverifikation und Organisationsgrenzen zu prüfen: Verschiedene Kundendomains in derselben Organisation erhalten nicht automatisch unabhängige Verwaltungs- und Datenbereiche.

Unter genau diesen Annahmen ist TrekMail Agency rechnerisch etwa 13× günstiger als das angesetzte Migadu-Modell je Domain und 240× günstiger als das Workspace-Modell je Benutzer. Das illustriert den Unterschied zwischen Pauschal- und mengenbezogener Abrechnung, beweist aber keine allgemeine Ersparnis: Insbesondere die angenommene Domainabrechnung von Migadu muss überprüft werden. Gemeinsame Versand-IP-Pools und dedizierte IP-Adressen sind außerdem getrennt von der Preisfrage zu bewerten. Eine eigene IP kann Reputation abgrenzen, verbessert die Zustellung jedoch nicht automatisch und benötigt geeignete Versandqualität und Volumen.

Wann sich der Eigenbetrieb tatsächlich lohnt

Die vorherige Modellrechnung spricht häufig für Hosting. Es gibt jedoch drei Situationen, in denen ein selbst betriebener Mailserver trotz des zusätzlichen Aufwands sinnvoll sein kann. Die Ausnahmen zu kennen ist ebenso wichtig wie die übliche Kostenabwägung.

Erstens: regulatorische Vorgaben, die kein geeigneter Anbieter erfüllt. Muss ein Mandant seine Daten physisch in einer Rechtsordnung speichern, in der TrekMail, Migadu und die infrage kommenden Cloudangebote nicht tätig sind, kann eine eigene oder anderweitig speziell betriebene Infrastruktur nötig werden. Der Aufwand bleibt bestehen. Für Agenturen kann eine Mischform passen: den betroffenen Mandanten selbst betreiben, die übrigen extern hosten. Ein einzelner Sonderfall rechtfertigt nicht zwangsläufig den Eigenbetrieb des gesamten Stacks.

Zweitens: dedizierte Versand-IP-Adressen und Reputationsanforderungen, die verfügbare Hostingangebote nicht abdecken. Manche Newsletteranbieter mit hohem Volumen oder Transaktionsdienste benötigen geeignete getrennte Versandressourcen. Viele Mehrmandantentarife verwenden gemeinsame IP-Pools. Sind eigene IP-Adressen und ein kontrollierter Reputationsaufbau tatsächlich erforderlich, kann ein VPS-Modell mit getrennten Reputationsgruppen passen. Der Bedarf muss jedoch belegt sein; dedizierte IP-Adressen sind nicht für jeden Mandanten vorteilhaft.

Drittens: bereits vorhandene interne Fachkompetenz. Beschäftigen Sie aus anderen Gründen ohnehin einen Mailadministrator, kann der zusätzliche Aufwand für weitere Domains geringer ausfallen. Seine Zeit ist dennoch nicht kostenlos: Bereits bezahlte Arbeitsstunden haben Opportunitätskosten und stehen nicht mehr für andere Aufgaben zur Verfügung. Das verändert die Rechnung, ohne den laufenden Betriebsaufwand aufzuheben.

Sicherheitsmaßnahmen für einen gemeinsamen Mailserver

Ein Mailserver für mehrere Domains ist ein attraktives Angriffsziel, weil eine umfassende Kompromittierung den Nachrichtenfluss aller Mandanten gefährden kann. Die folgende Checkliste konzentriert sich auf wirksame Kontrollen statt auf Maßnahmen, die nur den Anschein zusätzlicher Sicherheit erwecken.

Authentifizierte SMTP-Einlieferung sollte über Port 587 mit STARTTLS oder Port 465 mit implizitem TLS erfolgen. Zugangsdaten dürfen dabei nur über eine korrekt abgesicherte TLS-Verbindung übertragen werden, nicht anonym oder unverschlüsselt. Port 25 bleibt für eingehende Server-zu-Server-Mail offen. Unberechtigtes Relaying und die Umgehung der Submission-Regeln müssen dort verhindert werden; legitime eingehende Nachrichten an lokale Empfänger dürfen aber nicht pauschal als lokale Einlieferung abgewiesen werden. Prüfen Sie ausdrücklich, dass Port 25 kein ungeschützter Ersatz für den authentifizierten Versand ist.

Versandlimits je Mandant können den Schaden eines übernommenen Postfachs begrenzen, garantieren aber nicht, dass die IP-Reputation innerhalb von 20 Minuten unbeschädigt bleibt. Sinnvolle Grenzen gelten je Postfach und Stunde sowie je Konto und Tag und orientieren sich an legitimen Versandmustern. Ohne Limits könnte ein gestohlenes Passwort im Beispielszenario 100K Spamnachrichten über die gemeinsame IP verschicken, bevor die Überwachung reagiert. Die im Ausgangsvergleich genannten TrekMail-Limits, etwa 1,000 Nachrichten je Postfach und Tag sowie 6,000 je Konto und Tag bei Starter und 50 SMTP-Einlieferungen pro Stunde bei Nano, sind Beispiele solcher Kontrollen; aktuelle Werte und Geltungsbereiche sind zu prüfen.

Administrative Zugänge benötigen starke Passwörter und möglichst 2FA. Auch 2FA für Postfächer ist wichtig und darf gegenüber administrativer 2FA nicht als nebensächlich behandelt werden: Ein einzelnes kompromittiertes Postfach kann Daten offenlegen und die gemeinsame Versandumgebung schädigen. Bei IMAP-Clients können dafür je nach System Anwendungspasswörter erforderlich sein. Das Administratorkonto besitzt besonders weitreichende Rechte für die Mandantentrennung und muss entsprechend geschützt werden.

Betriebliche Checkliste für den Eigenbetrieb

Beim Eigenbetrieb sind die täglichen und wöchentlichen Aufgaben mindestens so wichtig wie die Erstkonfiguration. Ein gepflegter Postfix- und Dovecot-Stack kann lange laufen. Regelmäßige Wartung, Überwachung und Sicherheitsupdates entscheiden jedoch darüber, ob daraus eine zuverlässige gemeinsame Mailumgebung wird. Die folgende Checkliste zeigt einen möglichen Betriebsrhythmus.

Täglich: Warteschlangenlänge und Versandrate je Mandant überwachen. Ein plötzlicher Anstieg auf das 10× der üblichen Menge kann eine Kampagne oder eine Kompromittierung sein und muss geprüft werden. Den Sperrlistenstatus der Versand-IP-Adressen bei MX Toolbox oder einem vergleichbaren Dienst beobachten. Kontrollieren, ob nächtliche cron-Aufgaben wie Protokollrotation, DMARC-Berichtseingang und Sicherungsrotation erfolgreich liefen.

Wöchentlich: verfügbare aggregierte DMARC-Berichte für alle Mandantendomains prüfen. Neue Newsletterdienste, Zahlungsanbieter oder Vertriebswerkzeuge bringen neue Versandquellen hinzu, die korrekt über SPF und DKIM autorisiert werden müssen. Das Speicherwachstum je Mandant prüfen; bei Postfächern über 30 GB kann je nach Tarif ein Archivierungskonzept oder ein Upgrade nötig werden. Die IMAP-Verbindungszähler von Dovecot beobachten: Bei ausgeschöpften Limits können Client-Synchronisierungen fehlschlagen und Supportanfragen entstehen.

Vierteljährlich: domainspezifische DKIM-Schlüssel nach dem gewählten Sicherheitskonzept rotieren. Im Beispiel wird ein neuer Selektor im DNS veröffentlicht, 48 Stunden gewartet, die Signierung auf ihn umgestellt und der alte Selektor nach weiteren 48 Stunden Überlappung entfernt. Diese Wartezeiten garantieren nichts: Tatsächliche Cachelaufzeiten, verzögerte Zustellung und alte Signaturen müssen berücksichtigt werden. Bei 100 Domains werden hier etwa 8-12 Arbeitsstunden je Quartal angesetzt, ungefähr 40 Stunden pro Jahr allein für diese manuelle Pflege. Hosting kann die Rotation automatisieren, sofern der konkrete Tarif diese Funktion tatsächlich umfasst.

Jährlich: eine vollständige Sicherungsprüfung durchführen, indem die Nachrichten eines Mandanten in einer sauberen Dovecot-Instanz wiederhergestellt werden, sowie Authentifizierungsbackends auditieren. Die Erneuerung von SSL/TLS-Zertifikaten für SMTP und IMAP muss unabhängig davon fortlaufend überwacht werden; verwenden Sie dabei aktuelle TLS-Verfahren. Die im Beispiel genannten 90 Tage bei Let's Encrypt sind kein dauerhaft gültiger allgemeiner Rhythmus, und Automatisierung kann ausfallen. Auch seltene manuelle Fälle gehören in die Überwachung. Die Authentifizierungsprüfung soll insbesondere veraltete Konten finden, deren Domains aus Postfix entfernt wurden, deren Benutzer sich aber noch anmelden können.

Nächste Schritte

Ein eigener Mailserver für mehrere Domains ist technisch gut realisierbar, kann im Betrieb aber viel Zeit beanspruchen. Postfix und Dovecot liefern die bewährte Grundlage; domainspezifische DKIM-Pflege und DMARC-Auswertung verursachen einen wesentlichen Teil des laufenden Aufwands. Ob Hosting günstiger ist, hängt von den tatsächlichen Agenturanforderungen und den aktuellen Angeboten ab.

Das zugrunde liegende TrekMail-Agency-Beispiel nennt $29 pro Monat beziehungsweise $23.25 als monatlichen Gegenwert bei Jahreszahlung, nominal 1,000 Domains × 1,000 Postfächer je Domain, 200 GB gemeinsamen Speicher für E-Mail und TrekMail Drive, domainspezifische DKIM-Rotation, einen Sieve-Editor für eigene Filter, gesonderten Support, 100 Aliase je Postfach und CSV-Import für beispielsweise 50 Kundendomains. Die nominalen Kontenzahlen garantieren keine unbegrenzte Betriebskapazität; Speicher, Versandlimits und tatsächlicher Funktionsumfang sind gesondert zu prüfen. Im beschriebenen Modell erfordert die 14-tägige Testphase eine Kreditkarte. Der kostenlose Nano-Tarif ohne Karte und ohne befristete Testphase sieht 10 Domains × 10 Postfächer vor, um das Dashboard kennenzulernen. Die jeweils aktuellen Bedingungen sind maßgeblich. Domainspezifische Risiken behandelt auch unser Leitfaden zum Hosting mehrerer Domains. Den aktuellen Tarifvergleich finden Sie unter trekmail.net/pricing.