Investigating TLS usage for SMTP in Exchange Online
Published Mar 22 2019 06:53 AM 145K Views

UPDATE: The dates for disabling of TLS1.0 and TLS1.1 in Office 365 have been set. As things stand, the date for Office 365 WW and GCC customers is June 2020. More information can be found here. The date for Office 365 GCC-High and DOD customers is January 2020 and more information can be found here. These dates are subject to change so please consult the links above for the latest information.

Microsoft is committed to enforcing the best security for our services. As a result, TLS1.0, TLS1.1, and 3DES were deprecated in the Office 365 service. While 3DES is currently in the process of being disabled, there is no date set for disabling TLS1.0 and TLS1.1. That said, we are working towards disabling these TLS versions for Exchange Online endpoints. Should TLS1.0 be compromised, we will have to act quickly to disable it in our service to protect our customers. In the case of SSL3.0, we disabled it in the service just over a month after the compromise was disclosed. Therefore, we urge you to be proactive by verifying TLS1.2 support for all of your email clients and servers as soon as possible. For inbound and outbound connections with email servers and devices that are exposed to the internet, TLS1.0 usage is still around 5%. In most cases, TLS usage is optional for messages that are sent and received on the internet. There are certain scenarios where TLS is mandatory, and if TLS1.0 is turned off in Exchange Online, mail flow will be affected. For example, over 10% of connections from customer on-premises email servers and devices still use TLS1.0. Even worse are the legacy SMTP Auth client submissions that are used by multi-function printers and applications that need to send email. For the SMTP Auth protocol, just less than 50% of connections are still using TLS1.0. These are likely old printers or legacy applications that either have not or cannot be updated to use TLS1.2. To help you identify if your organization is contributing to those numbers, we have developed several reports for Exchange Online. You can use these reports to help determine which clients and servers are still using TLS1.0 and TLS1.1 to connect to the various email protocol endpoints in Exchange Online. These reports can be found in the Security and Compliance Center under the Mail Flow Dashboard.

Emails between your on-premises or partner email servers and Exchange Online

Third-party email servers sending and receiving email to and from our customers are normally beyond our control (or even the control of our customers). However, your on-premises or partner email servers are easily identified because their connections to and from Exchange Online use mail flow connectors. Exchange Online relies on successful TLS negotiations and certificates to identify and use the correct inbound connector. You can also configure outbound connectors to force the use of TLS. If a connector with forced TLS uses TLS1.0 today, messages will fail to send when TLS1.0 is disabled in Exchange Online. To help identify servers that require updating to TLS1.2, we have developed the Connector Report, which is available in our Mail Flow Dashboard in the Security and Compliance Center. To access the report, click View Details and then the Connector Report link. TLSreport1 The Connector Report allows you to review mail flow volume or TLS usage for a specific connector, or traffic to and from the internet that does not use a connector.  The numbers behind the charts are available in the Details Table. For detailed information on the messages involved (including if 3DES is being used), you can download the data using the Request report feature. From that data, you can identify the exact server or device, and you can attempt to upgrade the server or device to TLS1.2.

Email submitted using the legacy SMTP Auth client submission protocol

Email clients can submit email messages using several different protocols. The SMTP Auth protocol is a widely supported protocol that’s used primarily by devices and applications that send automated messages on behalf of customers. Examples include scanner to email devices, or applications that send out alerts or notifications. SMTP Auth is identified by its endpoint smtp.office365.com. To protect against the disclosure of credentials, TLS is mandatory for SMTP Auth. This means that when TLS1.0 is disabled, no messages can be sent from devices or clients that do not support TLS1.2. To help identify which of your devices and applications are still using TLS1.0, we have created the SMTP Auth Clients report. This report is available in the Mail Flow Dashboard where its widget displays the number of mailboxes that have used SMTP Auth in the last week. The report displays pivots for sending volume and TLS version usage. The details table provides the individual users or system accounts and their volume or TLS usage. You can also download the data using the Request report feature, which includes information about whether or not 3DES is being used. TLSreport2

 

Sean Stevenson

32 Comments
Not applicable
Thanks
Brass Contributor

Does this Connected Report still exist, I cannot seem to find it anywhere?

Copper Contributor

https://protection.office.com/mailflow/dashboard --> Outbound and Inbound mail flow --> View Details --> Connector Report.

Brass Contributor

Thanks for the update, however I do not see the link for the connector report here. I believe it was orignaly a link in this block of text, as seen in this link

https://docs.microsoft.com/en-us/office365/securitycompliance/mfi-outbound-and-inbound-mail-flow

 

