Traditionally, even when moving to the cloud, it’s rare to move everything to the cloud. There is usually a need for an on-premise server for something. Perhaps the need is a physical fax card in a server or local storage for video capturing. When migrating email to the cloud, the main requirement usually still needed is a server running the IIS6 management tools with SMTP relay configured. Any on-premise devices or applications would then send their usually unauthenticated emails through this relay server and its outbound delivery settings to Office 365 would connect to smtp.office365.com through port 587 using TLS.
A positive trend, however, in the last many years is that the devices have been capable of TLS/StartTLS, and therefore are able to send mail directly to Office 365 at smtp.office365.com. More info can be found on the Office 365 blog.
Office 365 has become more and more secure as an ongoing theme. Modern authentication has been introduced, which is supported by Microsoft products. Multifunction devices, UPS units, etc., however, have not updated yet to support Modern Authentication. As such, Microsoft introduced the ability for SMTP AUTH client submissions. As a security recommendation, SMTP AUTH for Office 365 should be turned off for all accounts that don’t need it. The only accounts that would need it are accounts that are connected to by a relay server or newer multifunction devices using a firstname.lastname@example.org address, for example.
To enable or disable SMTP AUTH, there is a new checkbox available for Active Users with a mailbox in Office 365—”Authenticated SMTP.” This is found by clicking the user in Active Users, Mail, then Manage email apps.
Authenticated SMTP needs to be checked to send mail out either through a relay server or direct through a copier/UPS/etc.—essentially wherever modern authentication is not possible.
I had a client where I was decommissioning their last server on-premises and setting up email to be sent directly to Office 365 from their multifunction devices.
After already checking the Authentication SMTP checkbox, sending mail directly from the scanner did not function. However, the SMTP relay server still was functioning.
I discovered what was happening by use of Microsoft Remote Connectivity Analyzer page, https://testconnectivity.microsoft.com/tests/o365, specifically, the Message Header Analyzer tool: https://mha.azurewebsites.net/
This is a Message Header Analyzer, which saves quite a bit of time digging through the text of a message header. To get the message headers from an email, first open the email in Outlook, then click the down arrow in the Tags section.
This will open the message properties along with the message headers. Select all and copy the headers and then paste them into the website and click Analyze headers.
In my troubleshooting I see that the message was going directly from the SMTP relay server directly to Sikich’s spam filter instead of first going through Office 365.
In the SMTP virtual server properties, I found that the check box for “Attempt direct delivery before sending to smart host” was checked. This means the server was functioning as an email server sending mail directly to recipients. This box should not be checked as it will not relay through Office 365 when the box is checked. If the box is checked, then it is likely an incorrect setup as email should flow through Office 365 for SPF, DKIM, and DMARC (if applicable).
(Again, this box should not be checked).
Have any questions about setting up Office 365 SMTP AUTH? Please contact us at any time!