Site's firewall is blocking certain emails to that site's employees

[mdownes]

I have a client, a one-man show with his own domain, whose email is handled by MS 365. He often visits SME customers and connects to their WiFi. When he does, emails he sends to that site's own employees are sometimes rejected (he was unable to explain exactly what he meant by "rejected"). In those cases, the site's own IT people need to "change settings in their own system" to allow his emails to transit through.

SPF,DKIM and DMARC are all in place and his domain passes all the main checks at mxtoolbox.com/emailhealth with a few warnings, but no errors:

Status Warning smtp abc-dd.mail.protection.outlook.com May be an open relay.
Status Warning dns abc.dd SOA Serial Number Format is Invalid
Status Warning dns abc.dd SOA Expire Value out of recommended range

(domain disguised to protect the innocent)

These warnings seem to appear fairly frequently among other random, well-known domains I've checked with the same tool. I've also checked to see if his domain is blacklisted, but he's in the clear. He did mention that someone told him the shortness of his e-mail address might be a factor (his initials @ his 3-letter domain with 2-letter TLD), but I have never heard of that as a potential red flag in email filtering.

Has anyone any suggestions as to what might be happening for him?

 

[Sky-Knight]

I would advise him to share what he's smoking.

And then I'd get into his M365 tenant and check for, and probably remove all custom mail connectors that are configured in Exchange.

Then remind the customer that the location of the Outlook client is utterly irrelevant to the email transmission process, Exchange does all of that, and it's in Microsoft land... and there is literally no way a network anywhere can influence the SMTP conversation, because that happens entirely on Microsoft's network safely out of reach of everyone on this board, the customer, and anyone else that's not trained well enough to handle this issue.

 

[HCHTech]

Have him provide the details of a message that didn't get through (date, time, recipient, content), then do a message trace on that in his M365 tenant - that will tell you what happened or didn't happen.

 

[YeOldeStonecat]

Really weird....yeah. Outlook to 365 connections are secure, and by default...universally portable. I can connect and send/receive from my office, from my house, from a hotel or VRBO/AirBnB down in Florida, from a Starlink connection on an RV or a boat way out at sea, ...and barring any intentionally deployed conditional access policies with geoblocking or impossible travel policies....if I'm lucky enough to travel to Greece or Ireland or one of those super luxury island resorts out in the Maldives in the Indian Ocean....it should still connect and send/receive...and my recipients will get it.

With some "old school" residential grade servers, sometimes traveling to other ISPs that blocked outbound SMTP could cause problems for POP/IMAP clients. Since back then ISPs used to lock down port 25 if it tried to "leave" their network. But that's a non-issue with 365.

MX Toolbox will always squawk about open relay, and SOA serial number...when checking a client on 365.

Yeah next thing to do is get your hands (eyes) on a the "NDR" or report from the "clients" spam system...to see the details, the why. Without seeing that, you're without the first important step to troubleshoot.

 

[mdownes]

Thanks everyone. This began with him being very keen to know his "email settings". "You're using Microsoft 365, you know your email address and here's your password",wasn't satisfying him and I only today realised why: he thought unless I was giving him POP and SMTP server addresses, I was fobbing him off. Which suggests maybe the reports of emails not getting through and 3rd party techs asking him for settings, was a kind of ruse to secure the settings he wanted. The dangers of a little knowledge, i guess.

 

[britechguy]

unless I was giving him POP and SMTP server addresses

::shudder:: Particularly for the former . . .

 

[Markverhyden]

He often visits SME customers and connects to their WiFi. When he does, emails he sends to that site's own employees are sometimes rejected (he was unable to explain exactly what he meant by "rejected"). In those cases, the site's own IT people need to "change settings in their own system" to allow his emails to transit through.

Several things immediately come to mind. When he connects to their WiFi SSID which network is he on? A Guest or Corporate? Is this all emails? Can he send to himself? Many times Guest networks are tightly locked down and won't allow anything other than port 80 and 443. So the SMTP ports, 25, 465, and 587, are blocked. What happens when he tries via OWA?

 

[mdownes]

Several things immediately come to mind. When he connects to their WiFi SSID which network is he on? A Guest or Corporate? Is this all emails? Can he send to himself? Many times Guest networks are tightly locked down and won't allow anything other than port 80 and 443. So the SMTP ports, 25, 465, and 587, are blocked. What happens when he tries via OWA?

He wouldn’t even have been aware of which WLAN he was on and I’m sure he wouldn’t have tried OWA. But the problem only affected his outgoing emails to the company to whose WiFi he was connected. He could send all other email without any problems. Of course, I only heard about his problems after the fact, so his memory and understanding was is all I have to go on.

 

[Sky-Knight]

You can answer his questions honestly. Sure he's demonstrating a ton of ignorance, but perhaps a nice truth bomb will placate him while perhaps educating him a bit.

He's using the MAPI protocol over an HTTPs proxy. This is configured via autoconfiguration directives provided by Exchange Online. This must be the case because there are 6-8 different connection pipelines that move information between Outlook and the Exchange server. It's not just mail, it's also voice, chat, file, and security controls.

By default M365 does allow use of POP3, IMAP, and SMTP, however all three of these protocols should be disabled or strictly controlled lets you make it extremely easy for bad actors to hack the tenant. Enabling modern authentication basically covers this need, which is enabled by default if you use Security Defaults.

Any attempt to manually use the above protocols will cause issues, due to the above.