but the image below is what I see now, I'd be intrested to know if this is isolated to us, or if other people are having similar issues.

 

Also does anyone know if anything needs to be configured before this link becomes avalable?

 

 

2019-07-17_8-22-27.jpg

Brass Contributor

we have download the secure trust portal and even it shows Tls1.2 machine in the report. we have opened many tickets with your support team and it is not worth....

 

related to smtp client auth report. can you please tell us whether they access the smtp connections through application or mobile device.

Copper Contributor
@hobbssj I am having the same issue. The connector report link is missing for us as well.
Copper Contributor

Some information on how to go about resolving these issues would be great. Even if its just a few links to get us started. Also, could you not also capture the IP address / hostname of the device(s) to show in that report. Some of our users have quite a few devices and its not always clear which one is the culprit

Brass Contributor

I have opened a Support ticket for what its worth, I post the results afterword's.

Copper Contributor

"Even worse are the legacy SMTP Auth client submissions that are used by multi-function printers and applications that need to send email" 

 

What is the solution here? We have several MFP that are nowhere near EOL.

Brass Contributor

Eric Bostrom for legacy applications you can follow this article: To start addressing weak TLS use by removing TLS 1.0 and 1.1 dependencies, see TLS 1.2 support at Microsoft.

 

for MFP you can use their Multifunction: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-dev...

 

Copper Contributor

@hobbssj @mikeh1974 go to reports and select the connector report from there

Brass Contributor

Thanks that seem to work. 

 

Copper Contributor
Thank you
Copper Contributor

"You can use these reports to help determine which clients and servers are still using TLS1.0 and TLS1.1 to connect to the various email protocol endpoints in Exchange Online."

 

Edit1: Click 'Request Report' to get the level of detail you need to identify hosts.

 

Edit2: This worked great to get tls1.2 working on server16/sql16sp2.

Copper Contributor
@Eric Bostrom you can see more details when you request the report. The report you receive in your email will have that information.
Copper Contributor

Thanks, figured that out after posting but can't delete comment ;)

Copper Contributor

Is the link provided here working for any one else?

"This will take you to the Secure Trust Portal where you can download your TLS 1.0/1.1 and 3DES reports."

 

It just shows up with the my Office  365 banner across the top but no content.

Brass Contributor

If you can't get to the Smtp Client Submission Report ussing the dashboard, try:

https://protection.office.com/reportv2?id=SmtpClientSubmissionReport&pivot=SenderDomain

 

Cheers.

Copper Contributor

Being a complete IT luddite, I'd like to know exactly how to do the update - we have just lost our IT support which has now left us with a bit of a problem as half the team (in a remote location) are on TLS1 (from the report I just obtained) and bearing in mind the update from Office Centre re moving to TLS1.2 asap, I'd like to know how I achieve that.

Copper Contributor

This is as clear as mud.

 

Prey tell, Microsoft, just what exactly do I need to do to ensure the mail continues to flow?

Copper Contributor

@JohnnyReaction Agreed. I have an MFP that sends scans to users that I'm confident isn't going to be compromised, and the other account is for sending password reminders to users who don't have domain joined computers that get a change password pop-up. Again, I'm confident that account won't be compromised. It's all well and good for MS to tell us what accounts are using the older TLS module. But they don't provide any fix or solution to allow it to continue for those handful of accounts that we want to continue using this.

Copper Contributor

Here is a way to view the connector report.  MS likes to hide things and not update documentation:

2019-07-19 08_56_30-Dashboard - Security & Compliance.png2019-07-19 08_58_03-Report Viewer - Security & Compliance.png

Copper Contributor

@Shawn Housler Don't worry that will change in the re-design that will be introduced next week with a re-design again two weeks after that.

Copper Contributor

Tips for troubleshooting:

 

