Installing a local SMTP Relay

The first step is to install an IIS SMTP server that will be used for relaying messages from SharePoint. This can be accomplished by using the ‘Add Roles and Features’ wizard, after completion will add a new option “Internet Information Services (6.0)” in the Server Manager ‘Tools’ menu. This is the interface by which we’ll configure the SMTP server, pictured below:

Configure SMTP Virtual Server Settings

By default the server listens to all addresses on port 25 which is the default SMTP server port, and Anonymous access is enabled; no changes are required to either of those items for our scenario. However, to ensure that we don’t relay messages from any machine we’ll limit the systems that are able to connect to and send through our server. From the “[SMTP Virtual Server #1] > Properties > Access” tab, click the “Connection” button which brings up the following window:

Be sure to specify the IP Address of each of the servers from which messages will be sent. Typically, multiple IP addresses are bound to each SharePoint server to support SSL bindings – be certain to list each of the addresses. In this screenshot, we’ve configured the SMTP Server to allow connections from two of our SharePoint servers.

Next, we’ll also ensure that only our two systems are allowed to relay messages through the SMTP server, which is accomplished by clicking on the “Connection” button on the same “Access” tab of the server properties. Note that we have the same two IP addresses listed, allowing only those two machines to relay:

From here, we need to configure the Office 365 mailbox username/password that the SMTP Server will use when sending messages. This is configured in the “Delivery” tab, using the “Outbound Security” button. Be sure to enter valid credentials for your Office 365 user, and if it’s a newly-created user make note that you’ll need to change the initial password on first login. If you don’t do this, mail will not send despite your best efforts!

Next we need to tell the server to use TCP port 587 when attempting to connect to Office 365, which is set in the “Outbound Connections” option of the “Delivery” tab:

Lastly, we need to specify which server to send mail through, and we do this by clicking the “Advanced” button on the “Delivery” tab. Be sure to specify the smart host as smtp.office365.com and clear the option to “Attempt direct delivery before sending to smart host”: this will ensure that all outbound mail will be sent via Office 365:

Configure Outgoing E-Mail Settings in SharePoint

Finally, we need to let SharePoint know about our new SMTP Server, which is done via Central Administration > System Settings > Outbound E-Mail Settings, as pictured below. Note that I’ve blurred out the values to protect the innocent, but you need to be certain to specify the servername, and your Office 365 mailbox user in the From address.

At this point, we’re ready to test our configuration and we’ll use PowerShell on the SharePoint server to do so. This way we can be sure that each component in our configuration is working, from the SharePoint settings through to the Office 365 mailbox. Open a SharePoint Management Shell and run the following PowerShell snippet:

$sdo = new-object System.collections.specialized.stringdictionary
$sdo.add("to","raymond@dynamicowl.com")
$sdo.add("from","sharepoint@office365domain.com")
$sdo.add("Subject","Test message from SharePoint")
$web = get-spweb "https://intranet"
$messagebody = "This is a test message from SharePoint on-prem"
[Microsoft.SharePoint.Utilities.SPUtility]::SendEmail($web,$sdo,$messagebody)

The output of the command will return “True” (and you’ll receive an email message) if it was successful; “False” indicates that something has gone wrong and the message was not delivered.

When things go wrong

In our experience, there are a few items that you’ll want to verify if outbound email is not flowing as expected, including:

• the SMTP Server service is set to “Manual” start by default; be sure to change this to “Automatic” so that the service starts upon a reboot of your server
• the Windows Server may require a server certificate in order for TLS to be used; this will generate an error in the Event Log and be evidenced by the SMTP Server Properties “Secure Communication” section of the “Access” tab indicating that no certificate can be found for TLS

Conclusion

E-mail is still a critical communication method in today’s business world, and moving email services to the cloud is more common than ever. We can still send email from an on-premises SharePoint server via Office 365 by setting up a local relay and sending mail from an Office 365 mail-enabled user.