The DMARC Enforcement Delta: Why M365 & Google Treat p=quarantine Differently

You finally did it. After weeks of analyzing aggregate reports and fixing alignment for a dozen different sending services, you flipped your domain's DMARC policy from `p=none` to `p=quarantine`. It feels like a milestone. You've raised the drawbridge. Now, emails failing DMARC will be held for inspection, kept away from unsuspecting users. Right?

Not exactly. The truth is, `p=quarantine` is one of the most misunderstood settings in the entire email security stack. What it actually does to a failing message is entirely up to the receiving mail server. And the two biggest players in the game, Microsoft 365 and Google Workspace, have fundamentally different philosophies on what 'quarantine' means in practice.

This isn't a minor implementation detail. The delta between their approaches has direct consequences for your security posture, the user experience, and the kind of threats your SOC team will end up chasing.

RFC 7489 vs. Reality: The Suggestion Box of 'Quarantine'

Let's start with the source. RFC 7489, which defines DMARC, is surprisingly non-prescriptive about this. It states the domain owner is requesting that receivers 'treat email that fails the DMARC check with suspicion.' It offers examples like 'place into a spam folder' or 'quarantine and hold for later review'. The key here is that these are just suggestions.

quarantine: The Receiver SHOULD quarantine the message. This means the message is to be treated with suspicion, but not outright rejected. This can mean 'place into spam folder', 'flag as suspicious', 'hold for further review', etc. Each Receiver determines the specifics of its quarantine implementation. — RFC 7489, Section 6.3

The RFC gives receivers immense latitude. There is no standard for quarantine. One system's 'suspicious' holding pen is another's junk folder. This is the root of all confusion. You, as the sender, are making a request, not issuing a command. The receiver's policy, infrastructure, and even the user's own settings can override your intent. This is where the clean, theoretical world of RFCs collides with the messy reality of global mail flow.

Microsoft 365: The Direct Path to the Junk Folder

When an inbound message fails DMARC with a `p=quarantine` policy on a domain, Microsoft's Exchange Online Protection (EOP) almost always interprets this as one simple action: deliver the message to the user's Junk Email folder.

What the User Sees

The user sees the message. It might have a banner or a safety tip warning them it's suspicious, but it's there. They can open it, click its links, and reply to it. With a single click on 'Not junk,' they can even move it back to their inbox, effectively overriding the sender's DMARC policy and the receiver's filtering action. Operationally, this means the threat is contained, but not eliminated. It's visible and interactive.

The Admin Experience

For the IT admin or SOC analyst, there's no central holding pen for these `p=quarantine` DMARC failures. You won't find them in the Microsoft 365 Defender Quarantine portal alongside high-confidence phish or malware. Those are reserved for messages EOP deems actively malicious, independent of the DMARC verdict. The DMARC failure is treated as a strong signal contributing to the overall spam score, which results in the 'Junk' disposition. The action is logged, but the message itself is decentralized across potentially thousands of user mailboxes.

This approach prioritizes deliverability and user autonomy. Microsoft's logic seems to be that if the sender wasn't confident enough to use `p=reject`, then the message shouldn't be completely hidden from the recipient. The burden of the final trust decision is placed on the end-user.

Google Workspace: A Tale of Two Quarantines

Google's implementation is more nuanced and offers administrators a critical choice that Microsoft does not. The outcome of a `p=quarantine` failure in Google Workspace depends entirely on how the receiving domain's admin has configured their 'Spam' settings in the Google Admin console.

Default Behavior: The Spam Folder

By default, Google Workspace behaves similarly to M365. An email failing DMARC with `p=quarantine` is delivered to the user's Spam folder. Just like in Microsoft's world, the user can see it, interact with it, and mark it as 'Not spam'. For many organizations, this is where the story ends, and the security implications are identical to the Junk Email folder scenario.

The Power-Up: Admin Quarantine

