The decision: keep the mailbox, change the MX
Changing email services and changing protection are two different projects. The first moves mailboxes, history, calendars and accounts on phones. The second only touches the path of incoming mail.
That path comes down to one DNS record: the MX, which tells sending servers where to deliver mail for your domain. When it points to the gateway, the gateway receives, analyzes, then hands the message to the mailbox server. This applies to:
- Microsoft 365 (Exchange Online);
- Google Workspace;
- Exchange, on-premises or hosted;
- any other email server that receives over SMTP;
- Klytic Mail, which is just one case among others, not a prerequisite.
This guide covers the case where you keep the mailbox. If you are also changing servers, the guides migrating from Microsoft 365 and migrating from Google Workspace describe that project.
Who changes what
| Setting | Where | Who |
|---|
| The domain’s MX record | DNS zone, at the registrar or DNS host | The person who manages DNS, or the provider to whom it has been delegated |
| Declaring the gateway to the email service | Administration console of Microsoft 365, Google Workspace or the server | The email administrator |
| SPF, DKIM and DMARC | DNS zone | The DNS manager, after an inventory of the servers that send for the domain |
| Domains and delivery server | Gateway | The gateway provider, who prepares the configuration |
The principle on the Microsoft 365 side
Microsoft’s documentation on filtering through a third-party service is clear: the domain’s MX must point to that service, which then delivers to Exchange Online. Microsoft recommends a “partner” inbound connector, which can reject mail that arrives without going through the service. It also recommends enabling Enhanced Filtering for Connectors, so that its own analysis evaluates the real sender rather than the gateway’s address. It advises against simply bypassing its filtering for the third-party service’s addresses.
The principle on the Google Workspace side
Google describes an “inbound mail gateway”: the MX points to the gateway, then the administrator declares its IP addresses in the console. Gmail uses this to find the sender’s real address in the headers, on which SPF and its spam evaluation depend. You can also reject mail that does not come from the gateway. Google specifies that it does not apply the sender’s DMARC policy to mail received through a declared gateway: that check then falls to the gateway.
This guide does not reproduce the screens of these consoles, which change. Follow the official page cited at the bottom of this page when you configure it.
Several servers behind a single gateway
A common case in a group: the parent company on Microsoft 365, a subsidiary on Google Workspace, a third on a legacy server. A single gateway can sit in front of all three.
The principle is per-domain routing. Each domain has its MX pointing to the gateway. For each domain, the gateway knows which server to hand the mail to after analysis. The analysis is shared; the destination changes.
The benefit: the same filtering policy, or different settings per domain, and all decisions readable in one place. A point to prepare: a domain whose mailboxes are split between two servers requires knowing, address by address, where to deliver. This case is studied before the switchover.
What changes, and what does not
Does not change: addresses, mailboxes, history, email software, webmail, phones. The email service’s built-in filter keeps working. Internal rights and sharing remain those of the platform.
Changes:
- The first server to receive the mail. It is the one that sees the original connection and checks sender authentication.
- The mailbox server no longer sees the sender directly, but the gateway. Hence the declaration described above.
- Messages carry the gateway’s decision headers: an administrator can read there why a message was delivered or set aside.
- If the gateway also relays outgoing mail, the domain’s SPF record must authorize it, and the DKIM signature must be published for it. What these mechanisms mean is explained in SPF, DKIM and DMARC.
The day you also change mailbox servers, the gateway can stay in place: only its delivery server changes. The guide migrating email without interruption remains the reference for that day, including for SPF, DKIM and DMARC.
Setup, step by step
- Inventory: domains, the mailbox server for each, applications that send mail on behalf of the domain.
- Gateway preparation by its provider: accepted domains, delivery server, initial rules.
- Declaring the gateway in the email service (inbound connector or inbound gateway), if the platform provides for it.
- Lowering the MX TTL beforehand, then changing the MX. During the DNS cache period, some senders still deliver directly to the mailbox server: this is normal.
- Check: a message sent from an external address should arrive with the gateway’s decision headers.
- Monitoring the quarantine for the first few days, to release false positives and adjust rules.
Rolling back is simple: restore the old MX. It is prepared as for a migration, with a person who has the authority to decide it.
What the gateway does not do
It sees the mail that passes through it, and only that. It does not see messages exchanged between two mailboxes on the same platform that never leave it, nor files shared in online storage, nor user sign-ins.
It therefore does not replace the internal settings of Microsoft 365 or Google Workspace: permissions, two-factor authentication, sign-in alerts, automatic forwarding rules. A stolen account remains first and foremost an issue for the email service. The guide spam, phishing, malware and compromised accounts sorts this out.
Finally, a sender who knows the technical address of the mailbox server can try to deliver to it directly, bypassing the MX. That is the reason for the lockdown offered by Microsoft (partner connector) and by Google (rejecting mail that does not come through the gateway).
Frequently asked questions
Should users be informed?
Their addresses do not change. Do, however, let them know they may receive quarantine notices: see Quarantine, false positives and reporting.
Should the Microsoft 365 or Google filter be turned off?
No. Microsoft recommends leaving its analysis active and configuring it to see the real sender, rather than bypassing it.
How long does the switchover take?
The MX change itself takes effect at the pace of the DNS cache. Preparation depends on the number of domains and servers. For Klytic MTA, see the next section.
Does a gateway in front change the deliverability of our outgoing mail?
Only if it also relays outgoing mail. In that case, SPF and DKIM must take it into account: see SPF, DKIM and DMARC.
Why not simply change email services?
That is a different decision, with different criteria. It is covered in choosing a European business email service.
Where Klytic stands
Klytic MTA sits in front of the email service you have: Microsoft 365, Google Workspace, Exchange, Klytic Mail or any other server. It does not require a Klytic mailbox.
- Onboarding: usually 24 to 48 hours. Klytic prepares the configuration; you change your domain’s MX record, or Klytic does it for you. Declaring the gateway in the Microsoft 365 or Google Workspace console is done by that service’s administrator, and is prepared with Klytic during onboarding.
- Deployment: Klytic cloud, dedicated instance or customer servers. For specific needs, other architectures can be designed with Klytic, for example filtering in the cloud with a relay installed on your premises, or multiple regions.
- Plans: Essential and Advanced. Essential covers authentication, anti-spam, antivirus, phishing, lookalike domains, quarantine, DKIM signing of outgoing mail and recall before sending. Advanced adds financial fraud, time-of-click protection, the DMARC console and log export to a SIEM.
- Trial: 30 days free, without changing email services.
Klytic MTA does not manage the permissions or accounts of your current email service, and does not claim equivalence with the security tools built into Microsoft 365 or Google Workspace: it adds a layer in front of them.
This page describes a principle. The Microsoft and Google consoles evolve: their official documentation is authoritative for the exact steps.
Sources
Consulted in October 2026.
- Microsoft Learn, “Manage mail flow using a third-party cloud service with Exchange Online”: the MX must point to the third-party service; partner-type inbound connector; Enhanced Filtering for Connectors rather than bypassing filtering. learn.microsoft.com
- Google Workspace Help, “Set up an inbound mail gateway”: MX to the gateway, declaring its IP addresses, optional rejection of mail not coming through the gateway; the sender’s DMARC policy is not applied by Gmail to mail received through the gateway. knowledge.workspace.google.com
- RFC 5321, SMTP: intermediate hosts are generally designated by the DNS MX record. rfc-editor.org
- Klytic, Klytic MTA page: modules in the Essential and Advanced plans, options, deployment modes, activation via the MX record. klytic.com
