SMTP Relay with Microsoft Online

Posted on May 29, 2010 by MessageOps Team

Lately we’ve been seeing a lot of questions around SMTP relay with Microsoft Online so we wanted to take a few minutes here to write down our thoughts.

First, here’s a high level overview of what is required for an application to relay off Microsoft Online. (Click here for the official requirements from Microsoft)

1. The sending application must connect to the Microsoft Online relay servers on port 587.
2. The sending application must support TLS.
3. The sending application must authenticate with the Microsoft Online.

In working with our customers, we are finding that a lot of home grown applications and multifunction devices (fax, scan, printer), don’t support TLS and some don’t support connecting to a non-standard mail port.

If your applications do meet those criteria, there are a couple more things to keep in mind:

4. Your domain must be authoritative in Microsoft Online before you are allowed to relay.
5. The account you authenticate to the relay server with must be the same account as the from address on the messages you send through the relay.

Let’s dig into these items a little more and describe what they mean and also show you how to configure a local IIS SMTP server to relay mail.

Since relaying only works for authoritative domains, it makes it almost impossible to test relaying before all users are migrated. One thing you can do to test is create an account with a username of user@company.microsoftonline.com . Since your Microsoft Online Routing domain (company.microsoftonline.com) is authoritative in Microsoft Online you can authenticate with an account from this domain and relay mail from that account.

So you might be thinking I’ll just create an account called relay@company.microsoftonline.com and use that account to authenticate and then send mail from my various applications using those credentials. The problem is that once authenticated, you can only send mail from the account you are authenticated with. So if you authenticate with relay@company.microsoftonline.com, you’ll only be able to send from that address, you won’t be able to authenticate with that account and then send from another address such as sales@company.com. So each account you want to send as has to have an account in Microsoft Online. If you wanted to send mail from donotreply@company.com you’d need to have an account configured in Microsoft Online for donotreply.

The fact that you can only send as the account you are authenticated with, also kills the idea of having a local IIS SMTP server configured to relay off the Microsoft Online servers. The idea here is that you have a local IIS SMTP server which allows all your internal applications to connect to port 25 without authentication or TLS. The IIS server is configured with a connector to Microsoft Online which connects to port 587 and uses TLS. Since the connector can ony authenticate with 1 account, if you wanted to use IIS to relay off Microsoft Online, all applications would have to send using the same from address that you halve configured IIS to authenticate with.

So in our opinion, the Microsoft Online relay servers are good if you have POP3 clients that need to send mail out, but not practical in most cases if you have applications that need to send out.

While we’re on the topic of relay, we wanted to try and clarify when you actually need to relay. If you have an internal application that is sending to recipients at Internet domains which you don’t own (hotmail.com, yahoo.com, anothercompany.com etc.) then you need to use a relay. If your applications are only sending to internal recipients, you don’t need to relay. You can configure the application to send mail directly to mail.global.frontbridge.com on port 25 without authentication or TLS. Note, this only works after your domain is authoritative in Microsoft Online. After the domain is authoritative when the application sends mail to mail.global.frontbridge.com over port 25 FrontBridge will accept the mail without authentication or TLS since the recipient you are sending to resides on Microsoft Online.

To deal with the Microsoft Online relay server shortcomings, what some customers do is create a local IIS server which is used to relay mail. We’ll now take a quick look at how easy it is to configure IIS as a relay server. In this scenario IIS will be configured to send mail directly to the end recipient, it will not be routed through Microsoft Online, unless the recipient’s mailbox is on Microsoft Online.

Once the IIS SMTP service is installed, you’ll need to modify a few default settings.

First you’ll need to open the Properties of the Default Virtual Server. From there go to the Access tab, and click the Relay button.

You’ll need to enter the IP addresses of the hosts that you want to relay.

Next click on the Messages tab and review the maximum message size, the default of 2 MB might be too small.

The final setting you’ll likely want to review is the Advanced Delivery options, which can be found on the Delivery Tab, and then clicking the Advanced button.

Here you specify the host name that will be advertised when this server connects to the remote hosts. It’s best practice to have the IP address of the mail server resolve to this hostname when a reverse lookup is performed on the IP. You can also configure a smarthost on this page that all outgoing mail will be sent through.

At this point, the IIS server is ready to send mail, but there are a few more things you’ll probably want to do to help ensure that messages sent through the server don’t get flagged as spam.

1. Ensure the IIS server can connect to remote mail servers over port 25. It doesn’t need to accept incoming connections, it just needs to be able to connect to remote hosts on port 25.

2. Ensure the IP address that the IIS server is sending from has a PTR record created in the external DNS. If you are unsure what the external IP of your mail server is, send a test message to an external account and look at the message headers to determine the IP Addresses. Then use nslookup to query the IP to see if there is a reverse record for it. As mentioned earlier, its best practice to have the IP resolve to the name configured in Advanced Delivery Options.

3. Update your SPF record to include the IP address of the new IIS server.

Once you have these settings configured, you should be able to test your new relay server. When sending to remote hosts during your testing, check out the message headers to make sure the SPF record is working properly and your messages aren’t being rejected or marked with a high Spam score.

As always, if you have any questions, or would like assistance setting up a local relay server, contact us at support@messageops.com. Also, if anyone has other ways to work around the limitations, please share!

http://www.messageops.com/smtp-relay-with-microsoft-online