Skip to main content

Do You Need Office 365 Help?

Most Office 365 customers don't realize they're entitled to better quality support than Microsoft provides. If you're purchasing licenses from Microsoft or elsewhere, you can easily make us your Cloud Solution Provider and you'll be automatically enrolled in Support Plus.

It's easy to switch today. The transition is invisible to end-users. Plus, there's no increase in the cost for licenses, you may even save some money.

Check our our Cloud Services page to learn more, Contact Us to get started, or use the chat icon in the corner to start a conversation. We're happy to answer any questions you may have.

This concludes our commercial interlude. Please enjoy this article with our compliments!

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.

​Connect with TLSSTART
​Secure Tunnel
​Direct Send
​SMTP Relay
Roll Your Own Server​
Login w/ License Required
​On-premises or Hosted Server?
​DNS Changes Needed?
​Supported by All Senders
​Secure (Encrypted) in Transit?
​Combines with Other Options
​No​All Others
​SMTP Relay
​Direct Send
​Limits on Recipients
​Internal Only
​Limits on Volume
Low Volume
Low VolumeHigher​HigherNo Limit

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:
  • 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

STunnel configuration is a turn-key service that we provide as part of a short-term engagement, or you can purchase the needed configuration file from us directly and we'll support you to get it working. Contact Us to start a conversation if this is what you think you need.

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

Important Licensing Notes for Options 1 and 2

Unless you're using Option 3 (Direct Send), you'll need to authenticate to Office 365 using an account and password that has a license for Exchange.

The lease expensive option would be Exchange Online Plan 1 at a cost of $4/month. We have never tried using the Exchange Online Kiosk plan, but it would be a worthwhile experiment. Our guess is that it would probably not allow SMTP connectivity, as it is a very restricted plan with limited intended uses.

You can use the same login for multiple e-mail addresses - as long as you're comfortable with the security and fault-tolerance implications of sharing those credentials across systems. So, not need to run out and buy a plan for each printer or server that you're using.

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,; 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.

If you're a Liquid Mercury Solutions' Office 365 customer, configuring DNS to allow this is covered by our Standard Support for Office 365. If you're purchasing licenses from Microsoft or elsewhere, you can easily transition to our Cloud Solution Provider program and we'll take care of the rest for you. There's no increase in the monthly cost for licenses (in fact your cost may very well decrease), and the transition is invisible to end-users. Check out our Cloud Services page and Contact Us to get started.

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).

Does this seem a bit too complex for you to take on yourself? We have some good news for you! Setting up SMTP relay for your business is fully covered by our Standard Support for Liquid Mercury Solutions' Office 365 customers. If you're purchasing Office 365 licenses directly from Microsoft (or somewhere else), we can transition your plans to our Cloud Solution Provider program in a manner that is cost-neutral and transparent to your users, thus enabling us to support you - and we'll even complete the back-end the work for you. Check out our Cloud Services page and Contact Us to get started.

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.