Microsoft 365 hybrid email

A hybrid setup splits one domain between two mail systems: some addresses are Exchange Online mailboxes, the rest are domain accounts here.

One of the two must receive the mail from the internet, look at the recipient, and pass on what isn't its own. Either side can take that position, and which one is the single real decision on this page.

	Microsoft receives first	We receive first
The domain's MX records point at	Microsoft	Us, unchanged
An address it doesn't host is	relayed to us by Microsoft	relayed to Microsoft by us
Filtered and logged first by	Microsoft	Us
The list you keep current	The tenant's mailboxes, which you maintain anyway	The tenant's mailboxes and a matching relayer here
Built from	Third-Party Incoming Mail Gateway	Relay to Your Own Server
Cost of a missing entry	None	We refuse mail to that cloud address

Which one to choose

Microsoft receives first is the simpler setup and what most organizations want. There's no address list to maintain, because Microsoft already knows its own mailboxes.

We receive first is more work. It pays off when you want every message for the domain, including those for cloud mailboxes, filtered, logged, and searchable in your Email Traffic Log here before Microsoft sees it.

Before you start

Write down which addresses are on which side

Each address belongs to exactly one side. The system that receives the mail first decides where it goes, without asking the other side about an address it already knows.

An address that exists in both places receives its mail in one of them; in the other, it never arrives and nobody is told. After a hybrid cutover, a duplicate address is the most common cause of "some mail disappears".

You also need administrator access to the Microsoft 365 tenant, with the domain already added and verified there.

The panel features this is built from

Feature	What it does
The mail gateway settings	On each Mail service, put an external service in front of your mail (Third-Party Incoming Mail Gateway) or behind it (Third-Party Outgoing Mail Gateway). Turning one on changes the published DNS: the incoming gateway replaces the MX records; the outgoing gateway replaces the SPF record and adds the provider's DKIM key. See Third-party mail gateway.
Relay to Your Own Server	The reverse direction: we keep the MX records and pass named addresses to a server elsewhere. See Relay to your own server.
Custom DNS records	Records a provider asks for that the panel knows nothing about: a domain-verification TXT, an autodiscover CNAME, their own DKIM keys. Add them under DNS Records.
Sender verification	The panel publishes SPF, DKIM, and DMARC from your mail settings. With a domain split across two providers, mail leaves from two places and you authorize both. See Sender verification.

Generated records are changed in the service, not the zone

A generated record belongs to the service that produces it, and that service's settings are where it changes. When a provider's record would conflict with a generated one, the answer is a setting on the service.

Microsoft receives the mail first

Mail from the internet reaches Microsoft. If the recipient is a mailbox in the tenant, Microsoft delivers it there; if not, it relays the message to your mail server here, where the address does exist.

Most of the work is on the Microsoft side. Here you turn on one setting and publish a few records Microsoft asks for.

On your side: publish Microsoft's MX records

Open Services, select the zone, then the domain's Mail service, and use Third-Party Incoming Mail Gateway:

1. Turn it on.
2. Under Gateway MX Records, enter your tenant's Microsoft mail host as <priority> <hostname>, e.g. 0 example-com.mail.protection.outlook.com. The exact hostname is in the Microsoft 365 admin center under Settings > Domains.
3. Leave Gateway Source Addresses empty.

Why the source addresses stay empty

That field limits who may deliver mail for this domain to us. Microsoft's sending ranges are large and change over time, so listing them isn't practical. See what an empty source-address list costs.

On save, the panel replaces the domain's published MX records with Microsoft's. The mail service here keeps working as before: the mailboxes here still receive, send, and sign their mail.

On the Microsoft side

Two settings in the Microsoft 365 admin center make the relay work.

1. Accepted domain: Internal relay. In the Exchange admin center, set the domain type to internal relay, not authoritative.

warning

Authoritative means "every address in this domain is mine", so Microsoft refuses mail for the addresses here.

2. Outbound connector. Add a connector from Office 365 to your organization's email server, with the Mail Server hostname from your Mail service page as the smart host. That's the same host your mail clients use, e.g. mail.example-host.net. Use port 25.

Use the server's hostname, not the domain name

The domain's MX records now point at Microsoft, so a connector pointed at the domain sends the message back into Microsoft, and it loops until it fails.

Our server accepts these connections on port 25 with STARTTLS and a certificate for that mail server hostname, so you can turn on Always use Transport Layer Security in the connector; if you also require the certificate's subject name to match, use that same hostname.

An address that exists on neither side is refused while the connection is open, and Microsoft returns the non-delivery report to the sender.

Mail between the two sides

Nothing more is needed:

• Mail from a mailbox here to an Exchange Online mailbox follows the domain's public MX records, which now point at Microsoft, and reaches the cloud mailbox like any other message.
• In the other direction, Microsoft hands mail for an address it doesn't host to the connector, and it arrives here.

