Announcing New DMARC Policy Handling Defaults for Enhanced Email Security

[The_Exchange_Team]

Domain-based Message Authentication, Reporting & Conformance (DMARC) is a standard that helps prevent spoofing by verifying the sender’s identity. If an email fails DMARC validation, it often means that the sender is not who they claim to be, and the email could be fraudulent.

The ‘p=’ value (this stands for “policy”) in a DMARC TXT DNS record represents the sender’s policy for their domain. It tells the receiver what to do if an email fails DMARC validation. There are three possible values for the policy: none, quarantine, and reject. This helps the sender protect their reputation and brand from being spoofed and helps the recipient avoid emails from unverified senders.

Today, we are announcing important changes to our DMARC policy handling that affect both consumer and enterprise customers.

For our consumer service (live.com / outlook.com / hotmail.com), we have changed our DMARC policy handling to honor the sender’s DMARC policy. If an email fails DMARC validation and the sender’s policy is set to p=reject or p=quarantine, we will reject the email.

For our enterprise customers, you can now choose how to handle emails that fail DMARC validation and choose different actions based on the policy set by the domain owner, such as p=reject or p=quarantine. If the recipient domain's MX record points to Office 365, by default, we will honor the sender’s DMARC policy and reject (p=reject) or quarantine (p=quarantine) the email as instructed. However, you can change this behavior and specify different actions for different policies in the Anti-Phishing policy section of the Microsoft 365 Defender portal. Note that 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 message.

We’ve already begun rolling out the new policies, starting July 19, 2023, we’re will continue to rollout them out to our government and 21Vianet clouds. As stated in Message Center posts MC640228 (worldwide and government clouds) and MC640225 (21Vianet), you have until mid-August to modify the policies before they’re enforced.

For messages that fail DMARC validation where the policy is reject and this action is taken on the message, the sender will receive a non-delivery report (NDR) with the following message (using contoso.com as an example):

550 5.7.509: Access denied, sending domain contoso.com does not pass DMARC verification and has a DMARC policy of reject

We encourage you to review your DMARC settings and customize if needed to benefit from improved email security and deliverability.

Learn more:

• (DNS Configuration) Use DMARC to validate email.
• (Security Policies Configuration) Spoof protection and sender DMARC policies in Anti-phishing policies in Microsoft 365 Defender
• (Troubleshooting) 550 5.7.509 and Why does DMARC fail: Email non-delivery report (NDR) and SMTP errors in Exchange Online
• (Blog) Email Protection Basics in Microsoft 365: Spoofing and Impersonation

Microsoft Defender for Office 365 team

[hajekj]

Awesome! Thank you for this!

[Martin Wildi]

So if i get it right, microsoft didn't respect my DMARC settings until now? so they accepted Mails, even if DMARC validation failed and policy was set to reject or quarantine?

just to be sure about what changes...

[Michel de Rooij]

@martin That is correct. Up to now, inbound messages failing DMARC checks did not get rejected nor quarantined (went to junk). Only guess for this non-RFC compliant behavior is someone tried to avoid liability issues. Still, lots of customers I know implemented transport rules to override this behavior. These rules will become obsolete.

[Arindam Thokder]

@Michel de Rooij - The rfc7489, section 6.7 says "Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy". So, what we did till now is not a non-RFC compliant behavior. Also, by default the p=reject used to be quarantined for Enterprise and not sent to Junk. 

[Michel de Rooij]

@Arindam True, same applies to DKIM SPF, etc. Nobody can force receiver to do anything. Yet, NTA7516 (secure email) compliance here dictates receiving parties should implement these techniques for non-repudiation, so it's a thing here for gov, healthcare & edu a.o.

[Michel de Rooij]

By the way, if we are paraphrasing the RFC, one could argue that treating p=reject as p=quarantine is a non-RFC compliancy (6.3) :)

[Brian .]

Nothing mentioning DMARC and looking like this:

