SMTP Namespace Sharing - How it differs in the Cloud

When you enter Hybrid with Microsoft Office 365, you establish a concept called SMTP Namespace sharing to allow mailboxes in the cloud and on-premises to share the same address space such as @contoso.com.

Microsoft Exchange handles SMTP Namespace Sharing with Office 365 in a different manner to implementing SMTP Namespace Sharing with another Exchange Server or third party mail system.

In this blog post we are going to run through how to configure SMTP Namespace Sharing between an Exchange Server and another mail system, and then look at how SMTP Namespace Sharing works with Office 365.

Configuring SMTP Namespace Sharing

Before we talk about SMTP Namespace Sharing, we must first understand the concept of an Exchange Accepted Domain.  There are three types of Accepted Domains:

• Authoritative Domains - This tells an Exchange Server that the "Exchange Organisation" has a recipient (in particular a mailbox) for that inbound email such as recipient@contoso.com and it needs to deliver it locally.  All email address namespaces that your Exchange Servers receive email for need to be setup as Authoritative Accepted Domains.
• Internal Relay Domains - Internal Relay Domains are used when you share a domain between the Exchange organization and a third-party messaging system.  When an Exchange Server receives an email for an email address such as user@contoso.com, it will look to see if a mailbox exists, else send it out a Send Connector.
• External Relay Domains - No mailboxes exist on the Exchange Environment, send it out a send connector matching the address space.  You would use these if your Exchange Server is setup to perform mail cleansing at a transport layer most likely with a third party Transport Agent, then send the email on its way.

For more information please refer to https://docs.microsoft.com/en-us/exchange/mail-flow/accepted-domains/accepted-domains

To configure SMTP Namespace Sharing, you would change the Accepted Domain to an "Internal Relay Domain" and then create a send connector.  An example config would look like this:

Set-AcceptedDomain contoso.com -DomainType InternalRelay

New-SendConnector -Name "SMTP Namespace Sharing for Consoto.com" -Custom -AddressSpaces contoso.com -SmartHosts 10.1.1.54 -SourceTransportServers ExchangeServerFQDN

This will tell all Transport Servers in the Exchange Organisation to perform the following:

1. Look in Active Directory to see if a mailbox exists, if it does route the email to the Mailbox Server and deliver it.
2. If a mailbox doesn't exist, route it out a Send Connector to a remote mail environment for delivery instead of sending the typical 550 5.1.10 RESOLVER.ADR.RecipientNotFound error.

Configuring SMTP Namespace Sharing with Office 365

When you enable Hybrid Exchange using the Hybrid Configuration Wizard (HCW), SMTP Namespace sharing is setup differently.  After you move a mailbox to Exchange Online, it replaces the mailbox on-premises with a "Remote Mailbox" object.  These mailboxes can be viewed in the Exchange Admin Center as "Office 365" Mailboxes or with the following on-premises Exchange cmdlets:

• Get-RemoteMailbox
• Set-RemoteMailbox

Each of these Remote Mailboxes have a "Remote Routing Address" which looks like alias@tenant.mail.onmicrosoft.com.  If we look at one of the Remote Mailboxes in Exchange Admin Centre on-premises, we can see there is a new box to specify the Remote Routing Address.

Note: This can also be set using Set-RemoteMailbox "mailbox name" -RemoteRoutingAddress "avantgarde@tenant.mail.onmicrosoft.com"

In addition, SMTP Namespace Sharing does not require the Accepted Domain be changed to an "Internal Relay Domain".  It should stay "Authoritative" due to these Remote Mailbox objects.

How the Remote Routing Address is Set

By default, when you run Hybrid Configuration Wizard and move a mailbox to Office 365, the Remote Routing Address is set automatically and you never need to touch/look at this value.

We had an incident however for a customer where the Remote Routing Address was getting automatically set to the users primary domain name, not the Office 365 tenant.mail.onmicrosoft.com SMTP namespace.

How Exchange Server sets the Remote Routing Address automatically is unclear.  I can confirm it does not get set by an Email Address Policy.

We have reached out to Microsoft to find an answer, as it is important this is set to the correct value automatically!