How to handle Microsoft treating DMARC reject policy as quarantine?
Matthew Whittaker
Co-founder & CTO, Suped
Published 24 May 2025
Updated 15 Aug 2025
8 min read
For years, email senders have grappled with a peculiar challenge posed by Microsoft: their tendency to treat a DMARC p=reject policy as if it were p=quarantine. This means that even when a domain explicitly instructs receiving servers to reject unauthenticated emails, Microsoft's systems would often simply route them to the spam or junk folder instead of outright blocking them. This seemingly minor difference can have significant implications, especially when dealing with brand impersonation and phishing attempts. Your goal with p=reject is to prevent illegitimate emails from reaching anyone's inbox, including the quarantine folder.
This behavior by Microsoft has often left domain owners feeling frustrated. While quarantine is better than inbox delivery for fraudulent emails, the fact that recipients can still encounter these spoofed messages, even in a junk folder, means the brand is still exposed to potential reputational damage. My aim here is to explore why this happens and what practical steps you can take to achieve true DMARC rejection, minimizing the visibility of fraudulent emails bearing your brand.
Understanding DMARC policies and Microsoft's approach
Historically, Microsoft (and many other mailbox providers) viewed DMARC policies as a suggestion rather than a strict command. Their reasoning often stemmed from a desire to prevent legitimate emails from being inadvertently blocked. If a DMARC record had issues, or if an organization had complex sending practices, a strict p=reject policy could lead to deliverability problems for valid mail. You can find more details on their approach to email authentication on the official Microsoft Learn site.
This cautious approach meant that even if your DMARC record was set to p=reject, Microsoft systems, particularly Outlook and Hotmail, might still deliver emails failing DMARC to the junk folder. This was due to an internal override designed to prioritize deliverability over strict policy enforcement for some legitimate senders. However, recent developments, particularly with the new DMARC policy handling defaults, show a clear shift towards stronger enforcement, especially for high-volume senders.
While this change is a step in the right direction for email security, some senders may still find themselves facing the original challenge or want to ensure absolute rejection. The core idea behind DMARC is to tell receivers what to do with unauthenticated emails purporting to be from your domain. If a receiver doesn't honor your p=reject policy, your brand remains vulnerable to visual spoofing, even if the emails are in a quarantine folder.
DMARC policy interpretation
A DMARC policy is essentially a set of instructions for receiving mail servers. It tells them how to handle emails that claim to be from your domain but fail SPF or DKIM authentication checks. There are three main policies you can set: p=none, p=quarantine, and p=reject. Understanding these policies is crucial for effective email protection.
The impact of Microsoft's interpretation
When Microsoft treated p=reject as p=quarantine, it created a loophole that phishers and spoofers could exploit. While the email might not land in the primary inbox, it still appeared with your brand in the junk or spam folder. This means that users could still see what looked like a legitimate email from your company, even if it was flagged as suspicious. This significantly undermined the anti-phishing benefits of a strong DMARC policy (blocklist or blacklist).
The primary objective of moving to a p=reject policy is to completely eliminate unauthorized emails from circulation. When a server truly rejects an email, it’s bounced back to the sender (or to a null address, depending on configuration) and never reaches the recipient’s mailbox at all. This prevents users from even seeing fraudulent emails that attempt to impersonate your domain, protecting both your brand reputation and your customers from potential scams.
This discrepancy also highlights the importance of DMARC alignment. Even with a DMARC policy, if SPF and DKIM aren't properly configured and aligned with your organizational domain, emails can still fail authentication. This is why a gradual approach to DMARC policy enforcement, typically starting with p=none to p=quarantine and then to p=reject, is recommended to identify and fix any authentication issues before applying a strict rejection policy.
Expected DMARC reject behavior
Email disposition: Messages that fail DMARC authentication are immediately rejected during the SMTP conversation.
Recipient visibility: No rejected emails appear in the recipient’s inbox, spam, or junk folders.
Brand protection: Maximizes defense against phishing and spoofing, maintaining brand integrity.
Microsoft's historical DMARC quarantine behavior
Email disposition: Messages that fail DMARC are sent to the recipient’s junk or spam folder.
Recipient visibility: Unauthorized emails still visible to recipients in their quarantine (junk) folders.
Brand protection: Reduced, as users might still encounter and interact with spoofed messages.
Strategies to enforce DMARC reject with Microsoft
While Microsoft's stance has evolved towards stricter DMARC enforcement, especially for high-volume senders, you might still encounter scenarios where you want to ensure a hard reject. The most effective way to address this for emails sent to your own Microsoft 365 organization is by creating a mail flow rule (transport rule) in Exchange Online. This rule allows you to explicitly reject emails that fail DMARC authentication and are marked with a DMARC policy of p=reject (or p=quarantine) as if they were intended for outright rejection.
To implement this, you'll typically navigate to the Microsoft 365 Defender portal, then go to Mail flow > Rules. You'll create a new rule that checks the authentication results header for DMARC failures where the action taken by Microsoft was oreject (original reject, indicating your published DMARC p=reject policy). If that condition is met, the rule will then enforce the desired action, which is to reject the message. This essentially overrides Microsoft's default handling for your organization.
Before implementing such a strict rule, ensure that your DMARC setup is flawless. This means ensuring all legitimate sending sources are properly authenticated with SPF and DKIM and that they are in DMARC alignment. Failing to do so can result in legitimate emails being rejected, causing significant deliverability issues. Reviewing your DMARC reports is vital. If you're encountering issues, a thorough troubleshooting process is recommended.
Exchange Online transport rule to enforce DMARC rejectPowershell
New-TransportRule -Name "Reject DMARC Failed Emails with Reject Policy" -HeaderContainsMessageHeader "Authentication-Results" -HeaderContainsWords "dmarc=fail action=oreject" -RejectMessageReasonText "Email rejected due to DMARC policy failure."
The broader context of DMARC enforcement
Beyond Microsoft's specific handling, it's important to remember that DMARC policies, even p=reject, are fundamentally requests to receiving servers. While most major providers generally honor these policies, their internal algorithms and considerations for user experience can sometimes lead to variations in enforcement. This is why continuous DMARC monitoring is essential.
Some in the email community argue that DMARC, particularly the strict enforcement policies, can complicate legitimate email delivery. The challenge often lies in correctly identifying all valid sending sources for a domain and ensuring their SPF and DKIM records are perfectly aligned. Misconfigurations can lead to legitimate emails being quarantined or rejected, impacting your sender reputation and deliverability.
Despite these complexities, DMARC remains a critical tool for combating email spoofing and phishing. The key is a well-thought-out implementation strategy, starting with p=none to gather data, moving to p=quarantine for testing, and finally to p=reject only after thorough analysis of your DMARC reports. This iterative process helps ensure that you can combat email spoofing effectively without unintended consequences.
Ensuring DMARC effectiveness
Email authentication, particularly DMARC, can be complex, and getting it right requires careful planning and continuous monitoring. While Microsoft's historical treatment of p=reject as p=quarantine was a point of contention, their recent changes and the ability to implement specific transport rules provide more control. By combining a robust DMARC implementation with targeted Exchange Online rules, you can effectively enforce your desired p=reject policy and prevent unauthorized emails from reaching any part of your recipients' inboxes.
Remember, the journey to a fully protected domain is continuous. Regularly review your DMARC reports, adjust your policies as needed, and stay informed about changes in mailbox provider behavior. This proactive approach will help ensure your legitimate emails are delivered, while illegitimate ones are effectively blocked.
Views from the trenches
Best practices
Always start DMARC implementation with a 'p=none' policy to monitor and gather data without affecting deliverability.
Ensure all legitimate sending sources are properly authenticated with SPF and DKIM and achieve DMARC alignment before moving to 'p=reject'.
Utilize DMARC aggregate reports to identify any legitimate emails that are failing authentication and correct issues promptly.
For Microsoft 365 organizations, implement an Exchange transport rule to enforce 'p=reject' for inbound emails that fail DMARC and are marked as 'oreject'.
Continuously monitor your DMARC reports even after moving to 'p=reject' to ensure ongoing compliance and identify new sending sources.
Common pitfalls
Implementing 'p=reject' prematurely without proper SPF/DKIM alignment, leading to legitimate emails being rejected or quarantined.
Not configuring DMARC reporting (rua tag) or failing to analyze the reports, leaving blind spots in your email ecosystem.
Assuming all mailbox providers will strictly honor a 'p=reject' policy without understanding their individual interpretations.
Ignoring potential DMARC failures for emails originating from third-party services like marketing platforms or transactional email providers.
Not educating internal teams or clients about DMARC, leading to misunderstandings about its purpose and impact on email delivery.
Expert tips
DMARC policy should be seen as a strong recommendation, but ultimate enforcement lies with the receiving server.
Microsoft's historical DMARC behavior aimed to reduce false positives for legitimate senders, but it impacted brand protection against spoofing.
The most robust DMARC implementation includes creating custom rules within your own email infrastructure, such as Exchange Online, to explicitly enforce rejection.
Prioritize DMARC alignment and reporting to gain visibility into your email ecosystem before applying strict policies.
Consider the trade-offs: DMARC helps with anti-phishing, but overzealous or incorrect implementation can disrupt legitimate mail flows.
Expert view
Expert from Email Geeks says DMARC enforcing policy should be treated as a suggestion only, as it's ultimately up to receivers how they choose to interpret and apply it.
2021-01-21 - Email Geeks
Expert view
Expert from Email Geeks says DMARC policy statements are always a request, not a definitive command to email receivers.
Microsoft has often left domain owners feeling frustrated. While quarantine is better than inbox delivery for fraudulent emails, the fact that recipients can still encounter these spoofed messages, even in a junk folder, means the brand is still exposed to potential reputational damage. My aim here is to explore why this happens and what practical steps you can take to achieve true DMARC rejection, minimizing the visibility of fraudulent emails bearing your brand.
Microsoft (and many other mailbox providers) viewed DMARC policies as a suggestion rather than a strict command. Their reasoning often stemmed from a desire to prevent legitimate emails from being inadvertently blocked. If a DMARC record had issues, or if an organization had complex sending practices, a strict p=reject policy could lead to deliverability problems for valid mail. You can find more details on their approach to email authentication on the official Microsoft Learn site.