https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-phishing-policies-...

has shown up in our Anti-phishing policy, so I guess it's still rolling out.

[Rafał_Fitt]

@Arindam Thokder 

please correct me if I am wrong:

the table located at https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-phishing-policies-... shows that to get the most compliant behavior (Explicit email authentication failures for p=quarantine DMARC policies are quarantined, and failures for p=reject DMARC policies are rejected), you need to turn "honor DMARC policy" OFF ?

[Thomas Stensitzki]

The mentioned article on Anti-Phishing policy does not cite any recommendation on configuring the policy for hybrid environments utilizing centralized mail flow.

The blog post itself mentions a "different email security solution." Which is not the same as having an on-premises Exchange organization. 

Is disabling the "Honor DMARC record policy when the message is detected as spoof" setting sufficient? 

Are there any dependencies to the inbound connector types, e.g., OnPremises handles DMARC differently automatically?

[Arindam Thokder]

@Rafał_Fitt  - No, to get the most compliant behavior (Explicit email authentication failures for p=quarantine DMARC policies are quarantined, and failures for p=reject DMARC policies are rejected), you need the top left setting in the table which is Spoof intelligence On and Honor DMARC policy On.

[Satyajit321]

"For messages that fail DMARC validation where the policy is reject and this action is taken on the message, the sender will receive a non-delivery report (NDR) with the following message (using contoso.com as an example):

550 5.7.509: Access denied, sending domain contoso.com does not pass DMARC verification and has a DMARC policy of reject

"

What about the admins of the tenant rejecting it, how can they track, trace this. Will it show-up in message trace or Threat explorer. Any other reporting for this.

[fbifido fbifido]

If security is good by default, no one will pay for extra security.

most if not all basic/easy spam/phishing emails comes from hotmail/gmail/outlook/yahoo.

why not prevent this kind of email from leaving your infrastructure?

block them before they can be sent.  make it impossible to change the from & reply-to address.

Security is big money; no email provide wants to stop this kind of email.

No one can make you do something, but if you want to not do something and still ack as if you are right, then you need a way around said law:

"Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy"

DMARC does not need this, because no email provider has to implement DMARC, but yet they put it in, yes. WHY?

[Guido007]

Hi @Michel de Rooij, do you think the transport rules will be overriden or will just become void? Some customers have created the transport rules to honor DMARC but with some tweaks. I wonder if those will take precedence over Microsoft's change.

[DaSven]

Seconding @Thomas Stensitzki question about hybrid scenarios with centralized mailflow.

Technically the last hop, Exchange on-prem, might not be represented in the SPF record also it's not signing mails via DKIM. There is also no reason to put it on the SPF or signing at this point, because that's not the internet facing part; with the exception to Exchange Online. 

I see the following Authentication Results for mails send by systems using our On-Prem Exchange server. For my understanding, those mails would be quarantined by default.

How can we fix this, without weakening security?

spf=fail (sender IP is 1.2.3.4) smtp.mailfrom=domain.tld; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=domain.tld;

[alexandruliviunita]

Can you elaborate if/when the action defined in this new DMARC handling feature can be overridden by allow listing?
Create safe sender lists | Microsoft Learn

[Jeremy Bradshaw]

I don't mean to jump onto a bandwagon but I do find it bothersome that you're choosing to Reject when p=Quarantine, especially when EOP has such an in depth Quarantine in place.  You would think you would Quarantine if p=Quarantine, especially if you are reviewing the topics that led to this decision and blog post in the first place.  It's like actively missing an opportunity to do something slightly better, for untold reasons.

[alexandruliviunita]

@Jeremy Bradshaw - this is not correct, I think you misread.
quote from this article <<by default, we will honor the sender’s DMARC policy and reject (p=reject) or quarantine (p=quarantine) the email as instructed.>>

We don't even have the option to reject if the sender's policy is p=quarantine: Set-AntiPhishPolicy (ExchangePowerShell) | Microsoft Learn