If you go to the report details (per their instructions or the help of others, the chart view doesn't help much on the troubleshooting side) you can see the users affected.

 

The most common sources would be printers, desktop CRMs sending customer communications, or scanners.  Once you know the user(s) affected it may trigger the memory to which application uses it.  If not, login to the account using the web portal and go to their sent items.  The communications inside will point you directly to the culprit.

 

For scanners and printers you should be able to login to their associated web portal to change the TLS settings (very simple on Xerox).  If a desktop app is causing your headache you will likely need to install an update on your application server, though I highly suggest contacting your application support before doing so.  Your application may need code updates to support the TLS update.  The more notice you can give your providers, the better.  No one wants to miss customer communications and potential revenue.

 

Good Luck!

Copper Contributor

Has any one found a way to trace a smtp message when it shows a smtp message was sent on a certain date with TLS1.0? 

 

How do we go about getting reports for older dates, I was trying to request the SMTP Auth Clients Report but only allows me to go back to June 29th.

 

We have identified an smtp event on June 28th using an older TLS but we are having trouble tracking down that actual message, when I pull detailed reports they all shows TLS 1.2.  What other reports are people using to help identify messages sent with older TLS?

Iron Contributor

From what I can see from our environment there are emails being sent in two ways:

  1.  SMTP Auth - Authenticated 
  2. Unauthenticated

These emails can either use No TLS, TLS 1.0, TLS 1.1, or TLS 1.2.

 

What I think I got from the above is that any devices or applications that authenticate but don't use TLS 1.2 will fail beginning June 1, 2020. It also looks like any devices that send mail using the Office 365 SMTP server that don't authenticate will continue to work. 

 

I understand it to mean the following:

TLS.JPG

 

If that is the case then the short answer is that we must upgrade or replace any devices and applications that authenticate to the SMTP server that don't use TLS 1.2 and we don't have to worry about any devices or applications that don't authenticate.

 

Is that how other see it?

Copper Contributor

@hobbssjThe Connector report link is not displayed is your tenant does not have any mail flow connectors. As mentioned above, you can still find it via the Reports dashboard although there is little action for you to take if you have no connectors.

 

@BGCBatesThe Secure Trust Portal should be accessed via the Secure Score site so I'll have the blog edited to remove the portal link.

 

@Hong_Kong_Techpro_GM@JohnnyReactionAs a service accepting connections, we have limited insights into what servers, applications, or devices you are using to connect to us. This blog and reports can only help you identify which of your mail flow connectors or mailboxes are associated with non-TLS1.2 usage. You need to determine which servers are associated with that connector or which clients or devices are associated with sending from that mailbox. We also do not produce most of those devices or software connecting to us so the instructions and steps to upgrade them to start using TLS1.2 are not known by us. The onus is on you to contact those manufacturers if you do not know how to upgrade them.

 

@DeezuIf you do not want to or cannot upgrade a device or software that is not using TLS1.2, then you will need to set up your own local Exchange server or other mail server on-premises that supports TLS1.0 and TLS1.2. You devices would connect to it locally on your network using TLS1.0 and then it would connect to Office 365 using TLS1.2. You should be able to find instructions on how to set up an Exchange Server with Office 365 very easily online.

 

@John TwohigMail flow between email servers uses "plain" SMTP instead of SMTP AUTH. However there still may be authentication involved such as when mail flow connectors are used. for example, if you have a connector that forces the use of TLS and is currently using TLS1.0, then when TLS1.0 is disabled by us, emails will fail to send.

Brass Contributor

Hi,

 

whether this report will update everyday

Copper Contributor

The report is giving me contradictory information:

 

Report shows 3 clients still "not" using TLS1.2 in the last 7 days.

 

I go to details and download the custom report to show the TLS versions and ciphers - which incidentally I've just spent a few hours updating to TLS1.2 earlier this week - and lo and behold it shows that ALL THREE clients are ACTUALLY using TLS1.2.

 

Please explain what else should be done or what I'm missing.

Thanks.

Copper Contributor

@CTI_Support - I'm in the same boat as you. We have an application that show they are sending as TLS 1.0 and TLS 1.2. There's no details as to what message are sent using what protocol. It's hard to find out why the system delivers as either protocol. I even looked at the message trace and found all the ones sent by this system and it shows it was delivered with TLS 1.2. 

 

I have no clue how to identify which emails were sent with TLS 1.0. This needs some improvement to help us track this down. 

Copper Contributor

The same problem with the report. We have an account in office 365, it is used to send mail from Power BI (with password). The report shows that 1.2 and 1.0 are used. The same problem is with another account that is used in sql 2017.

Copper Contributor

Lots of useful information here in the comments - thanks to all that have posted.  I downloaded the detail report, and assuming I can't do much about issues with inbound e-mail, I ran TLS recipient tests on the few outbound e-mails that were TLS 1.x using this tool: https://www.checktls.com/TestReceiver.  Both of the recipients I tested had expired certificates on their mail server (so again, issues with the mail server on the other end).  As we don't use connectors, no issues for me! :beaming_face_with_smiling_eyes:  Nice to be able to scratch this off the list as a concern.

Version history
Last update:
‎Aug 06 2019 10:16 AM
Updated by: