Noticed an increase in legitimate email going to the junk mail folder lately? You’re not alone.
I’m personally seeing the same high rate of false positives, as are some of my customers. The junked emails have a safety tip inserted by EOP that says:
This sender failed our fraud detection checks and may not be who they appear to be.
I’ve previously written about this safety tip here. The solution then was to fix your SPF records. The same advice applies here too, but it’s a little more complicated now, as you’ll see below.
The common element of each customer where I’ve seen this happening is that they have Office 365 ATP licenses in their tenant. I also have ATP licenses in my tenant. This commonality wasn’t immediately obvious until some background discussions in the last 24 hours, and the posting of this Office roadmap item.
The anti-spoof capabilities referred to in that roadmap item are different, but related to, the ATP anti-phishing policies I wrote about recently here. Anti-phishing policies look for lookalike domains and senders, whereas anti-spoofing is more concerned with domain authentication (SPF, DMARC, and DKIM).
You’ll notice that the roadmap item was just added in the last 24 hours, and was immediately listed as “rolling out”. That means the feature is in production. However, there’s no public documentation or other announcements available to let customers know what to do about it. The reference to “policies” in the roadmap post likely mean there will be admin controls released for this behavior in the near future.
Some tweets from my fellow MVPs explain what’s happening.
This change is one of those “good idea, bad execution” situations that could have been handled a lot better from a communication perspective. But it’s out there now, so what do we do about it?
The first and most obvious step is to review and fix your SPF, DKIM, and DMARC records. I’ve covered SPF in the past here. You can also look at Microsoft’s documentation for SPF, DKIM, and DMARC. That should solve the issue for emails sent from your own domains, for example externally hosted apps that use your domain when sending to your Exchange Online mailbox users.
Once you have your own house in order, the question is then what to do about other senders getting junked when they send email to you? That’s a little tricker, because you can’t fix someone else’s domain authentication problems. You can certainly help them to diagnose the problem and suggest the fixes, but these situations often degrade into a “it’s not our end” finger pointing exercise. If it helps, point them at this advice from Microsoft, particularly this quote:
The newest anti-spoof features help protect organizations from external domain spoof. Office 365 honors emails from external domains having proper SPF, DMARC, and DKIM authentication settings enabling them to pass authentication, and junks messages that fail this authentication. The challenge occurs when external domains do not have these settings properly configured…. (We recommend) admins of sender domains into Office 365 update SPF, DKIM, DMARC configurations so emails can pass the stricter authentication rules.
If all else fails, it may be necessary to apply some whitelisting of domains in EOP for important senders that you want to receive email from. That’s not ideal, as it will also cause other mechanisms in EOP to be bypassed.
On the bright side, the longer the other domain owners ignore the problem, the worse the situation will get for them. Eventually, if they want to reliably send to Office 365 customers, they’ll need to fix their domain authentication problems.