Email encryption formultiple tenants.From one account.
One partner account with your tenants underneath. Set up S/MIME, OpenPGP, domain encryption and the reader portal once, then hand the configuration to the next customer as a sealed package. Licences come from a pool, and end users see your brand instead of ours.
Why encryption breaks down at the thirtieth customer
Encryption gateways are built for one company. Running them for thirty means running thirty installations.
One installation per customer
An appliance or gateway knows exactly one company: one instance, one certificate store, one maintenance window. With thirty customers, every update, every expired certificate chain and every troubleshooting session multiplies accordingly.
No view across customers
Which tenants already enforce encryption towards a partner domain, and which merely try opportunistically? Without a shared view, only someone logging into each console in turn can answer that.
The rule set drifts apart
Every new installation starts from scratch. What was thought through for the first customer gets rebuilt from memory for the eighth. Two years on, the same policy means something slightly different in every tenant.
Every deal waits on a purchase order
Ordering licences per customer ties each new deal to a contract and an activation step. The effort sits in the ordering process, not in the setup.
How Conbool groups your tenants
What must stay separate stays separate. Administration is what you share.
1. One account, tenants underneath
Each customer is a tenant of its own, with its own data, its own mailboxes and its own outbound path. You create it yourself with a name, a URL slug and a mailer pool, and sit above it as the managing partner.
2. The rule set as a sealed package
Export routing rules, S/MIME and PGP settings, groups and MailGuard policies from one tenant and import them into the next. If a package contains key material, a passphrase seals it, and that passphrase cannot be looked up here either.
3. Licences from a single pool
You buy capacity per module and distribute it across tenants. When a customer comes on board you assign instead of ordering. The portal shows how much of the pool is out and which tenant uses which module.
What the partner portal adds for encryption
No extra module, no surcharge. The partner account is part of the programme.
Tenant list with module coverage
Every customer in one table, together with the modules in use and the licences handed out from the pool. Changing an allocation, adding licences and creating a tenant all happen in the same view.
Configuration package with a preview
Before anything is written, the portal shows what is new, what changes and what stays the same. While a finding is open, nothing is applied.
A default for new tenants
A newly created customer starts with the protection template you defined, either enforcing or observing only. No tenant accidentally goes live unprotected.
Your brand in end-user mail
Quarantine reports, notifications and release mails carry your sender name, an address on your verified domain, your logo and your accent colour. Your customer's users see you, not Conbool.
Search and clean-up across all tenants
A wave rarely hits just one customer. Search once by subject, address or attachment hash across all your tenants and pull the hits out of the mailboxes in one go.
Outbound path per tenant
Conbool Cloud, a dedicated mailer pool on your own IP, or an installation inside the customer's network. The sending path is a property of the tenant, not a second product.
Keys and certificates per tenant
Order S/MIME certificates and have them renewed automatically, manage OpenPGP keys. Separated per customer, in the same interface as the rules, with a log of every renewal.
Conbool versus the usual encryption gateway
What a setup for thirty customers has to do.
Conbool SecureMail | Usual gateway | |
|---|---|---|
| Tenancy model | One account, customers as tenants underneath | One installation per customer |
| Moving the rule set | Sealed package, preview before it is applied | Retyping or a raw configuration dump |
| Licences | Pool per module, freely distributed across tenants | Purchase order per customer |
| Brand towards end users | Your sender, your logo, your colour | The vendor's brand |
| An incident across customers | One search, bulk clean-up in every tenant | Repeated customer by customer |
| Deployment model | Cloud, own mailer or on premises, same administration | Usually fixed to one model |
Statements about the usual route follow the publicly documented prerequisites of common signature services that source people data from Entra ID.
Questions about running multiple tenants
Which email encryption tool can be managed for all customers from one central dashboard?
Can I move a rule set from one customer to the next?
Do my customers see Conbool or me?
How are licences billed?
What if a customer is not allowed to use the cloud?
What happens when a phishing wave hits several customers?
Related solutions
Every customer, one account.
Encryption, protection and signatures for all your tenants from one interface. Under your brand, hosted in the EU, with a German company as your contracting party.