Change Becomes Effective in Mid-August 2023
A July 31 announcement confirms Microsoft’s decision to honor the DMARC policy setting for sender domains for inbound emails arriving into Exchange Online from mid-August. Damian Scoles discusses the background for the changes to DMARC processing in this article and I don’t intend to repeat them here. Commercial tenants received notification of the change in MC640228 (13 Jul 2023), so the thirty-day notification period is now coming to an end.
From a practical perspective, the call to action is clear. It’s time for every tenant to check its anti-phishing policies to decide how to handle messages detected as spoof. Open the Microsoft 365 Defender portal and go to the Policies and Rules section under Email and Collaboration. You’ll then see the anti-phishing policies configured for the tenant, including the default anti-phishing policy that’s present in every tenant. Edit the policy and scroll down to the Edit actions section. Find the actions Exchange Online Protection takes when email fails DMARC checks.
DMARC Policy Options
As shown in Figure 1, three options exist for messages that Exchange Online Protection spoof intelligence considers to be spoofing because they fail explicit DMARC authentication and the sender’s policy (published in DNS) specifies “reject.” Those options are reject, quarantine, or deliver the message to recipient mailboxes. Given the amount of email-transmitted threats that exists today, I consider it a bad idea to allow messages through to user mailboxes, even if the email goes into Junk Email. Quarantining messages means that someone needs to process those items, which can become quite an overhead.
Overall, the best idea is to reject the message outright and force Exchange Online to send a non-delivery notification to the sender:
550 5.7.509: Access denied, sending domain phishingareus.com does not pass DMARC verification and has a DMARC policy of reject
Attackers won’t care that their spoofing attempt failed. Legitimate email that’s rejected will hopefully cause the administrators of that domain to figure out why this happened (probably due to some misconfiguration of DNS records). Either way, rejecting messages moves the responsibility away from you, which seems like the right approach to take. It’s why my tenant rejects any email that fails DMARC checks.
Using Other Email Hygiene Services
All of the above works as described when Exchange Online handles email for a domain (the MX record points to Office 365). Many organizations use third-party email hygiene services to filter and cleanse the inbound mail stream before email reaches Exchange Online. In this scenario, different conditions apply. Microsoft says:
“If the tenant recipient domain’s MX record points to a different email security solution that sits in front of Office 365, then ‘Honor DMARC’ will not be applied because the information about the sending infrastructure is likely affected by the complex mail flow routing. However, if enhanced filtering for connectors is enabled, we do apply “Honor DMARC” even when MX is pointed to 3rd party, and it will be treated as normal incoming messages.”
The bottom line is that if your tenant uses a third-party email hygiene service, it’s time to review processing to make sure that everything works after Microsoft implements its changes later this month.
Battling the bad stuff that circulates in email is an ongoing struggle. Closing gaps help. This is an example of closing a gap. It’s a good change. Go reject that spoofed email!