Holdings, associations, and IT service providers often have the same problem. They run ten domains with ten spam filters, ten quarantine mailboxes, and ten ways of reporting. One central mail security setup would cost less, be safer, and be easier to audit. But only if you can still set it up per domain.
The Problem with "One Domain Per Gateway"
Classic on-prem tools are often copied for each tenant. There is one gateway for the holding, one for subsidiary A, and one for subsidiary B. Each copy needs its own patches, its own license, and its own monitoring. This grows with the business, but IT staff costs grow with 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 one row in a database, with its own settings:
- Per-domain direction policies: inbound and outbound rules can be strict or loose for each domain. A marketing domain needs other outbound rules than a tax firm's domain.
- Per-domain quarantine: messages land in the quarantine of their own domain. Each one has its own group of people who can release mail.
- Per-domain DLP: the outbound DLP policies point to the domain. A subsidiary that handles credit card data can use stricter rules than a sister firm that does not.
- Per-domain statistics: dashboards filter by domain on their own. Each tenant sees only its own numbers.
Auto-Bootstrap on Deployment
You usually set up a new domain in three places:
- DNS: MX, SPF, DKIM, and DMARC records.
- Mailcow: create the domain and its mailboxes.
- The gateway: assign a policy set.
SecTepe.Comm handles the Mailcow side through the Mailcow API. When the container starts, it loads the default policy set from the environment variables DOMAIN and MAIL_ADDITIONAL_DOMAINS. So a new tenant domain is live in 10 minutes. That includes ZAP (Zero-Hour Auto Purge), which removes threats that are only found after delivery.
Direction Detection: How Does the Gateway Know If a Mail Is In or Out?
It sounds simple, but it is not. A gateway between Postfix and the internet sees the same TCP connections from both sides. SecTepe.Comm checks the sender and recipient domain against the domain registry:
- If the sender is a local domain, the mail is outbound.
- If the recipient is a local domain, the mail is inbound.
- In all other cases, it is a relay.
The gateway picks the policy based on this direction.
UI-Driven Domain Management
You add a new domain in the web UI. Enter the domain, pick a policy, and click "provision in Mailcow". That's it. When you remove a domain, a safe "retroactive ZAP" button is there too. It strips all mail of this domain from the mailboxes before the DNS records are deleted.
What It Changes Day to Day
- One platform instead of many: one patch cycle, one monitoring board, one audit.
- Same policy defaults through templates. What applies at the holding applies to a new subsidiary on its own.
- Tenants stay apart, even on shared systems. Each domain owner sees only their own data.
- Faster M&A work: a company you buy is under mail security protection within hours.
Conclusion
In 2026, multi-domain mail security is not a nice-to-have. For any group with several business units or subsidiaries, it is a matter of cost and safety. A central platform with fine-grained policy control per domain is the practical way to get there. It also helps keep NIS-2 audits doable in complex group structures.