Don't create a cloud address here as well

No forwarder, alias, or placeholder account is needed, and creating one is harmful: a forwarder here is an address here, so the mail would stop at it.

While the MX records propagate

Microsoft may refuse mail sent from here to a cloud mailbox with a 550 recipient address rejected error. This resolves itself once the new MX records are in effect everywhere.

What an empty source-address list costs

Gateway Source Addresses normally makes us refuse mail for the domain from any sender other than the gateway. With the field empty:

• A sender can deliver to us directly, bypassing Microsoft's filtering. Our own spam filter still applies to everything we accept.
• Our filter also scans the mail Microsoft relays; we don't trust it as already scanned.

Filling the list in is usually the wrong decision

It restores both, if you're prepared to maintain the list from Microsoft's published endpoint ranges. Most people shouldn't: an out-of-date entry refuses genuine mail.

We receive the mail first

The opposite arrangement. The MX records stay with us, so every message for the domain arrives here and is filtered and logged here. You mark the addresses that are Exchange Online mailboxes as relayers, and we hand each of those messages to Microsoft over SMTP.

On your side: relay the cloud addresses

Leave Third-Party Incoming Mail Gateway off. The MX records staying ours is the point of this arrangement.

Open Services, select the zone, then the domain's Mail service, and edit Relay to Your Own Server:

1. Turn it on.
2. Choose We send it to you. The other method, where your server collects the spool over POP3, doesn't apply; Microsoft doesn't collect mail that way.
3. Set the host to your tenant's mail host, e.g. example-com.mail.protection.outlook.com, from the Microsoft 365 admin center under Settings > Domains. Use port 25.
4. Set TLS to Verified. Microsoft's endpoint always offers TLS with a certificate valid for that name.
5. Leave the username and password empty. That endpoint accepts mail for the tenant's own domains without authentication, like any other MX host.

Then create one Relayer per Exchange Online mailbox: open Email & Identity → Accounts, select the domain, select Create, and choose Relayer. A relayer takes the address and nothing else: no mailbox here, no sign-in, no storage.

There is no catch-all

A cloud address with no relayer here is refused, not passed to Microsoft. Your relayer list has to match the tenant's mailboxes; that's the price of this direction.

Other control panels have the same setting as a default address, default mailbox, or default mail. It's the same thing, and we don't offer it either.

The panel, the API, and the command line can all create relayers, so you can build the list in one operation. This is not a catch-all gives the reasoning.

A duplicate becomes impossible

A relayer takes the name: [email protected] can be a relayer or a domain account, not both. So in this direction the panel enforces "one address, one side" for you. In the other direction, your address list has to, and that's where the mistake happens.

Two consequences of mail passing through our spool:

• A relayer is filtered more strictly than a mailbox here, for the same reason as a forwarder: we pass the message on, and Microsoft counts its spam against us. Spam is refused during the sending server's connection, not filed.
• Mail waits here when we can't reach Microsoft, in a spool that counts against your account's disk quota. We retry with growing intervals, and report a permanent refusal to your postmaster address and to the sender.

On the Microsoft side

Nothing is needed for the mail to arrive: Microsoft's mail host accepts messages for the tenant's accepted domains from anywhere, as it does for ordinary internet mail, without checking where the MX records point.

Keep the accepted domain authoritative. Microsoft receives only the addresses you told us are its own, so it never has to relay anything.

Don't set it to internal relay in this direction

Internal relay tells Microsoft that some addresses in the domain are elsewhere and must be passed on. Elsewhere is us, so a message for an address that exists in neither place would come straight back to the server that sent it.

Left authoritative, Microsoft refuses an address it doesn't host, we report the failure, and you learn that a relayer here has no matching mailbox there. That's the answer you want.

Add your domain as a trusted ARC sealer. In the Exchange admin center, under the email authentication settings, add your own domain to the list of trusted ARC sealers.

We seal every message we accept with ARC on arrival, with your domain's own key. The seal records how the message authenticated when it reached us. Microsoft acts on a seal only from a sealer it trusts, and by default it trusts nobody. See DMARC at Microsoft for what this decides.

Optional: an inbound connector with enhanced filtering. The ARC seal settles authentication, but each relayed message still reaches Microsoft from our server's address, so Microsoft's anti-spam judges it by our reputation rather than the original sender's. The remedy is enhanced filtering for connectors (skip listing): add an inbound connector from your organization's email server to Office 365, identified by our mail server's IP address, and turn enhanced filtering on for it. Microsoft then looks past our address to the sender behind it.

Mail between the two sides

Again, nothing more is needed:

