SMTP Relays with Office 365 Hosted Exchange

Let’s talk about SMTP relays. A relay is typically needed when an application or device does not natively support the type of connection an SMTP server requires. I see this most often with customers who use 365’s hosted exchange for their email, because 365 requires that connections be established over a TLS encrypted port. It also requires them to successfully authenticate with a username and password. If you use the Office 365 Hosted Exchange, then you may be familiar with this issue already. Especially if you are trying to send emails from a legacy program or scanner/printer.

To clarify, those requirements are for sources trying to send an email FROM 365. This is different from sources trying to deliver a message TO 365. If I were to send a message from a 3rd party server, over a non-encrypted port, to a mailbox hosted in 365, it would be accepted without any problem. If I wanted 365 to send a message on my behalf, such as from an application or a multi-function printer/scanner, it would then require a TLS connection and proper authentication. It is possible to have an application or scanner just send the message directly to the internet, without routing through 365. The problem is there’s a high risk of that message being flagged as spam or as spoofed, and will likely be rejected or quarantined. This is mostly due to SPF records inside of DNS.

I’ll write about SPF records in a future article, and then link to it here. Make sure you subscribe to my newsletter, so you get notified when that article and others are published!

So in situations like this, the only solution is to use a relay. The SMTP relay feature in Windows Server’s Internet Information Services (IIS) role can support TLS and authentication for its upstream connection, while also accepting anonymous or plain-text connections from downstream devices. That means the application or device that wouldn’t work with 365 directly, could connect to the relay and the relay can pass the message on to 365.

With the “why” out of the way, we can move on to the “how”. I’m going to describe the process with IIS only, because there’s a good chance you already have at least one Windows Server in your environment. Which means the only investment you would have to make is a bit of time and a single 365 email license. No additional hardware or software would be required.

Step one: Create a 365 user for the relay.
  1. This is the account your new relay server will use to satisfy the authentication requirement. You’ll need to login to your company’s Office 365 Admin portal. (Tip: When logging into any Microsoft website, use Private Browsing, Incognito Mode, etc. I always have trouble with Microsoft properly logging me out and deleting sessions/cookies from my browser. I think it’s related to the session sharing they have across their multiple domains.)
  2. Once you’re logged in, select the Add a user option from the main dashboard.
  3. Now you’ll need to fill in the appropriate information for the new mailbox. I used a generic name for my example below, but I’ve seen others use the address [email protected] or [email protected] Choose whatever you think is appropriate for your environment. I strongly recommend creating your own password though, rather than allowing 365 to automatically generate one. Temporary passwords from 365 cannot be used to login from any program or device until it’s been changed by logging in, as the user, in the web portal. Creating a password yourself, removes that extra step. Once you’re done click the Add button. You’ll then get the option to have the username and password emailed to you. You may want to save that email, in case you need to add another relay or setup another application/scanner in the future.
  4. It will take 5-10 minutes for 365 to fully process the new user and to create a mailbox. While you wait, continue with the section below for installing IIS.
Step two: Install the IIS Role (Server 2012 R2)
  1. From the Server Manager, select Add roles and features.
  2. In the Add Roles and Features Wizard, select Role-based or feature-based installation, then click Next.
  3. Select the server you’d like to use. By default, the wizard should automatically select the current server. Click Next.
  4. Select Web Server (IIS) from the list of available roles. When you make the selection, a new window will appear listing required features to install. Click the Add Features button, and then click Next.
  5. Select SMTP Server from the list of available features. Similar to the previous step, a new window will appear listing other required features. Click the Add Features button, and then click Next.
  6. On the role services selection page, make sure that Basic Authentication under Security is selected, then click Next.
  7. Double-check your selections on the Confirmation screen, and then click Install.
  8. Once the install is complete, you can click Close to exit the wizard. Restart your server, if prompted.
