Hosted Exchange – Undeliverable Mail

By Shaun Ewing · · 4 mins read · Tech

I’ve installed and configured Microsoft Exchange numerous times before, however I recently had a requirement to install Microsoft Exchange 2010 SP1 in Hosting mode for a client. Exchange hosting mode is designed for those who provide Exchange hosting services to multiple tenants or organisations within the one platform, and is the successor to Microsoft Hosted Messaging and Collaboration (HMC).

Being familiar with Exchange and the Exchange Management Shell (Exchange in hosting mode does not have the graphical console) I found the installation and configuration fairly straightforward. I did however encounter a problem during my testing phase in that I was unable to send mail between organisations on the platform.

The Problem

When attempting to send mail between organisations on the platform, a non-delivery report (NDR) indicating that message delivery had failed would be received by the sender. This report is as follows:

Delivery has failed to these recipients or groups:
[email protected] ([email protected])
A problem occurred and this message couldn't be delivered. Check to be sure the e-mail address is correct. If the problem continues, please contact your helpdesk.

Diagnostic information for administrators:
Generating server: testdomain1.example
[email protected]
#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##

In this case my installation of Exchange had two hub transport servers each handling mail to and from the Internet as per the following diagram:

Mailflow Diagram

And that is inherently where the problem lies. In Exchange hosting mode, each organisation is logically separated from each other. This means that mail flow between domains will still perform a normal DNS lookup and attempt delivery to the MX record(s).

While this has many security and other benefits, the non-delivery report is generated when the sending hub transport server connects back to itself in an attempt to deliver the message. The hub transport server detects a potential loop and refuses to deliver the message.

When searching for a solution to this problem I came across a blog post by Antoine Khater that suggested creating a new internal send connector that forced messages e-mail internal domains to be processed by Exchange without performing a DNS lookup.

While that was appropriate for Antoine’s local lab environment, for a larger Exchange deployment it wasn’t an option for a number of reasons including:

  • The system uses an automation control panel with the potential for thousands of domains. Updating send connectors for each new customer was not an option even if it was automated.
  • This would cause mail to be processed internally. Tenants emailing each other would receive internal out of office replies, etc.
  • This would remove enhanced security provided by the client segregation. If, for example somebody added ‘gmail.com’ to their list of domains it would be processed internally and used to intercept mail destined to Gmail users.

The Solution

There are a few solutions to this problem as discussed below:

Separate outbound and inbound hub transport

This is the option that I went with and involves provisioning additional servers with the hub transport role.

By configuring this option you will keep one set of hub transport servers for receiving mail, and another set of hub transport servers to send mail per the following diagram:

Mailflow Diagram

To do this you will need to modify your Internet send connector so that mail is only sent outbound from your outbound servers, eg:

new-SendConnector -Name 'To Internet' -Usage 'Custom' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false -SourceTransportServers EXHUBOUT01,EXHUBOUT02

Configure a smart host

This problem can also be resolved by configuring all outbound mail to be delivered through a smart host first. That smart host could be something as simple as a Linux machine running Postfix, or a high performance mail processing and filtering platform (eg: IronPort).

To do this you need to create a smart host in the Exchange management shell as follows:

new-SendConnector -Name 'Send To Smarthost' -Usage 'Custom' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $false -DNSRoutingEnabled $false -SmartHosts '[1.2.3.4]' -SmartHostAuthMechanism 'None' -UseExternalDNSServersEnabled $false -SourceTransportServers EXHUB01, EXHUB02

Obviously replace “1.2.3.4″ with the IP address of your outbound mail server, and set the source transport servers as appropriate.

Single server Exchange?

If you’re running Exchange on a single server the only way to get around this problem without configuring an internal send connector is to provision a smart host server. I wouldn’t recommend running Exchange on a single server to begin with for anything beyond lab applications.

Conclusion

By following this advice you should now have Exchange inter-organisation email working with either separate inbound and outbound hub transport servers, or by using a smart host.

I hope this information is helpful!