Three operating models
People often talk about “cloud” versus “on-premise,” as if there were two camps. In practice, three models coexist, and they are distinguished by two questions: where the machine runs, and who runs it.
Operating an email system means applying updates, monitoring the queue and disk space, renewing certificates, backing up, restoring, responding to an incident at 7 a.m. and maintaining the domain’s sending reputation. Hosting only means providing the machine and the network.
Managed cloud
The provider runs the entire platform. It is generally shared between several customers, with logical separation: each organization sees only its own domains and mailboxes, but the servers, storage and operations teams are shared. It is the simplest model to get started with and the cheapest to run.
Dedicated email
An instance or a server is reserved for your organization. Your data is not stored alongside that of any other customer. The provider still operates it: you are buying isolation, not a workload. This model suits regulated sectors, large volumes, groups that want to clearly separate their companies, or settings that a shared platform cannot grant to a single customer.
Email on your premises
The machine is on your site, in your server room or your data center. Yet someone has to operate it. Either your team does it, or a provider does it remotely, with access you grant. Both choices are legitimate; they do not cost the same and do not provide the same recovery guarantees.
What really changes
Five points distinguish the three models. The others, such as webmail or Outlook compatibility, depend mainly on the software, not on the location.
| Point | Managed cloud | Dedicated | On your premises |
|---|
| Neighbors | Shared platform, logical separation | No other customer on the instance | Your network, your other servers |
| Updates | The provider, on its schedule | The provider, schedule sometimes negotiable | Your team or the appointed provider |
| Backups | At the provider, under its contract | At the provider, sometimes dedicated | To be organized: where, by whom, off site? |
| Who can open a mailbox | Your administrators and the operator | Your administrators and the operator | Your administrators, and the operator if there is one |
| Exit | Export and MX change | Export and MX change | Export, MX change, and the machine to repurpose or recycle |
Neighbors
On a shared platform, a spam campaign sent from another customer’s compromised account can damage the reputation of the shared sending IP address. A dedicated instance, or a dedicated IP address, isolates this risk. On your premises, the neighbor is your own network: an infected workstation can reach the server if it is not segmented.
Who can open a mailbox
This is the line people fill in too quickly. Whoever can restore a mailbox can read it, whatever the model. Location does not remove this access; it only changes the list of people who have it. The useful questions are therefore: who holds the administration accounts, are these accesses named and logged, and does the contract prohibit the operator from opening a mailbox except at the customer’s request. Only end-to-end encryption, for which you keep the private key, for example with S/MIME, makes the content of a message unreadable for the operator.
Exit
The domain name must remain in your name: its MX record designates the server that receives your mail, and you must be able to change it without asking for permission. The rest has to be prepared: export of mailboxes in a standard format, including calendars and contacts, export lead time, deletion after the end of the contract.
Self-hosting is not enough for sovereignty
Putting the server on your premises answers one specific question: where the disks physically are. The guide what is a sovereign cloud points out that at least three others remain: which company operates it, which law applies to that company, and how you get out.
A server within your walls can thus remain dependent on outside parties without it being visible:
- maintenance is done remotely by a provider, whose country and access you need to know;
- backups go to online storage chosen by default, sometimes outside your region;
- filtering of incoming mail is handled by a third-party service, which every message passes through before reaching you;
- mail sent to your clients travels over their servers anyway, which you do not control.
Conversely, a hosted service can be operated by a European company that alone has control over the data, with logged access and a written exit plan. Location remains a useful element, particularly for the record of processing activities. The hosting and sovereignty page details the options offered by Klytic.
The workload people forget
An SME may want control without wanting to be on call. Before bringing email back in-house, take stock of what operating it really requires.
- Monitoring. A growing queue, a filling disk, an expiring certificate, an IP address listed on a blocklist. Every alert must reach someone, including on weekends.
- Outages. When the server stops, senders keep the mail in their queue and retry: incoming mail waits. But nobody can read or send, and phones stop syncing. A single Internet connection or a single power supply becomes a point of failure.
- Network. A fixed IP address, a consistent reverse DNS record, an internet provider that lets outgoing mail through: without them, your messages end up in your correspondents’ spam folders.
- Renewal. Hardware ages, and the operating system and the email software reach end of support. A major version upgrade has to be prepared like a small project.
- Skills. If only one person knows how to restart the service, their vacation is a risk. Documentation and a backup person are part of the cost.
Example. A 60-person manufacturing company (hypothetical case) has a server room and wants its drawings never to leave the site. It installs email on its premises, but entrusts remote operation to a provider: updates, monitoring, restores. Its IT technician keeps control of the hardware and the network. It has the location it wanted, without carrying the on-call burden alone. It still has to write down where backups go and who can connect.
How to decide
Managed cloud is suitable when you want to start quickly, without an operations team, and the logical separation and the operator’s written commitments are enough for you.
A dedicated instance is suitable when a client, a regulated sector or a multi-company group requires that your data not be stored alongside that of any other customer, without you wanting to operate it.
Your premises are suitable when data must not leave the site, when the network must be able to be isolated, or when the directory and infrastructure already exist and are maintained.
Your premises are a poor choice if they serve only to “be sovereign” without anyone having time to operate the system or to back up off site.
The features to require, whatever the model, are in what a business email system must do. Backup and recovery after an outage are covered in backup, deletion and continuity. To compare European providers, see choosing a European business email provider.
Frequently asked questions
Should you host your email server yourself?
Only if you have a reason to keep the machine on site and someone to operate it, or a provider appointed to do so. On the question of sovereignty alone, the operator and the contract matter more than the location.
Is dedicated email safer than a shared cloud?
It removes neighbors from other customers. It does not, on its own, change who can open a mailbox or the quality of backups. Compare these two points in writing.
Can you change models later?
Yes, provided mailboxes can be exported in a standard format and the domain is in your name. The method is that of a migration without interruption.
Does filtering have to be in the same place as the mailboxes?
No. A security gateway can be placed in front of the email system, somewhere else. The guide built-in filter or gateway explains this choice.
Where Klytic fits
Klytic Mail is offered in all three models: in Klytic’s shared architecture, separated by customer, in a dedicated instance, or on the customer’s premises. Whatever the mode, Klytic operates the platform: maintenance, updates, security, monitoring and keeping it in operational condition. The dedicated server is set up on quotation. Switching from one mode to another is possible later.
Hosting is possible in any geographic area matching the applicable jurisdiction, subject to service availability, notably in Europe or Mauritius, or on the customer’s own servers.
Klytic Mail is the email system. Klytic MTA is the gateway that filters mail in front of it; a mixed setup is possible, for example filtering at Klytic and email on your premises. Details of the filter are in built-in filter or gateway.
Klytic teams are prohibited from accessing customers’ email accounts; technical access is controlled and audited. Messages are encrypted at rest with keys managed by Klytic, which protects the storage media; for content unreadable by Klytic, the customer encrypts end to end with its own private key, for example with S/MIME.
What the offering does not cover: an email system you would operate alone, without Klytic, on your own server. Klytic is not SecNumCloud-qualified; if a client requires it, this offering does not meet that requirement.
This page describes a general framework. It does not replace an analysis of your contract or your infrastructure.
Sources
Consulted in October 2026.
- Klytic, Email: Klytic Mail hosting modes (data centers in the region, dedicated server, customer premises) and options. klytic.com
- Klytic, Hosting and sovereignty: three deployment modes, mixed setup, later change of mode. klytic.com
- Klytic, What is a sovereign cloud: operator, applicable law, exit; key ownership and prohibition on Klytic teams accessing mailboxes. klytic.com
- Klytic, Choosing a European business email provider: operation by Klytic whatever the hosting mode. klytic.com