• Mail from a mailbox here to a cloud mailbox goes to a relayer, so we accept it locally and relay it to Microsoft with everything else.
• Mail from a cloud mailbox to a mailbox here follows the domain's public MX records, which point at us.

Sender verification with two senders

In both directions, your domain sends from two places, and you authorize both.

DKIM. Keep DKIM active here; the panel signs mail leaving your server with the key it manages. For mail Microsoft sends, turn DKIM on for the custom domain in the Microsoft 365 admin center, then add the two CNAME records it gives you at selector1._domainkey and selector2._domainkey. That's the DKIM key from a third party case. The selectors keep the keys apart, so Microsoft's and the panel's coexist with no coordination.

SPF. Add a custom TXT record on the domain itself with Microsoft's value: v=spf1 include:spf.protection.outlook.com ~all. Leave your SPF policy as it is.

Why you don't combine them yourself

A domain can publish only one SPF record, and the panel produces it. It merges your record with the one it generates, keeping every include: mechanism and the strictest qualifier among them.

The record in DNS then authorizes your mail server here and Microsoft, with nothing copied by hand and nothing taken out of the panel's maintenance.

Run the SPF Check afterwards

Both sides of a hybrid add an include: mechanism, and SPF allows only ten DNS lookups per evaluation.

DMARC on the mail that Microsoft relays to us

This is the forwarding problem in the first direction. A message Microsoft relays to us arrives from Microsoft's servers, so the original sender's SPF no longer matches, and a strict DMARC policy would normally refuse genuine mail.

Exchange Online seals the mail it relays with ARC, and Microsoft is on the platform's list of trusted ARC sealers. That seal carries the result from the first hop, and the mail arrives.

note

Trusted Forwarders isn't needed for this; it's for a provider we don't trust globally. If you do see genuine relayed mail refused, the value to add there is the d= tag from the message's ARC-Seal header.

DMARC at Microsoft, on the mail that we relay

The same problem in the second direction, solved by the same mechanism the other way round.

Our ARC seal, applied on arrival before anything else happens to the message, records the authentication result from that moment. We relay the message with the seal on and the body unchanged, so the seal and the original DKIM signature both reach Microsoft intact.

Whether that helps is Microsoft's decision, not ours:

At Microsoft	What happens to relayed mail
Your domain is a trusted ARC sealer	Microsoft reads the result from the message's first arrival. Mail that authenticated only with SPF survives the relay.
Your domain is not	Microsoft judges the message as it is at that moment. We rewrite the envelope sender to one of ours, so SPF no longer identifies the original sender, and only a surviving DKIM signature can carry DMARC.

Which mail the trusted-sealer entry protects

A message whose only authentication was SPF, with no DKIM signature, from a domain with a strict DMARC policy: that's the message Microsoft can treat as a failure after we relay it.

Most automatic mail from small senders is like this. Add the entry before you cut over, not after the reports arrive.

Optional: send your outgoing mail through Microsoft too

Some organizations want every message, including those from the mailboxes here, to pass Microsoft's outgoing scan and compliance rules. That's the Third-Party Outgoing Mail Gateway, with:

• your tenant's mail host as the destination address
• v=spf1 include:spf.protection.outlook.com -all as the Gateway SPF Record

This is independent of which side receives the mail and works with both directions above.

This route needs a dedicated IP address

Microsoft accepts that traffic only through an inbound connector that authenticates your server, by TLS client certificate or by IP address. Our mail server presents no client certificate when it relays, so the connector has to authenticate by IP address, and Microsoft expects that address to belong to your organization alone.

Ask your provider before choosing this route. The direct path for your outgoing mail needs no dedicated IP address, and most hybrid setups use it.

Autodiscover for the two kinds of mailbox

Microsoft asks for a CNAME record at autodiscover pointing to autodiscover.outlook.com. Add it as a custom record, and Outlook sets up the cloud mailboxes.

note

A mailbox here is set up from its own mail setup page, which gives each user their settings directly, so Microsoft's autodiscover name doesn't get in their way.

Limits to know about

Limit	Detail
Neither direction has a catch-all (elsewhere a default address or default mail).	We accept mail only for addresses that exist. When Microsoft receives first, an address that exists on neither side is refused while its connection is open. When we receive first, an address with no relayer here is refused before Microsoft sees it.
Where the mailbox exists decides the split, on each side.	There's no per-address routing rule to change that.
One relay destination per domain.	When we receive first, every relayer on the domain goes to the same host. You can't send some addresses to Microsoft and others to a different server.
Our ARC seal counts only if Microsoft trusts it.	We seal every message on arrival with your domain's key and relay it unchanged, but Microsoft ignores the seal until your domain is on the tenant's list of trusted ARC sealers.
Relaying your outgoing mail through Microsoft needs a dedicated IP address.	Our server authenticates to Microsoft's inbound connector by IP address, not with a client certificate.