How to use Mail Contact to enable outgoing SMTP relay?
Consider the following scenario. You need to deliver emails to/from an application server that receives emails via SMTP. You want to use Exchange Online protection; the application server’s SMTP domain can send emails via SMTP. However, it is not routable or contactable over the Internet and therefore cannot receive replies to sent messages. Your organization’s email system is in a hybrid configuration with an on-premises Exchange server. This server is configured to allow your application servers to relay outgoing emails through Office 365.
Your application server can receive external emails through Exchange Online if it uses a Mail Contact object. This object will accept emails destined for Exchange Online. It will then forward them on-premises for delivery to your application server. In this article, we’ll show you how to do this and troubleshoot common issues you might encounter.
Example SMTP relay configuration
In our example scenario, we have an application server that sends messages as Application.Mailbox. It has two different email addresses: the internal address used in the application server and the address defined in 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
The Office 365 email address must relay mail to the on-premises application server. To do this, the non-routable email domain requires a specific connector . This connector must be able 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. However, we don’t recommend this. Running the hybrid setup wizard will remove the domain from the connector.
It is also necessary to ensure that the on-premises environment is able to send mail to the application server, as shown below:
Since the application server needs to send SMTP messages, on-premises Exchange can act as a relay:
After implementing this configuration, the application server can send and receive mail. And everything may seem fine, initially…
Some emails are marked as spam or are not delivered
Mail delivery problems with some mail servers on the Internet are common.
Typically, you check that records, such as SPF records, are configured correctly. You check and see that SPF is configured correctly and that you are not blacklisted. Email delivery is generally good.
However, sending a test email through the application server and analyzing the headers shows some interesting results.
After sending a test message, open the message headers in a client like Outlook. You can then copy and paste the headers into Microsoft’s Message Header Analyzer.
This is a useful tool because it allows you to easily examine the properties contained in message headers. This allows you to quickly identify the issue at hand. In the example below, we’ve highlighted what appears to be the underlying problem:
You can see above that in the return path, the envelope’s “from” address is on the internal domain resdomain.local.
An invalid Return-Path domain is sufficient reason for the receiving mail server to reject the message.
In this example, we can easily reconfigure Office 365 so that the application server relays messages. We will modify the configuration for testing purposes to achieve the configuration shown below:
After making the configuration changes, we will perform the SMTP relay test again, as shown below:
We’ll follow the same investigation process as before and examine the headers of the message upon receipt. Routing directly, rather than via Exchange Hybrid, shows that this time the return path is as expected:
So what’s going on?
Conclusion
Notice the unusual capitalization of the return path in the first example. And note that it’s the exact same address in bold in the Mail Contact subject (the reply-to address):
On-premises Exchange receives the email and uses the Mail Contact object as the envelope address when relaying it to Office 365. It doesn’t change the reply-to address seen by the user, so at first glance, everything behaves as expected.
Although Office 365 has the same Mail Contact object, the behavior is different. Exchange Online does not change the envelope address.
You might consider routing all your application servers directly through Office 365 and Exchange Online. However, this configuration isn’t suitable for many organizations. It requires significant firewall changes, particularly to allow application servers to communicate directly over the internet.
Instead, we’ll choose to fix this issue by updating the contact object on our application servers in on-premises Exchange. The simplest solution is to set the correct address as the reply-to address in the email contact:
Summary
Migrating your applications to relay and receive mail via Exchange Online Protection and Office 365 is a smart move. It ensures that messages are properly protected both when they leave your organization and when replies are received. However, it’s not always straightforward. By ensuring you properly define on-premises Mail Contact objects, you can avoid potential pitfalls.