However, Google Workspace admins have a powerful alternative. They can create a routing setting that specifically targets messages that are 'Spam' and configure it to 'Move message to administrative quarantine'. When this is enabled, the DMARC `p=quarantine` failure, which contributes to the spam verdict, now triggers a completely different workflow.

The message never touches the user's mailbox—not the inbox, not the spam folder. It's shunted into a central holding area that only administrators can access. The user is completely unaware of the message's existence unless the admin chooses to release it. This transforms `p=quarantine` from a user-facing warning into a true, admin-gated security control. The operational difference is massive. It moves the decision from a potentially untrained user to a security-aware admin or analyst.

Digging in the Headers for Quarantine Clues

Regardless of the final destination, the initial verdict is always stamped in the email's headers. The `Authentication-Results` header is the ground truth for what the receiver's mail server decided about DMARC. As an analyst, this is where you look first when triaging a suspicious email.

Authentication-Results: mx.google.com; dkim=pass header.i=@sender.com; spf=fail (sender IP is 1.2.3.4) smtp.mailfrom=bounces.sender.com; dmarc=fail (p=QUARANTINE) header.from=sender.com action=quarantine

Look closely at that line. It shows a classic alignment failure. The DKIM signature is valid (`dkim=pass`), but it's for the `sender.com` domain. The SPF check, however, is being done against the `smtp.mailfrom` address (`bounces.sender.com`), and it fails. Because the `header.from` domain (`sender.com`) doesn't align with the authenticated DKIM domain or the (failing) SPF domain, the final `dmarc` verdict is `fail`.

The header explicitly states `action=quarantine`. This tells you what the receiver *did* at the DMARC processing stage. What happens *next*—delivery to Junk, redirection to an admin-held quarantine, or something else entirely—is dictated by the downstream policies of EOP or Google Workspace. The header shows the verdict, but you need to know the platform's behavior to know the email's final resting place.

The Strategic Role of 'Quarantine'

Given the inconsistent enforcement, it's tempting to see `p=quarantine` as a weak, ineffective control. That's the wrong way to look at it. Its purpose isn't to be a permanent security state; it's to be a temporary diagnostic tool on the path to `p=reject`.

Think of it as a dress rehearsal for rejection. When you switch to `p=quarantine`, you're not trying to perfectly block all bad mail. You're trying to discover all the legitimate, business-critical mail you're *about* to block when you switch to `p=reject`. These are the forgotten third-party SaaS platforms, the departmental marketing tools, and the weird forwarding rules that break SPF and DKIM alignment.

Your job during the quarantine phase is to obsessively monitor your DMARC aggregate reports. Identify every source of mail that is failing DMARC. For each one, determine if it's legitimate or malicious. If it's legitimate, you must fix its SPF or DKIM configuration to achieve alignment. This might involve getting a vendor to enable DKIM signing for your domain or adding a service's IP ranges to your SPF record via an `include`. You repeat this process until the only things failing DMARC are actual phishing and spoofing attempts.

Only when your DMARC reports show a near-perfect pass rate for all known, legitimate mail streams should you even consider moving to `p=reject`. Skipping this step is a recipe for blocking your CEO's calendar invites from a partner or your finance team's invoices from a key vendor.

The takeaway

The enforcement delta for `p=quarantine` isn't a flaw; it's a reflection of differing security philosophies. Microsoft empowers the user, betting on layered defenses and user education to catch what slips into the Junk folder. Google offers admins a stricter, more centralized control for organizations that want to remove the user from the decision loop entirely. Neither is inherently 'better,' but they are critically different.

Your responsibility as a defender is to know precisely how your own environment operates. Don't assume `quarantine` is protecting you. Test it. Send a non-aligned email from an external source and see where it lands. Trust the `Authentication-Results` header, but verify the final disposition. The path from `p=none` to the ironclad security of `p=reject` is paved with data, and using a tool like MailSleuth.AI to parse your DMARC reports can turn weeks of guesswork into a clear, actionable roadmap.