Holdings, associations, and IT service providers often face the same problem: ten domains, ten different spam filters, ten quarantine mailboxes, ten reporting worlds. A central mail security infrastructure would be cheaper, safer, and more auditable – if it remained configurable per domain.
The Problem with "One Domain Per Gateway"
Classical on-prem solutions are happily duplicated per tenant: one gateway for the holding, one for subsidiary A, one for subsidiary B. Each instance needs its own patching, its own license, its own monitoring. It scales with growth, but not with the personnel costs of IT.
The Idea: A Domain Registry in the Mail Security Gateway
SecTepe.Comm solves this with a central domain registry inside the mail security gateway. Each domain is a database row with its own properties:
- Per-domain direction policies: Inbound and outbound can be of differing strictness. A marketing domain needs different outbound rules than a tax consultancy domain.
- Per-domain quarantine: Messages land in the quarantine of the respective domain – including its own release approver group.
- Per-domain DLP: The outbound DLP policies reference the domain. A subsidiary processing credit card data can be stricter than the sister without.
- Per-domain statistics: Dashboards filter automatically per domain – each tenant only sees their own numbers.
Auto-Bootstrap on Deployment
A new domain is usually configured in three places: DNS (MX/SPF/DKIM/DMARC), Mailcow (create domain & mailboxes), and the gateway (policy set). SecTepe.Comm automates the Mailcow side via the Mailcow API and seeds the default policy set on container start from the environment variables DOMAIN and MAIL_ADDITIONAL_DOMAINS. A new tenant domain is therefore productive in 10 minutes – including ZAP (Zero-Hour Auto Purge) against retroactively detected threats.
Direction Detection: How Does the Gateway Know If a Mail Is In or Out?
Sounds trivial, but it isn't: a gateway sitting between Postfix and the internet sees the same TCP connections from both sides. SecTepe.Comm solves this by checking sender and recipient domain against the domain registry: is the sender a local domain → outbound; is the recipient a local domain → inbound; otherwise → relay. The policy selection hangs directly off this direction.
UI-Driven Domain Management
Adding a new domain runs entirely through the web UI: enter the domain, select a policy, click "provision in Mailcow" – done. Removing a domain again offers a safe "retroactive ZAP" button that strips all mails of this domain from mailboxes before the DNS records are deleted.
What It Changes Operationally
- One platform instead of N – one patch cycle, one monitoring board, one audit.
- Consistent policy defaults via templates – what applies at the holding applies automatically at the new subsidiary.
- Tenant separation despite shared infrastructure – every domain owner only sees their data.
- Faster M&A integration: an acquired company is under mail security protection within hours.
Conclusion
Multi-domain mail security in 2026 is not a nice-to-have but, for any organization with multiple business units or subsidiaries, a question of efficiency and safety. The combination of a central platform and fine-grained policy sovereignty per domain is the pragmatic path there – and a prerequisite for keeping NIS-2 audits feasible in complex group structures.