How to use Mail Contact object to enable outgoing SMTP relay

Consider the following scenario – you have a need to deliver email to and from an application server that receives email via SMTP. You want to use Exchange Online Protection, the SMTP domain of the application server can send email via SMTP, however it isn’t routable or contactable via the internet, and therefore can’t receive replies to messages sent. Your organization’s email is setup in a Hybrid configuration with on-premises Exchange Server, which is configured to allow your application servers to relay email outbound via Office 365.

One way to allow your application server to receive email from the internet via Exchange Online is by using a Mail Contact object. This will accept email to Exchange Online, and then relay the mail back to on-premises for delivery to your application server. In this post, we’ll show you how to achieve this, and how to resolve common issues you might encounter.

Example configuration of SMTP relay

In our example scenario, we’ve got an application server sending messages as Application.Mailbox. It has two different email addresses – the internal address used within the application server, and the address defined within Office 365.

In this example, our Office 365 email address is: Application.Mailbox@wordfish.co.uk

The internal application server email address is: Application.Mailbox@resdomain.local

So that the Office 365 email address can be used to relay mail back to the on-premises application server, the non-routable email domain needs a specific connector configured to route messages to the application server’s specific on-premises domain.

It’s important to note that you could instead add the domain to the hybrid connector, but we don’t recommend this. This is because if you re-run the Hybrid Configuration Wizard, which you may need to do periodically, the domain will be removed from the connector created and managed by the hybrid wizard.

The other key component of allowing email to route from Office 365 back to on-premises is ensuring that the on-premises environment is able to send the email to the application server, as shown below:

In a configuration like this, we’ll also expect that because the application server needs to send SMTP messages, the on-premises Exchange environment can be used for relay via the Hybrid configuration, as shown below:

After implementing this configuration, email can be sent and received from the application server. And all may appear well, initially…

Some emails are reported as spam or not delivered

After time, one common issue that may be reported is that there are mail delivery issues with some mail servers on the internet.

Generally, you will check that records, like your SPF records are set up correctly. You check and find that SPF is setup correctly and you are not on any bad reputation lists. Email delivery in general is fine.

However, sending a test email via the Application server and analysing the headers shows some interesting results.

After sending a test message to replicate the issue, open the message headers in a client like Outlook. You can then copy and paste the headers into the Microsoft Message Header Analyser.

This is a useful tool, as it helps you easily examine the properties contained in the message headers and quickly identify the offending issue. In the example below, we’ve highlighted what appears to be the underlying issue:

You’ll see above that we can see in the Return-Path, the envelope ‘from’ address, is set to the internal resdomain.local domain.

While this is valid on the internet, many receiving mail servers will consider an invalid Return-Path domain enough of a reason to mark the message as spam, or completely reject the message.

As this example is a lab environment, it is possible to easily reconfigure the network and Office 365 so that messages can be relayed directly from the application server. We’ll change the configuration for testing purposes to the configuration shown below:

Upon making the configuration changes, we’ll re-perform the SMTP relay test, as shown below:

After the message is received, we’ll follow the same investigation process as before and examine the message headers once the email has been successfully received. Routing directly, rather than via Exchange Hybrid shows that this time the Return-Path is as expected:

So, what’s going on?

Conclusion

Look at the unusual capitalisation of the Return-path in the first example and note that it’s exactly the same as the emboldened address in the Mail Contact object (the reply address):

Exchange on-premises is receiving the email then using the Mail Contact object as the envelope-from address when relaying it through to Office 365. It is not changing the reply address seen by the user, so at first glance everything behaves as expected.

Although Office 365 has the same Mail Contact object, the behaviour is not the same. Exchange Online is not changing the envelope address.

You could consider relaying all your application servers through Office 365 and Exchange Online directly. However this configuration isn’t suitable for many organizations, because it requires extensive firewall changes including allowing application servers to directly communicate over the internet.

Instead, we’ll choose to correct this by updating our application servers’ contact object within the Exchange on-premises environment. You’ll find the most straight-forward fix here is to set the correct address as the reply-to address in the Mail Contact, as shown in the example below:

Summary

Moving your applications to relay through, and receive mail via Exchange Online Protection and Office 365, is a good move for many organizations. It ensures messages are properly protected both as they leave your organization and as replies are received. However, it isn’t always straightforward. By ensuring that you set Mail Contact objects correctly on-premises, you can avoid potential pitfalls.