Update 21/03/2018: Microsoft have dialed back on how quickly messages are marked as spoofed and, thus, moved to the Junk E-Mail folder. However, the guidance is to still properly implement SPF/DKIM/DMARC to be future proof. After all, at some point in the (near) future, Microsoft plans to turn up the aggressiveness of the filtering again -rightfully so. However, let’s hope not before communicating more clearly about this!
Over the past few days, there has been an uptake in the number of people reporting an higher-than-usual amount of legitimate messages being moved to the Junk E-Mail folder. In addition, they are marked as being spoofed as well:
While (re)moving spoofed messages is not a bad thing, moving (seemingly) legitimate messages is!
So far, there has been no formal statement from Microsoft on the matter. However, a last-minute addition to the Office 365 roadmap states that new anti-spoofing features are rolling out, therefore possibly hinting what might be causing this particular behavior:
Image: ATP Roadmap – Source
Until Microsoft confirms, we can only speculate whether the new feature is, indeed, the culprit. Fellow-MVP Brian Reid, tweeted that changes were made to Exchange Online Protection (cfr. Roadmap item), and that those trigger a new filtering behaviour where unauthenticated messages are automatically marked and junked. In other words: all messages that have not (correctly) published any of the message authentication mechanisms (SPF/DKIM/DMARC), are at risk of being flagged as spoofed.
Some of my fellow MVPs have noticed the same, and have also reported on it. Amongst them is Paul Cunningham, who runs Practical365.com, where he published an article on the matter. On that same article, Terry Zink – the owner of the anti-spoofing feature in O365 – commented, stating the following:
Image: Terry Zink’s comment – Source
Especially the last sentence is interesting: “However, the long tail of smaller senders has proven problematic”. For now, we can only guess what “smaller sender” means. My best guess would be that if you’re only sending a few messages a day. If true, that would mean a large number of the small/medium organization could fall in that category and therefore be (negatively) affected by the changes.
I look forward to seeing a more elaborate statement from Microsoft on this, possibly further outlining what you can do to revert/alleviate the impact form legitimate messages being marked. For now, it seems you have the following options:
- Ask your users to add the senders to their safe list. On a side-note, this means that other protection features are bypassed too; therefore allowing actually spoofed messages to land in your inbox, should you ever receive one from such source
- Request the sender to correctly implement SPF, DKIM, DMARC; if possible all of them [correctly].
As Terry mentions, a lot of signals are being collected to determine if a message is legitimate or not. However, I also see an increase of messages being marked and junked, despite SPF being implemented correctly. Perhaps the machine learning systems Microsoft is using, need a bit more tweaking…?
The fact that your messages might end up in someone’s Junk E-mail folder is entirely on you. If you haven’t implemented any of the aforementioned authentication mechanisms, you’re doing things wrong. Whilst I cannot argue that setting up SPF, DKIM and/or DMARC is the right thing to do, I also cannot ignore the fact that a lot of senders haven’t done so correctly/properly/at all (choose whatever applies).
As such, more legitimate emails are now being caught whereas they should not be. The behavioral change in EOP/ATP, which seems to be causing quite the stirr, should have been communicated more clearly by Microsoft. At the very least, they should have given administrators the opportunity to prepare for this change, communicate it to their users or – if not already – implement SPF/DKIM/DMARC.
In the end, all Microsoft is trying to do is improve security for Office 365 recipients (and beyond). There’s no doubt that the industry is moving towards a more restrictive way of filtering messages to counter the new methods attackers use, and perhaps Microsoft was the first to do so. Instead of fighting this change, I’m all for making sure that you’ve correctly setup message authentication; but I also believe Microsoft could have addressed this a little more gently.
If you need help implementing SPF, DKIM or DMARC, feel free to reach out. In the meantime, make sure to look at this article from Paul where he covers SPF, and how to set it up.