Multi-Domain — eine Plattform, viele Domains.

Architektur ehrlich beschrieben

MailGuard ist Single-Tenant im Produkt-Sinn — eine Installation hat einen Operator, ein Admin-Team, eine globale Konfiguration. Was beliebig skaliert ist die Anzahl der geschützten Domains: ein Cluster kann Mail für eine einzige Domain filtern oder für hunderte Domains gleichzeitig, mit individuellen Settings pro Domain.

Das ist eine bewusste Architektur-Entscheidung. MailGuard ist nicht für SaaS-Hosting-Provider gebaut, die hunderten unabhängigen Endkunden-Operatoren jeweils eigene Login-Zugänge mit DB-Ebene-Isolation geben wollen — dafür gibt es PMG, Mimecast oder Hornetsecurity. MailGuard ist gebaut für: ein Unternehmen mit mehreren eigenen Domains, ein IT-Dienstleister der zentral mehrere Mandanten-Domains betreut, ein Hosting-Provider der eine pflegbare Mail-Schutz-Plattform für seine Kunden möchte.

Was pro Domain individuell einstellbar ist

Was global ist (nicht pro Domain)

Damit es eine ehrliche Beschreibung bleibt — folgendes ist auf Cluster-Ebene und gilt einheitlich für alle Domains:

• Branding (Logo, Produktname, Primary-Color) — eine Identität pro Cluster. Wenn Sie zwei Domains unter zwei verschiedenen Marken betreiben wollen, brauchen Sie zwei MailGuard-Cluster oder Sie leben mit einer einheitlichen Marke nach außen.
• Admin-Benutzer — der Admin-Login sieht alle Domains. Es gibt keine „Tenant-Admin"-Rolle die nur eine bestimmte Domain verwalten darf.
• RBL-Provider, Phishing-Feeds, Suspicious-TLDs, Bayes-/Neural-Klassifikator — globale Detection-Schichten gelten für alle Domains. Pro Domain einzeln deaktivieren ist möglich, aber es ist eine globale Liste.
• Mail-Konfiguration — Postfix-Settings, Cluster-Topologie, Lizenz, Update-Channel, TLS-Bootstrap.
• Quarantäne-Sicht im Admin-UI — der Operator sieht alle quarantänen Mails clusterweit. Es gibt keine UI-Filterung die einem hypothetischen „Mandanten-Login" nur seine Domain-Mails zeigen würde — weil es diesen Login nicht gibt.

Wer profitiert von dieser Architektur?

• Unternehmen mit mehreren eigenen Domains — z.B. firma.de + firma-shop.com + firma.at. Jede Domain mit eigener Konfiguration, ein zentrales Admin-Team.
• IT-Dienstleister der mehrere Mandanten betreut — der Dienstleister selbst ist der einzige Operator. Er konfiguriert pro Mandanten-Domain individuelle Settings, sieht alle Quarantänen aus seinem zentralen UI, entscheidet selbst über Releases. Endkunden bekommen ihren täglichen Quarantäne-Digest mit Self-Service-Aktionen — sie loggen sich nicht ins Admin-UI ein.
• Hosting-Provider mit Mandanten-Domains — auf jedem Cluster eine begrenzte Anzahl Mandanten, deren Mail-Schutz der Provider zentral verwaltet. Bei sehr vielen, sehr unabhängigen Mandanten sind separate Cluster pro Mandant ehrlicher als ein Multi-Domain-Setup mit nur konventioneller Trennung.

Und wer NICHT?

Wenn Sie hunderten unabhängigen Endkunden eigene Login-Zugänge mit getrennten Quarantäne-Sichten + getrennten Admin-Bereichen + DB-Ebene-Isolation geben wollen, ist MailGuard nicht das richtige Werkzeug. Solche Setups brauchen:

• Separate MailGuard-Cluster pro Endkunde (jeder Endkunde sein eigenes Cluster, eigene Lizenz, eigene Daten — vollständige Isolation, aber höhere Operations-Last beim Provider)
• oder ein anderes Produkt das von Grund auf Multi-Tenant-fähig ist (z.B. PMG, Mimecast)

Wir kommunizieren das ehrlich, weil sich „Multi-Tenant" als Marketing-Begriff sehr unterschiedlich auslegen lässt — und uns ist wichtiger, dass Sie wissen was Sie kaufen, als dass wir Buzzwords platzieren.

Fragen zur Eignung Ihres Setups?

Wir besprechen ehrlich, ob MailGuard zu Ihrem Mandanten-Setup passt — und wo es nicht passt.

Beratung anfragen