[bwestnedge]

@Alex I think @Jeremy Bradshaw is referring to this statement earlier in the post, which is confusing, given the later statement that you quoted. 

If an email fails DMARC validation and the sender’s policy is set to p=reject or p=quarantine, we will reject the email.

I would guess the author actually means "respect the policy", i.e. quarantine when the policy is quarantine, but the verbiage is unclear. 

[Arindam Thokder]

@Jeremy Bradshaw @bwestnedge - The line "For our consumer service (live.com / outlook.com / hotmail.com), we have changed our DMARC policy handling to honor the sender’s DMARC policy. If an email fails DMARC validation and the sender’s policy is set to p=reject or p=quarantine, we will reject the email." is only for consumer service (live.com / outlook.com / hotmail.com) because they do not have Quarantine.

The next line talks about Enterprise Customers - "For our enterprise customers, you can now choose how to handle emails that fail DMARC validation and choose different actions based on the policy set by the domain owner, such as p=reject or p=quarantine" 

[Jeremy Bradshaw]

Many thanks @Arindam Thokder for clarifying (was already clear in hindsight) and thanks as well @bwestnedge for clarifying what I was trying to say !  That was exactly it.  Well then, all happy times here! #p=truth

[Maxal1917]

What is the process for troubleshooting such rejections for public Hotmail.com account. I use forwarding service and don't usually have issues, but mail from contactcostco.com is being rejected due to DMARC verification. Same emails forwarded to Gmail are delivered just fine. 

[alexandruliviunita]

@Maxal1917 - sounds like spf fails due to forwarding, the only remaining option to pass dmarc is dkim pass and header.d domain alignment with header from.

If you pm me the NDR text including original headers I can point in the right way.

[Maxal1917]

@alexandruliviunita  Sent message, thank you.

[Ching_Hooi]

Interesting topic, where our tenant has enabled Honor DMARC policy; what we found was the policy doesn't seem working as expected. When an email being detected as High Phish/Phish still went to quarantine and not really respecting DMARC. I have a case open with MS and engineer mention that due to precedence.  Order and precedence of email protection | Microsoft Learn

Any idea why SPAM & Phishing detection have higher precedence than DMARC validation & authentication? The failure of validation should be applied action based on domain owner action identify in DMARC.

[reminimod2023]

The referenced article on Anti-Phishing policy contains no configuration recommendations for hybrid environments with centralised mail flow.

The actual blog post mentions a "different email security solution." This is distinct from an on-premises Exchange organisation. Igviews

Is it sufficient to disable the "Honour DMARC record policy when the message is detected as a spoof" setting?

Exist any dependencies between inbound connector types, such that OnPremises automatically manages DMARC differently?

[Brian .]

@Maxal1917 Did you end up unchecking the "honor" policy? We also saw a spate of these failures (various sending domains) when forwarding too, and all the ones that I noticed were to Outlook.com/Hotmail, though there may be others. I was surprised to see this given that the sending domain mentioned in the error is not us, but we're forwarding them so I guess in a way we are. In any case, I hope unchecking the option resolves it.

[Maxal1917]

@Brian . What do you mean exactly by "unchecking the "honor" policy"? Where is this? 

[Brian .]

@Maxal1917 The article that we're posting in here is about this:

https://admin.microsoft.com/?ref=MessageCenter/:/messages/MC640228

So I'm referring to the honor DMARC policy option in the Anti-Phishing policy, which I assume is the cause since it is what changed. Not that I really understand why it fails.

I should emphasize that I don't know if this is actually the solution. I'm still testing it but was earlier wondering if you had already gone down this road.

[Maxal1917]

@Brian . I'm not an enterprise customer, so, I don't have an option to change the policy. I'm referring to this part from the artical above:

For our consumer service (live.com / outlook.com / hotmail.com), we have changed our DMARC policy handling to honor the sender’s DMARC policy. If an email fails DMARC validation and the sender’s policy is set to p=reject or p=quarantine, we will reject the email.