Step three: Configure the SMTP Virtual Server
  1. From Server Manager, select Tools, then select Internet Information Services (IIS) 6.0 Manager. Be sure to select the option that has “6.0” in the name. See the screenshot below.
  2. Expand the current server, right-click the SMTP Virtual Server, and select Properties.
  3. On the Access tab:
    1. Select Authentication and make sure Anonymous access is selected. Click OK.
    2. Click Connection, select Only the list below, click Add, and enter the IP address(es) of the printer or server hosting your application. Click OK.
    3. Click Relay, choose Only the list below, click Add, and enter the same IP address(es) as you did above.
  4. On the Delivery tab:
    1. Click Outbound Security. Choose Basic authentication, enter the credentials for the Office 365 user you created earlier, and check the TLS encryption option. Click OK.
    2. Click Outbound Connections and enter 587 in the TCP port box. Click OK.
    3. Click Advanced and enter into the Smart host field. Click OK.
  5. Restart the Virtual SMTP Server by right-clicking on SMTP Virtual Server and selecting Stop. Right-click again and select Start.

Note: For steps 3-2 and 3-3 above, you have the option of selecting Allow except the list below, and leave the lists blank. This is not recommended because it would allow any device on your network to send messages through your relay and from your 365 account. This is especially dangerous if one of your computers becomes infected with a virus that tries spreading itself via email. It could cause your domain to become blacklisted on a RBL (Realtime Blackhole List) and start getting flagged as spam or known-to-be-dangerous.

I’ll go into greater detail about how to prevent every device from sending unauthorized emails to the internet, plus other standard security practices, in a future article. Make sure you subscribe to my newsletter, so you don’t miss it!

  1. In order for any application or device to use the relay, you’ll need to make sure connections on port 25 are allowed through Windows Firewall, and any other endpoint management firewalls you’ve installed.
    1. Open Windows Firewall with Advanced Security. You can search for it from your start menu, to locate it quickly.
    2. Under Inbound rules, you’ll want to click the New Rule action to launch the New Inbound Rule Wizard. Choose Port as the type of rule you would like to create, and click Next.
    3. Select TCP for the port type, select Specific local ports and enter 25 in the text field. Click Next.
    4. Make sure the Allow the connection option is selected, and click Next.
    5. Deselect the Public option on the Profile screen. If your relay is public facing (which it should not be!), this will prevent any devices outside of your domain and local network from connecting to the relay.
    6. Give your new inbound rule a proper name and description. You can see my example below. Then click Finish.

Note: This rule will technically allow ANY device on your local network (even malicious items) to establish connections to the server, because Windows Firewall doesn’t provide the granularity we would normally prefer. Keep in mind that the relay service listening on port 25 still has its own requirements for using the relay. So even though any device would be able to make a connection, the service will still ignore all requests from every IP not listed in steps 3-2 and 3-3 above.

Step four: Configure SMTP settings for your software or hardware

This step is hard to explain in detail, without knowing from what you are trying to send emails. What you’ll need to do is tell your application or scanner to use the IP address of your server (now running IIS) as its SMTP server, and to use port 25. It’s also very important to have the “from” address match the 365 user you created earlier. If you don’t enter the same address, you may get permission errors from 365 and the message may fail to send.

If you are trying to configure a printer/scanner, you can normally access the settings for your printer if you enter its IP address into your web browser. This usually makes it easier to change the settings, rather than using a smaller screen on the printer itself. In some cases, there may even be settings that are only available through the web browser.


That’s it. You should now be able to send emails to your new SMTP relay server and have them relayed and sent from your Office 365 account. The limitation with this setup is that the relay server can ONLY send as the 365 account you created. In my example, that means all messages sent through the relay will come from [email protected] I do have a method for changing this behavior, and allowing the relay to send as multiple other accounts. I’ll explain that process in my next article!


If you have any questions or comments, I’d love to hear them. Leave a message below, or use the contact page to email me privately. Remember to subscribe (top-right) and to follow me on twitter so you don’t miss any of my upcoming posts. At the time of this writing, my planned articles include “Using Multiple Accounts with a SMTP Relay”, “Fight Email Spoofing with SPF Records”, and “Security Best Practices and Beyond”.

Leave a Reply