Multi-domain — one platform, many domains.

A MailGuard cluster manages any number of domains, each with their own detection thresholds, DKIM keys, DMARC reporting and mail filters. A central admin team manages all domains from a single UI.

Architecture, honestly described

MailGuard is single-tenant in the product sense — one installation has one operator, one admin team, one global configuration. What scales arbitrarily is the number of protected domains: a cluster can filter mail for a single domain or for hundreds of domains simultaneously, with individual settings per domain.

This is a deliberate architectural choice. MailGuard isn't built for SaaS hosting providers who want to give hundreds of independent end-customer operators their own login with DB-level isolation — that's what PMG, Mimecast or Hornetsecurity exist for. MailGuard is built for: a company with multiple of its own domains, an IT-services provider centrally managing several customer domains, a hosting provider that wants a maintainable mail-protection platform for its customers.

What is configurable per domain

Detection thresholds

Per-domain spam-reject threshold, spam-quarantine threshold and greylist threshold. A conservative law firm with low tolerance, an aggressive marketing-sender domain with a higher value.

DKIM keys

Per-domain DKIM key pairs, yearly rotation with 30-day DNS lead time, RSA 2048 or ed25519. DKIM signing can be turned on or off individually per domain.

DMARC rua address

Per-domain reporting address for incoming DMARC aggregate reports. A hosted domain has its own reporting address, the main domain has its own.

Digest from address

Per-domain selectable: from which address are end-user quarantine digest mails sent — e.g. quarantine@customer.com instead of a central MailGuard address.

Allow/block mail filters

Allow and block lists can be either global (across all domains) or scoped per domain. Tenant A whitelists their tax adviser, tenant B blocks a competitor domain — both lists are maintained centrally by the operator.

Routing & outbound

Per domain a transport host (back-end mail server), outbound TLS policy (none / may / encrypt / DANE), header-rewrite rules, outbound rate limit, outbound IPs.

What is global (not per domain)

To keep this an honest description — the following is at cluster level and applies uniformly to all domains:

  • Branding (logo, product name, primary colour) — one identity per cluster. If you want to run two domains under two distinct brands, you need two MailGuard clusters or you live with a single brand outward.
  • Admin users — the admin login sees all domains. There is no "tenant admin" role allowed to manage only a specific domain.
  • RBL providers, phishing feeds, suspicious TLDs, Bayes/neural classifier — global detection layers apply to all domains. They can be disabled individually per domain, but the list is global.
  • Mail configuration — Postfix settings, cluster topology, licence, update channel, TLS bootstrap.
  • Quarantine view in the admin UI — the operator sees all quarantined mail across the cluster. There is no UI filtering that would show a hypothetical "tenant login" only its domain's mail — because that login does not exist.

Who benefits from this architecture?

  • Companies with several of their own domains — e.g. firma.de + firma-shop.com + firma.at. Each domain with its own configuration, one central admin team.
  • IT-services providers managing several customers — the provider itself is the only operator. They configure per-customer-domain settings individually, see all quarantines from their central UI, decide releases themselves. End customers receive their daily quarantine digest with self-service actions — they don't log into the admin UI.
  • Hosting providers with customer domains — each cluster carries a bounded number of customers whose mail protection the provider manages centrally. With very many, very independent customers, separate clusters per customer are more honest than a multi-domain setup with merely conventional separation.

And who does not?

If you want to give hundreds of independent end customers their own login with separate quarantine views + separate admin areas + DB-level isolation, MailGuard is not the right tool. Such setups need:

  • Separate MailGuard clusters per end customer (each customer their own cluster, own licence, own data — full isolation, but higher operations load on the provider)
  • Or another product designed for multi-tenancy from the ground up (e.g. PMG, Mimecast)

We communicate this honestly because "multi-tenant" as a marketing term can mean very different things — and it is more important to us that you know what you're buying than that we drop a buzzword.

Questions about whether your setup fits?

We discuss honestly whether MailGuard fits your customer setup — and where it doesn't.

Request a consultation