[Brian .]

@Maxal1917 Oh, I completely forgot about that since the bulk of the article was about the enterprise stuff.

That would explain it then. but I think leaves us completely at the mercy of this problem and makes Outlook.com an impractical destination for forwarding.

I'd love to see the Exchange team weigh in on this at this point.

[crobinuk]

This change appears to be causing issues for Microsoft users who forward emails from their Hotmail/Outlook.com accounts to other addresses.

See: https://answers.microsoft.com/en-us/outlook_com/forum/outlk_com-outtop_email/outlook-redirect-rule-s...

We use Mailchimp to send email newsletters to subscribers and have a complete DKIM/SPF/DMARC framework in place. We get lots of DMARC bounces from Hotmail subscribers who are using rules to forward their inbound emails to 3rd party email addresses.

Our email newsletter is getting forwarded to the new address but the mail headers being set suggest that Microsoft's IP is the sender, which will then fail DKIM/SPF checks because of the DMARC policy above.

Our own DMARC policy is *correctly* set to reject emails that aren't authenticated - this IS NOT a sender issue.

I wonder if Microsoft have stopped adding headers like "X-Forwarded-For" from the emails when they are forwarded using rules in Hotmail/Outlook.com...?

[alexandruliviunita]

@crobinuk - autoforwarding should not break dkim signature and if that is aligned to header From domain, dmarc should still pass at final recipient.

you can pm me some headers and I can review if mailchimp is signing dkim properly and point you in the right direction.

[crobinuk]

@alexandruliviunita thanks for your quick reply! I have PM'd you a set of headers with some examples where Hotmail users auto forwarded to Gmail, and Gmail rejects because the *Hotmail* IP address fails an SPF check for the *original* sender's domain.

[Its_the_M365_guy]

If we choose to opt-out today but in future want to opt-in then can we do it?

If we choose to opt-in today and in future intend to not use this feature then can we choose to opt-out in future?

How can we identify the 25 day timer from the original message center announcement? (I Believe this was 25 days from the initial date of July 13th, which would put it as mid august as per the documentation)

[alexandruliviunita]

Can you elaborate if/when the action defined in this new DMARC handling feature can be overridden by allow listing?
Create safe sender lists | Microsoft Learn

Returning with an update for this unanswered question, finally got the feature rolled out on a dev tenant and had time to test how HonorDMARC behaves when colliding with user&admin allows.

Admins can override HonorDMARC enforcement via:

- ETR to set SCL: -1 (Bypass Spam Filtering)

- TABL Spoof Allow

Disappointingly, End Users can also override HonorDMARC enforcement via MailboxJunkEmailConfiguration Trusted Senders (aka Outlook Safe Senders).

Fingers crossed someone gets back to me on this bit about End User override isn't true/expected, if not, that means I'd rather just create ETRs and enforce Reject/Quarantine based on Authentication-Results header value than use this feature.

[Patrick_Ding]

When our external member (domain BBB) emails to a distribution group of our company (domain AAA in MS365), the user would get bounce back for external members in the group: Remote server returned '550 5.7.509 Access denied, sending domain <SenderDomain BBB>.com does not pass DMARC verification and has a DMARC policy of reject.'

This is from original message headers: 

Authentication-Results: spf=fail (sender IP is XX.XX.XX.XX protection.outlook.com) smtp.mailfrom=BBB.com; dkim=pass (signature was verified) header.d=AAA.onmicrosoft.com;dmarc=fail action=oreject header.from=BBB.com;compauth=fail reason=000Received-SPF: Fail (protection.outlook.com: domain of BBB.com does not designate XX.XX.XX.XX(protection.outlook.com) as permitted sender) 

Not sure if it is related to the change. How do we resolve this? The distribution group accepts the email then expands to send out to members. Then bounce back happens at recipient's server. Create a new connector for the member to forward email to member's domain?

