Most emails from protection.outlook.com being dropped

Problem reported by Paul White - 2/19/2025 at 12:27 PM

Submitted

One of my clients reported that an external user was having problems sending them emails. My Client is on Smartermail Build 9168 (Feb 6, 2025). The external user is hosted by outlook.com At first I checked the logs and didn't find their email anywhere, so I thought that maybe the IP was being blocked at the firewall. Using their SPF, I compared protection.outlook.com list of ips to my firewall, and didn't find any there. Finally I had the user send me an email to my gmail account, so try to see if they were using a different IP. I got their IP on gmail. searched the SMTP logs on smartermail, and found a ton of entries, but 99% of them seem to just drop the connection. I even went through and whitelisted outlook's IPs in case that was causing problems, and still same issue. All these dropped connections seem to be from IPs within the 104.47.X.X block. Here is a snipped from my SMTP logs. Any ideas? And for reference none of the IPs on my mail server are using TLS. Also when checking other IPs part of outlook.com in other blocks, they all seem to be getting through just fine.

[2025.02.19] 13:01:42.969 [104.47.74.44][25309111] rsp: 220 mail.sut-us.org
[2025.02.19] 13:01:42.969 [104.47.74.44][25309111] connected at 2/19/2025 1:01:42 PM
[2025.02.19] 13:01:42.969 [104.47.74.44][25309111] Country code: US
[2025.02.19] 13:01:42.969 [104.47.74.44][25309111] IP in whitelist
[2025.02.19] 13:01:43.013 [104.47.74.44][25309111] cmd: EHLO NAM04-BN8-obe.outbound.protection.outlook.com
[2025.02.19] 13:01:43.016 [104.47.74.44][25309111] rsp: 250-mail.sut-us.org Hello [104.47.74.44]250-SIZE 699050666250-AUTH LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.02.19] 13:01:43.058 [104.47.74.44][25309111] cmd: QUIT
[2025.02.19] 13:01:43.058 [104.47.74.44][25309111] rsp: 221 Service closing transmission channel
[2025.02.19] 13:01:43.058 [104.47.74.44][25309111] disconnected at 2/19/2025 1:01:43 PM
[2025.02.19] 13:03:41.587 [104.47.58.42][58900369] rsp: 220 mail.sut-us.org
[2025.02.19] 13:03:41.587 [104.47.58.42][58900369] connected at 2/19/2025 1:03:41 PM
[2025.02.19] 13:03:41.587 [104.47.58.42][58900369] Country code: US
[2025.02.19] 13:03:41.587 [104.47.58.42][58900369] IP in whitelist
[2025.02.19] 13:03:41.612 [104.47.58.42][58900369] cmd: EHLO NAM10-DM6-obe.outbound.protection.outlook.com
[2025.02.19] 13:03:41.614 [104.47.58.42][58900369] rsp: 250-mail.sut-us.org Hello [104.47.58.42]250-SIZE 699050666250-AUTH LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.02.19] 13:03:41.639 [104.47.58.42][58900369] cmd: QUIT
[2025.02.19] 13:03:41.639 [104.47.58.42][58900369] rsp: 221 Service closing transmission channel
[2025.02.19] 13:03:41.639 [104.47.58.42][58900369] disconnected at 2/19/2025 1:03:41 PM
[2025.02.19] 13:10:05.363 [104.47.74.49][16878046] rsp: 220 mail.sut-us.org
[2025.02.19] 13:10:05.363 [104.47.74.49][16878046] connected at 2/19/2025 1:10:05 PM
[2025.02.19] 13:10:05.363 [104.47.74.49][16878046] Country code: US
[2025.02.19] 13:10:05.363 [104.47.74.49][16878046] IP in whitelist
[2025.02.19] 13:10:05.402 [104.47.74.49][16878046] cmd: EHLO NAM04-BN8-obe.outbound.protection.outlook.com
[2025.02.19] 13:10:05.404 [104.47.74.49][16878046] rsp: 250-mail.sut-us.org Hello [104.47.74.49]250-SIZE 699050666250-AUTH LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.02.19] 13:10:05.443 [104.47.74.49][16878046] cmd: QUIT
[2025.02.19] 13:10:05.443 [104.47.74.49][16878046] rsp: 221 Service closing transmission channel
[2025.02.19] 13:10:05.443 [104.47.74.49][16878046] disconnected at 2/19/2025 1:10:05 PM
[2025.02.19] 13:10:40.541 [104.47.73.177][34067073] rsp: 220 mail.whitesites.com
[2025.02.19] 13:10:40.541 [104.47.73.177][34067073] connected at 2/19/2025 1:10:40 PM
[2025.02.19] 13:10:40.541 [104.47.73.177][34067073] Country code: US
[2025.02.19] 13:10:40.541 [104.47.73.177][34067073] IP in whitelist
[2025.02.19] 13:10:40.588 [104.47.73.177][34067073] cmd: EHLO NAM04-MW2-obe.outbound.protection.outlook.com
[2025.02.19] 13:10:40.591 [104.47.73.177][34067073] rsp: 250-mail.whitesites.com Hello [104.47.73.177]250-SIZE 699050666250-AUTH LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.02.19] 13:10:40.638 [104.47.73.177][34067073] cmd: QUIT
[2025.02.19] 13:10:40.638 [104.47.73.177][34067073] rsp: 221 Service closing transmission channel
[2025.02.19] 13:10:40.638 [104.47.73.177][34067073] disconnected at 2/19/2025 1:10:40 PM

