Settings to Send SMTP E-mail

​

This article contains information compiled from several customer requests.

May 2018

Many of our customers have appliances or servers that need to be able to send e-mail via SMTP. In most cases, these are things like printer/scanner/copiers with scan-to-email capabilities or custom software that includes e-mail notifications.

For a long time, these systems created difficulty in Office 365 because they did not fully support the stringent encryption requirements for connecting to Exchange Online for purposes of sending e-mail. Microsoft put these high standards in place to prevent abuse of their e-mail servers (for sending spam/malware) and to protect the privacy of their users.

What are these requirements exactly? Specifically, Microsoft wants the e-mail client to start encryption as early in the process as possible. This setting is known as STARTTLS (or sometimes TLSSTART). For those not in the know, TLS is just a more recent iteration of what most folks know as SSL, the essential encryption that secures web browsers everywhere.

E-mail clients will generally have 3 possible encryption settings: none, use TLS/SSL, or use TLS at start (thus STARTTLS).

Software written prior to 2015 will more than likely not offer this third most-secure option. In fact, even some Microsoft products written recently, such as Microsoft Azure Backup Service, do not offer it.

Clients attempting to send e-mail via Office 365 will get booted immediately for failing to start their session with the appropriate level of encryption.

Nevertheless, customers still require that their equipment and servers will work as designed. So what are we to do?

Available Options

Before we get into technical specifics, let's do a brief overview that can help you decide which option is right for your situation. We'll gloss over most of the technical details that will be covered later or are adequately explained in the Microsoft support page (at the bottom of this article). Instead we just want to briefly touch on requirements, limits, and other pros-and-cons.

Option 1: Connect Directly to Office 365 Using the Correct Settings

This should always be the first thing to try, if your client application supports the correct settings.

Doing things with way will allow you to send e-mail to both users inside and outside your organization.

• Server Hostname: smtp.office365.com
• Port: 587 (recommended) or 25
• Encryption: Enabled + StartTLS (if your client does not show StartTLS, try using regular TLS encryption)
  
• Authentication: Provide the username/e-mail and password for the Office 365 account with an Exchange mailbox
• From address: sender's login must have Send As permission
  
• Limits: 30 messages a minute; 10,000 recipient e-mails per day
  

As a final note, make sure that the sender has permission to Send As the e-mail address listed in the From field for the e-mail.

Option 2: Configure STunnel

Up until recently, the only option that worked consistently would have been to create something called a secure tunnel.

You can think of a secure tunnel as basically a VPN connection for the e-mail traffic. Unsecured e-mail goes into one end of the tunnel, say at your office. It gets packaged up in a secure wrapper, then shipped over the Internet to Office 365 servers, where it is unpacked normally. Return traffic from the server is unpacked and the process is reversed, so the sender is able to receive the reply that says e-mail was transmitted successfully.

Once the secure tunnel is established, connections behave exactly like they do for Option 1, above. In fact, you can also combine this option with any of the other methods listed below.

The key benefit to using a secure tunnel is that it enhances the security of all e-mail transmissions, regardless of which option you combine it with. So, for example, if you're sending application doesn't support TLS encryption at all, you can use this method to ensure that messages send to and from Office 365 are secured while in transit over the Internet, regardless to whether you're authenticating to a mailbox or using the Direct Send / SMTP Relay option.

Creating a secure tunnel can be accomplished in many ways, but the one we like best is to use a software called STunnel.

Unfortunately, using this approach has two drawbacks.

The first is that it requires you to have a system on-premises (or near your hosted SMTP service) to install and configure the tunnel on. While STunnel comes in both Windows and Linux flavors, this requirement has prevented some customers from being able to take advantage of it - either because they lacked the know-how, or they did not have full control over their server environment (such as when using cloud solutions).

The second is that setting up and testing STunnel to work correctly with Office 365 is not exactly clearly documented anywhere. Getting the magic mix perfect is something that took our company a lot of effort to achieve, which is why you won't find that information posted here online for free.

To sum up, here are the things that might prevent you from using STunnel:

• No available server(s) to install it on
• Only server is Linux based and nobody can figure out how to install/configure STunnel on it
• Inability to get the configuration options working for Office 365
• Can't afford to pay for professional outside help
  

Fortunately, STunnel is not our only option anymore, so for the majority of customers we recommend the alternative.

Option 3: Use Direct Send to Send the E-mail

This option will work for most multi-function devices but possible not for every e-mail service you may use, because it can only send e-mail within your organization.

• Server Hostname: Your MX endpoint, for example, contoso-com.mail.protection.outlook.com; replace "contoso-com" with your email domain, swapping dots for dashes; you can also view this setting under Office 365 Admin Center > Settings > Domains
• Port: 25
• Encryption: Enabled
• Authentication: not required
  
• From Address: Any address ending with your domain; doesn't even need to have a mailbox.

You'll also want to add the public IP address(es) for your SMTP sender(s) to the SPF record for your domain, in order to prevent the e-mails from being flagged as spam.

Option 4: Configure SMTP Relay

This configuration is similar to Option 3 (Direct Send) with a couple differences. It is slightly hard to configure, and it allows some things that Direct Send alone will not, such as sending e-mail to outside parties. Microsoft recommends doing this only when necessary.

The first step is to completely all the things that you would have done to configure Direct Send, so we won't repeat those options here.

Once that's completed, go to Exchange Admin Center under Mail Flow and create a connection between your SMTP sender and Office 365. You can use a the sender's public IP address to whitelist the connection, or a certificate if your server supports this options and/or the public IP address may change frequently.

Creating a relay will not only allow you to send e-mails to external users, but will also raise the limits on the number of e-mails which can be sent (though Microsoft is a bit coy about what the actual limit will be raised to).

Option 5: Use Your Own SMTP Server

If all else fails, you can always configure your network and servers to deliver e-mail from your own SMTP server, either on-premises or in a hosted environment such as Azure. We'll note that as of this writing, we've never yet had a customer who was required to do this - but your mileage may vary.

More Information

If you'd like to review these configurations in more depth, Microsoft has written a comprehensive support page for configuring SMTP - including a side-by-side comparison between the different options, their features, and limitations.