DMARC says quarantine but mail still reaches the inbox

28 May 2026 · 10 min read

You moved your domain to p=quarantine, expected your own spoof tests to land in the spam folder, and instead a clearly failing message walked straight into the inbox. Or a customer forwarded you a screenshot of a phishing email that should have been quarantined, sitting happily in their primary tab. The natural conclusion is that DMARC is broken, that the policy did not apply, or that you published the record wrong. Usually none of those is true.

p=quarantine is not a command. It is a request. DMARC tells the receiving mail server what the domain owner would prefer happens to a message that fails authentication, and the receiver decides what to actually do with that preference. "Quarantine" does not even mean "spam folder" in the specification; it means "treat as suspicious", and every large mailbox provider interprets that phrase through its own filtering stack, reputation signals, and user-specific rules. On top of that, your own record may be sampling only a fraction of failing mail with the pct tag, and the message you are looking at may not be failing DMARC at all.

This article is specifically about the gap between what a quarantine policy says and what lands where, why that gap is normal, and exactly what to check when a failing message still reaches the inbox. If you have not yet published a policy or you want the basics first, read What is DMARC and the requirements overview, then come back here.

What "quarantine" actually instructs the receiver to do

DMARC defines three policies in the p= tag: none, quarantine, and reject. The relevant wording in the specification is deliberately soft. quarantine asks receivers to treat failing mail as suspicious, and explicitly leaves the mechanics to the receiver: move to spam, add a warning, apply extra scrutiny, hold for review, or something else entirely. The standard never says "deliver to the Junk folder", because the standard cannot make assumptions about how any given mail system is built.

So when Gmail, Outlook, Yahoo, Proton, Fastmail, or a corporate Mimecast or Proofpoint gateway receives a message that fails DMARC against a p=quarantine domain, each one runs its own logic:

• It may move the message to spam.
• It may deliver it to the inbox but strip or rewrite parts of it.
• It may deliver it to the inbox with a visible warning banner.
• It may deliver it to the inbox unchanged because other signals (sender reputation, the recipient's address book, an explicit allow rule) outweigh the DMARC failure.
• It may, at a corporate gateway, quarantine it in an admin-held queue that the end user never sees as a "spam folder" at all.

Only p=reject carries a hard, near-universal behaviour: the receiving server is expected to refuse the message at SMTP time with a 5xx error, so it never gets filed anywhere. That is the real reason enforcement projects aim for reject rather than stopping at quarantine. Quarantine is a soft signal; reject is an instruction the sending server cannot ignore.

If your goal is genuinely to stop spoofing, quarantine is a staging post, not a destination. Our DMARC product and the enforcement reading guide both treat it that way.

Reason one: the pct tag is only sampling a fraction of mail

The single most common reason a quarantine policy "does nothing" to a specific message is the pct tag. pct (percentage) tells receivers what proportion of failing mail to apply the policy to. It exists so you can ramp enforcement gradually instead of flipping everything at once.

Look at a record like this:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

This says: of all mail that fails DMARC, apply quarantine to roughly 25% of it. The other 75% is downgraded one step, to p=none, and delivered normally. That downgrade is part of the spec, not a bug. So three out of four failing messages, on average, will be treated as if you had no enforcement policy at all, and will land wherever they would have landed otherwise (often the inbox).

This catches people out badly during a phased rollout. You set pct=10 to test the water, send yourself a spoof, it arrives in the inbox, and you conclude quarantine is broken. In reality there was a 90% chance that specific message was sampled out. Send ten and you might see one quarantined.

There is a sharp subtlety here that trips up even experienced admins: pct does not apply to p=reject cleanly the way people expect, and pct is being deprecated in the newer DMARC revision (DMARCbis). Under the original RFC 7489 behaviour, pct=50; p=reject means half of failing mail is rejected and the other half is quarantined (downgraded one step, not delivered). Under DMARCbis the percentage tag is removed entirely in favour of doing your ramp through tree-walking and explicit policy changes. The practical takeaway today: if you want predictable behaviour, do not leave a partial pct in place long-term. Ramp pct=25 to pct=50 to pct=100, then remove the tag.

To see exactly what your live record says, including whether a pct is quietly limiting enforcement, run it through the DMARC checker. If you are building or editing the record, the DMARC generator shows you the effect of each tag as you set it.

Reason two: the message is not actually failing DMARC

The second big reason is the one people skip: the message you are staring at may pass DMARC, so quarantine never applied to it in the first place. DMARC passes when either SPF or DKIM passes and that passing mechanism aligns with the visible From: domain. You only need one of the two to align.

This matters because "looks like spam" and "fails DMARC" are completely different tests. A message can be ugly, unsolicited, and obviously junk while still passing DMARC, if it was genuinely sent by an authorised system. Conversely a perfectly legitimate newsletter can fail DMARC because a forwarder broke SPF and the DKIM signature was stripped.

Walk the alignment logic for the specific message:

• SPF alignment. SPF authenticates the Return-Path (envelope sender / MAIL FROM) domain, not the From: header. For DMARC, the SPF-authenticated domain must align with the header From: domain. Many platforms send with their own bounce domain in Return-Path, so SPF passes but is unaligned, contributing nothing to DMARC.
• DKIM alignment. The DKIM signature carries a d= domain. That d= must align with the header From: domain. A message signed only with the email platform's own domain (d=sendgrid.net while From: is you@example.com) passes DKIM but fails DMARC alignment.

So a message can show spf=pass and dkim=pass in the raw headers and still be a DMARC fail if neither passing mechanism is aligned, or a DMARC pass if just one is. The only reliable way to know is to read the Authentication-Results header that the receiving server stamped on. Paste a full raw message into the email header analyser and it will tell you the DMARC verdict the receiver actually reached, rather than what you assumed it reached.

If the verdict is dmarc=pass, your quarantine policy is working perfectly; it simply was never triggered for this message. If it is dmarc=fail and the message still hit the inbox, move on to the receiver-discretion reasons below.

Relaxed versus strict alignment changes the picture

DMARC alignment has two modes, set with aspf (SPF) and adkim (DKIM). The default is relaxed, which counts an organisational-domain match: mail.example.com aligns with example.com. Strict (adkim=s or aspf=s) requires an exact domain match.

A record running strict alignment will fail mail that relaxed alignment would have passed, and vice versa. If you tightened to strict and now expected more quarantining but see inbox delivery, confirm the subdomain actually matches exactly. Check the sending record with the SPF checker and the signature with the DKIM checker to see which domains are in play.

Reason three: receiver discretion and overrides

Assume now the message genuinely fails DMARC, your pct is 100, and it still reached the inbox. This is where receiver discretion lives, and it is entirely within spec. The big mailbox providers reserve the right to override your policy in both directions, and they tell you when they did via the aggregate reports.

Common override scenarios:

• Local allow rules win. If the recipient added the sender to their contacts, marked a previous message "not spam", or there is an organisation-level allow rule for that domain or IP, the provider will frequently deliver to the inbox despite a DMARC fail. The user's explicit signal beats the domain owner's preference.
• Trusted forwarder / mailing-list handling. Receivers know that forwarding and discussion lists break SPF and sometimes DKIM. Many apply a "local_policy" override that downgrades the DMARC result for known-good forwarding paths to avoid losing legitimate mail. This is the single biggest source of "it failed but got delivered" in aggregate reports.
• Reputation outweighs the fail. A sending IP with strong long-term reputation can have a DMARC failure treated leniently. A brand-new IP with the same failure gets quarantined hard. The DMARC verdict is one input to a filter, not the whole decision.
• Sampling and gradual provider rollout. Some receivers apply quarantine probabilistically on their own side too, independent of your pct, especially while they assess a domain.

You can see these overrides explicitly. DMARC aggregate (RUA) reports contain a <policy_evaluated> block with a disposition (what the receiver did) and, crucially, a <reason> element naming the override, such as local_policy, forwarded, trusted_forwarder, mailing_list, or sampled_out. When disposition is none but your policy was quarantine, the reason tells you precisely why the receiver chose to deliver. Feed your XML reports into the DMARC report analyser and look at the disposition-versus-policy mismatch column; that is the override audit trail.

Reason four: caching, propagation, and looking at the wrong record

Before you spend an afternoon on alignment theory, rule out the boring causes. DMARC records are DNS TXT records, and DNS caches.

• TTL caching. If you recently changed p=none to p=quarantine, receivers and resolvers may still hold the old none record until the TTL expires. A message processed during that window is judged against the old policy. Lower the TTL before you plan a change next time.
• You published at the wrong name. The DMARC record lives at _dmarc.example.com, as a TXT record. If it is at the apex, or someone typed dmarc without the leading underscore, receivers find no policy and default to no enforcement. Subdomains are worse: mail from news.example.com is governed by _dmarc.news.example.com if that record exists, otherwise it falls back to the organisational-domain policy with the sp= subdomain tag. A missing subdomain policy plus no sp= can leave a subdomain effectively unprotected.
• Two DMARC records. More than one TXT record starting with v=DMARC1 at _dmarc is invalid, and most receivers will ignore the policy entirely, behaving as if you had none.

Confirm the record resolves, at the right name, with one value, using the DNS record checker for the raw TXT lookup and the DMARC checker for the parsed verdict. If you run subdomains, set an explicit subdomain policy; the DMARC generator exposes the sp= tag.

v=DMARC1; p=quarantine; sp=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:dmarc@example.com

That record enforces quarantine at the organisational domain and every subdomain, with strict alignment and full (not sampled) coverage. Compare it against your live record; the differences usually explain the inbox delivery.

A quick diagnostic order of operations

When a failing message still reaches the inbox, work through this in order. It moves from "your record" to "the message" to "the receiver", which is the order that resolves the most cases fastest.

1. Read the live record. Run the DMARC checker. Is p actually quarantine? Is there a pct below 100? Is there a second record? Is it at _dmarc?
2. Get the receiver's verdict for the message. Paste the raw source into the email header analyser. What does Authentication-Results say for dmarc=? If it passed, you are done; quarantine never applied.
3. If it failed, check alignment. Which mechanism failed and which From: domain was involved? The SPF checker and DKIM checker show what is authorised and signed.
4. Check pct sampling. With pct=25, three in four fails are delivered by design. Send a handful of tests, not one.
5. Read the aggregate reports for overrides. Load RUA XML into the DMARC report analyser and look at the disposition and <reason> fields. A local_policy, forwarded, or sampled_out reason explains inbox delivery legitimately.
6. Rule out caching. If you changed policy recently, wait past the TTL and retest.

So is quarantine pointless? No, but reject is the goal

None of this means a quarantine policy is doing nothing. Even with receiver discretion, a p=quarantine; pct=100 policy measurably increases the rate at which spoofed and unauthenticated mail lands in spam rather than the inbox, and it gives you the aggregate-report data you need to find every legitimate sender before you tighten further. Quarantine is the right intermediate state: stricter than none, safer than reject while you are still discovering senders.

But if the headline you are reacting to is "spoofed mail reached my customer's inbox", quarantine alone will never fully fix that, because quarantine is advisory and reject is mandatory. Spoofing protection that actually blocks delivery requires p=reject, full pct=100 (or no pct under DMARCbis), strict-enough alignment, and an explicit subdomain policy. Getting there without quarantining or rejecting your own legitimate mail is the entire challenge, and it is exactly what monitoring is for. Set up emailed monitoring with change alerts so you are told the moment a new sender appears or a policy drifts, and lean on the aggregate report analyser to confirm every source is aligned before you move the lever.

If you would rather not babysit the ramp yourself, the done-for-you DMARC service takes a domain from p=none through quarantine to p=reject without an email outage, watching the aggregate reports at each step so the policy only tightens once the data says it is safe. The short version to remember: quarantine is a request, reject is an instruction, pct quietly samples, alignment decides whether a message even counts as failing, and the aggregate reports are the only place the receiver tells you the truth about what it actually did.