6 Replies

Reply to Thread

Jay Dubb Replied

2/19/2025 at 2:43 PM

You can expect the lack of TLS is why Microsoft's server is dropping the connection. There are conflicting docs floating around. Some say Exchange Online will switch to unencrypted transfer in the absence of TLS, and others say it's now mandatory. Who knows what to believe, but your log snippet tends to suggest the connection is dropped right at that point where TLS would normally be negotiated.

Paul White Replied

2/19/2025 at 2:47 PM

What is strange is on other IP Blocks Microsoft is not dropping the connection. Are they rolling this out slowly across their network to give Email Admins a little heads up? I didn't realize TLS had become mandatory these days.

Paul White Replied

2/19/2025 at 2:50 PM

Client that was having trouble forwarded me their bounce message, found this at the bottom of it.

That message almost indicates that my server dropped the connection for lack of TLS, yet I don't have it enabled.

2/19/2025 9:11:49 PM - Server at sut-us.org (199.119.176.85) returned '450 4.4.317 Cannot connect to remote server [Message=451 5.7.3 STARTTLS is required to send mail] [LastAttemptedServerName=sut-us.org] [LastAttemptedIP=199.119.176.85:25] [SmtpSecurity=-2;-2] [MW2NAM10FT088.eop-nam10.prod.protection.outlook.com 2025-02-19T21:11:50.120Z 08DD5125EDDBBEEB](451 5.7.3 STARTTLS is required to send mail)'

Jay Dubb Replied

2/19/2025 at 2:54 PM

It's likely they're rolling it out in stages. If you already have a certificate protecting your Webmail interface (hopefully you do), you could use the same certificate in Smartermail, assuming webmail uses the same FQDN as the SMTP server. If it doesn't, you should be able to add it as a SAN (subject alternate name) on your webmail certificate.

UPDATE:
@Paul White wrote: "...returned '450 4.4.317 Cannot connect to remote server [Message=451 5.7.3 STARTTLS is required to send mail] "

Mystery solved.

Paul White Replied

2/19/2025 at 5:52 PM

I went ahead and setup the same SSL cert I use for the websites, to also handle the SMTP communications via TLS. Emails from the MSFT block are coming in fine now. Thanks for the help!

Brian Bjerring-Jensen Replied

Yesterday at 6:07 AM

I experienced this when our TLSA record wasnt updated after a certificate renewal...

Back to Community Threads

Please leave this box unchecked

6 Replies

Reply to Thread

Tags

Related Knowledge Base Articles