DMARC

The Forgotten Quarantine Pile: Why DMARC-Enforcing Clients Miss Their Own Legitimate Senders

October 12, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

Every MSP that has rolled a client from p=none to p=quarantine remembers the moment the project got marked complete. The DNS record was published, the aggregate reports looked clean enough, and the ticket got closed. What rarely gets built into that workflow is a standing habit of opening the quarantine folder itself, the actual pile of messages a mail server decided to set aside because they failed DMARC. That pile is where legitimate senders who still need SPF or DKIM records quietly go to die.

Why Does Quarantine Get Ignored Once a Domain Is Enforcing?

Quarantine gets ignored because enforcement feels like the end of the project rather than the start of an ongoing operational duty. Once p=quarantine is live, failing mail stops hitting the inbox and starts landing in a spam folder or admin review queue that nobody has a ticket to check. The signal that something broke moves from "the client complained" to "a message sits unseen," and silence is far easier to mistake for success than noise ever was.

This is a structural problem, not a laziness problem. RFC 7489 specifies that when a message is subject to a quarantine disposition, the mail receiver should quarantine it, but the standard leaves what happens to that message afterward entirely up to local policy. Google's own rollout guidance tells administrators to review DMARC reports daily during the early weeks of a deployment, but the published guidance focuses on the aggregate XML reports, not the quarantine folder where the individual messages actually sit waiting, according to Google Workspace's recommended DMARC rollout documentation.

What Happens to Mail Once It Lands in the Quarantine Pile?

What happens depends entirely on the receiving platform, and most of those defaults favor the pile staying unopened. On Microsoft 365, Defender's own quarantine FAQ confirms that messages quarantined for high-confidence phishing use the AdminOnlyAccessPolicy, which prevents any user interaction with the message at all, meaning a legitimate vendor invoice caught by an overly strict policy sits exactly as invisible as a real phishing attempt would, per Microsoft's quarantine documentation.

Microsoft's own setup guidance for DMARC is explicit that aggregate reports need regular review specifically to catch unintentional DMARC failures, which is another way of saying that the vendor expects someone to be looking and knows that often nobody is, as noted in Microsoft Learn's DMARC configuration guide. Retention windows make the problem worse. Quarantined spam on many platforms is purged automatically after a set number of days, so a legitimate sender that fails SPF alignment during a busy week can be gone from the quarantine view before anyone circles back to look for it.

Who Actually Ends Up Lost in the Pile?

The senders most likely to get buried in quarantine are the ones nobody thinks to list when building the original SPF record: the marketing platform the sales team signed up for without telling IT, the invoicing tool finance started using last quarter, the HR platform sending offer letters from a subdomain nobody authenticated. These are exactly the senders RFC 7489 assumes a domain owner will discover through the reporting mechanism, because aggregate reports are required to include all relevant message data regardless of what percentage of mail is actually being quarantined.

In practice, discovering them requires someone to connect the aggregate report data to the actual quarantine folder and ask whether a failing source is a real customer tool or an attacker. The DMARC.org project's own FAQ puts it plainly: domain owners are expected to read the aggregate reports, understand their email infrastructure, and get at least one of SPF or DKIM working correctly for mail they care about, according to the DMARC.org wiki FAQ. That expectation assumes an ongoing review cycle, not a one-time rollout project.

Here is roughly how disposition and visibility change as a domain moves through DMARC's three policy states.

Amazon's own SES documentation underscores why the quarantine stage specifically is dangerous to ignore: the guidance warns that using the wrong policy at the wrong time in the rollout "can cause your email to not be delivered," and recommends treating the move to quarantine as a step that still requires active monitoring rather than a finished state, per AWS's DMARC compliance guidance. A reject-level bounce at least generates a complaint. A quarantine-level failure usually generates nothing except a missing email that someone notices days later, if at all.

The Scale of the Gap Makes a Manual Habit Unreliable

The reason this cannot be solved by simply telling a technician to "check the folder more often" is scale. Red Sift's December 2025 analysis of 73.3 million domains found that only 2.5 percent had reached p=reject enforcement, which means the vast majority of domains that have moved past p=none are sitting at the quarantine stage, exactly the stage where failing mail is most likely to be sitting unseen in a folder rather than bouncing loudly, according to Red Sift's global DMARC adoption guide. For an MSP managing dozens of client domains at that stage simultaneously, a manual per-tenant check of quarantine folders does not scale past a handful of clients before something gets missed.

A few patterns show up repeatedly in the domains that get stuck here:

• The quarantine folder is reviewed once during the initial rollout, then never again once the aggregate reports stop showing obvious red flags.
• Retention or auto-purge settings quietly delete the evidence of a missed legitimate sender before anyone looks.
• A new SaaS tool gets adopted by a business unit months after the DMARC project closed, with nobody updating the SPF include or DKIM selector.

Each of these failure modes is preventable, but only if quarantine review is treated as a recurring operational task tied to a specific domain, not a one-time deployment milestone. Building that cadence into a client's onboarding checklist, the same way the account was walked through during initial setup, closes most of the gap before it opens. The getting-started guide covers how to structure that first 30 days so the review habit is set up alongside the record itself, rather than bolted on after a client complains about a missing invoice.

Building a Review Habit That Survives Past the Rollout

The fix is less about tooling sophistication and more about discipline. Aggregate reports need to be cross-referenced against the quarantine folder's actual contents on a fixed schedule, not an ad hoc one, and every unrecognized source IP needs a yes-or-no answer: legitimate and needs SPF/DKIM added, or illegitimate and left to fail. That second category of decision is what the whole DMARC program exists to support, and it is exactly the decision that never gets made when the folder goes unopened.

For an MSP managing authentication across many client domains at once, this is where a scanning platform earns its keep, by surfacing new unauthenticated sources automatically instead of waiting for a technician to remember to look. ActiScan's continuous domain scanning is built around that exact gap, flagging senders that start failing alignment so they can be added to SPF or signed with DKIM before a retention window erases the evidence. Teams evaluating what tier of monitoring fits their client base can review the breakdown on the pricing page, and MSPs ready to put a standing quarantine-review cadence in place across their book of clients can get started from the signup page.

None of this replaces the judgment of whoever owns the client relationship, and no scanning tool can promise that a given domain will never have a legitimate sender slip through quarantine undetected. What a consistent review cadence does is shrink the window between a sender breaking and someone noticing, which is the entire difference between DMARC as a protective control and DMARC as a DNS record nobody is actually watching.