Thanks a lot!

Patrick

[Puneeth]

@alexandruliviunita 

Allowing user overrides is as per design. For this particular rollout, we made the decision to allow emails from user overrides, as a significant number of DMARC reject emails included user allows . While we may consider revisiting this in the future, there are no immediate plans to alter this behavior.

[alexandruliviunita]

@Patrick_Ding - 

Authentication-Results: spf=fail (sender IP is XX.XX.XX.XX protection.outlook.com) smtp.mailfrom=BBB.com; dkim=pass (signature was verified) header.d=AAA.onmicrosoft.com;dmarc=fail action=oreject header.from=BBB.com;compauth=fail reason=000Received-SPF: Fail (protection.outlook.com: domain of BBB.com does not designate XX.XX.XX.XX(protection.outlook.com) as permitted sender) 

These auth results tell me this:

- DKIM Signature is AAA.onmicrosoft.com , was the email original DKIM Signed by BBB.com?

If yes, was anything done on AAA.com that could invalidate that DKIM signature?(modifying subject/body/protected header)

- MailFrom was still BBB.com when landing on final recipient who rejects.
I would expect SRS to rewrite spf to AAA.com as long as auth passed on inbound for BBB.com.
I'd say most likely BBB.com auth failed on inbound and that caused AAA.com tenant to send this via Relay Pool : Outbound delivery pools | Microsoft Learn

This is more of an issue with overall BBB.com outbound email auth, won't fix DMARC rejection as SRS will mean MailFrom domain no longer aligns with HeaderFrom

Hope this helps point you in the right direction, if more help is needed PM me an NDR with original headers and I can have another look and perhaps give more details.

[Leighroyyyyy]

@The_Exchange_Team Discovered a bit of a glaring hole here. When EOP honors a p=reject DMARC policy and rejects the message, it sends an NDR with the original message attached.  Well, when the spoofed P2 sender & recipient email address is one of your users, EOP will blindly send that NDR directly to your user, creating a whole bunch of backscatter and security risks inside your organization.

In my opinion, EOP should be silently rejecting these emails, not sending NDRs back to spoofed P2 sender addresses.  Or at least include a configurable option on how you would like EOP to handle these.

[JSC-HFT]

Seeing same thing Patrick reported.  We are signing our emails correctly, and sending emails to a distribution list in TenantA.  This distribution list contains external members from TenantB.  When TenantB gets the emails, they fail for DMARC failure.  Only solution we have found is for them to safe list our domain if they want to keep their DMARC settings turned on.

TenantA does use a 3rd party email gateway in front of their tenant, and they could be modifying the body.  When tenantB receives the email, they see a header.d=tenanta.onmicrosoft.com

[Dclode]

This policy change does seem to have caused a huge problems for email forwarding, as others have noted, even between Outlook accounts. Previously the Anti-Phishing rules would randomly bursts of sending a whole heap of legitimate emails into junk (sometimes just one or two from the same regular sender) - annoying but retrievable if you remember to regularly check junk and hopefully 'train' the system. Now, however, a random (but sizeable) selection of legitimate emails forwarded from other accounts are being rejected entirely sometimes without even being identifiable to see what they are (helpfully, the rejection message on my phone app includes an attachment which lets me read the rejected message but not reinstate or reply to it, which at least has saved me from missing several crucial messages - the desktop version doesn't even allow this).  My forwarded emails come from a large institutional address which has a pretty good security system anyway. As a sole trader I've had to go to great lengths to find out the cause of this problem - which seems to be the upgrade of the dmarc settings - and even more work to try and locate where to change this in the Microsoft 365 Defender/Policies&Rules/Threat policies/Anti-phishing settings. Currently it seems to be giving me a 24-48 hour 'cooling off' period before deciding whether it will let me change the settings for both p=reject and p=quarantine to Quarantine rather than Reject? Super unhelpful for microbusinesses - seems to be no clear response to the forwarding error and no advice on how to set a 'safe forwarding domain' to override this highly disruptive error. (Note: so far it has not rejected ANY actual spam - and still lets through the usual small amount of spam as usual so I'm not sure how this is an improvement). Any thoughts or suggestions appreciated. Danielle

[gauravesi]

Hello Team,

Thanks for enabling the DMARC checks under AntiPhishing Checks in Security Center, I wanted to check if something is changed recently. When somebody tried to use our domains which was on p=reject. We could see in the message trace that the email failed to get delivered with an NDR : 550 5.7.509: Access denied, sending domain contoso.com does not pass DMARC verification and has a DMARC policy of reject.

However when we tried to send some test spoofed emails today, it did not work as expected. @The_Exchange_Team 

[Viktor_Roesen]

@The_Exchange_Team @Arindam Thokder 

What I noticed recently:
If a sender's DMARC record contains "p=reject" and Exchange Online rejects the email due to "DMARC = Spoof / CompAuth = Fail", the recipient will still receive a quarantine notification in Exchange Online. This causes confusion for both the quarantine administrator and the recipient and should be solved differently.

Is this problem known to you?

[fbifido fbifido]

Does Microsoft use DKIM or ARC?

DEF CON 31 - SpamChannel - Spoofing Emails From 2M+ Domains & Virtually Becoming Satan - byt3bl33d3r...

[Loh_CS]

hi expert, may I know how I change the action of DefaultFullAccessPolicy to another?
We experience the issues is when system detect Spoof DMARC, and the message move to quarantine without notification visibly by users.
Cheers,

Loh

[Brian .]

@Loh_CS Good question. Only a very slim minority of things (5% at most) that go to quarantine actually generate notifications for us, and I've never been able to figure out any rhyme or reason for it.

It's not that MS is only sending a notification for ones that it deems to be likely false positives (though this isn't a bad idea), which was my original thought. I now have no idea. It's also seemingly not based on "Quarantine reason" or "Policy type." Your question was based only on anti-phish, but I think if you look in Quarantine you'll find that it's broader than that (also anti-spam and transport rules, at least).

[alexandruliviunita]

@Loh_CS  & @Brian .   - each email security policy (malware filter, spam filter, antiphish, safe attachments) offers the option to configure quarantine policies that apply to each type of detection(spam, phish, spoof, etc…).

Quarantine policies control what access users have to those quarantine types and they also control notifications:

https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/quarantine-policies?vie... 

[Brian .]

@alexandruliviunita I'll take a look at that extremely lengthy page, but it seems odd to me that when someone enables what many assume to be the master switch for notifications (Quarantine policy, Global settings) that that in itself enables notifications only for an ambiguous minority of messages. There has to be better default behavior than that.

[Loh_CS]

@Brian . 

Yes sir, it is very slim but some of them is user verified it is important messages. This is why we change the default policy to Quarantine the messages instead of Reject messages which we lost the control to release it to users.

But I can't find a way to really inform the users to verify and request to release.

@alexandruliviunita 

Thanks, sir, for the great link, we already follow the practice to create our own quarantine settings for different filters. But cannot find the way to apply it to this honor DMARC after we try to enable enhanced filtering feature.

[John_Percival]

I too am having problems with this impacting emails that are auto-forwarded or redirected (using a rule) from one consumer Microsoft account to another. To reproduce:

1. Set up an email redirect rule to send email from account1 @ example.com to account2 @ example.com

2. Get someone who has a dmarc reject policy to send an email to account1 @ example.com

Expected behaviour:

- email is delivered to inbox of account1 @ example.com and account2 @ example.com

Experienced behaviour:

- email is delivered to inbox of account1 @ example.com but generates a NDR from account2 @ example.com ("Access denied, sending domain [#sender-domain#] does not pass DMARC verification and has a DMARC policy of reject.")