What is the difference between DMARC none, quarantine, and reject?

DMARC policy is expressed with a single tag — p= — that takes one of three values: none, quarantine, or reject. The choice has huge operational consequences. Picking the wrong policy too early can drop legitimate mail; staying on none forever leaves your domain open to spoofing. Understanding what each policy actually instructs receivers to do, and when to move between them, is central to operating email authentication correctly.

What the policies mean

p=none: monitoring mode. The receiver applies its normal spam filtering and takes no DMARC-specific action if the message fails. If you have rua= configured, the receiver sends you aggregate XML reports so you can see what is failing. This is the starting point for every deployment.

p=quarantine: on failure, the receiver should treat the message as suspicious. In practice this means the spam folder. The message still gets delivered, but it is far less likely to be seen. Quarantine is a middle ground — useful for gradual rollouts and for protecting against opportunistic spoofing while you finalize authentication.

p=reject: on failure, the receiver should refuse the message. In SMTP, this results in a 5xx bounce that the sending server sees. End users never see the message. This is the strongest protection against spoofing but also the most disruptive if you have sources you forgot about.

The pct tag and partial enforcement

DMARC supports a pct= tag that specifies what percentage of failing mail the policy applies to. p=quarantine; pct=10 means "quarantine 10% of failing messages; treat the rest as p=none". This is the canonical way to gradually roll out enforcement.

Note: pct applies to quarantine and reject only. p=none; pct=50 is meaningless — none is already "do nothing."

Also note: pct is advisory. Some receivers (Microsoft historically) ignore pct and apply the full policy. Treat pct as a risk-reduction tool, not a guarantee.

The typical progression

Most organizations move through these stages over weeks to months:

1. p=none with reporting. Collect aggregate reports for two to four weeks. Identify every legitimate sender that is failing alignment. Fix them.
2. p=quarantine; pct=10. Small exposure. Watch for complaints ("my email went to spam"). Fix the remaining failing sources.
3. p=quarantine; pct=50, then pct=100.
4. p=reject; pct=25, then 50, 75, 100.
5. p=reject steady state.

Sprint this at your peril. Most visible-brand domains take 3 to 6 months to reach p=reject safely. Smaller domains with few sending sources can do it in two weeks.

What counts as "failing" DMARC

A message passes DMARC if SPF OR DKIM passes AND aligns with the organizational domain in the From header. Alignment is checked in two modes:

• Relaxed (default): subdomains count. mail.example.com aligns with example.com.
• Strict: exact match only. mail.example.com does not align with example.com.

You set the mode with aspf=r|s and adkim=r|s. Most domains use relaxed for both; strict only makes sense in tightly controlled environments.

Real-world impact of each policy

p=none protection: essentially zero against spoofing, but full monitoring. A spammer can still forge your From header successfully against any receiver.

p=quarantine protection: effective against low-effort spoofing because quarantined mail rarely gets seen. However, targeted phishing still works if the attacker can convince the user to fish the mail out of spam, which users do surprisingly often.

p=reject protection: the strongest. The SMTP transaction fails and the receiving MTA returns a bounce. No user ever sees the forged message. Brand impersonation becomes infeasible through email for that domain.

Subdomain policy (sp=)

DMARC separates policy for the organizational domain and its subdomains. sp= overrides p= for subdomains. Common patterns:

• p=reject; sp=reject — fully locked down.
• p=reject; sp=none — main domain protected, subdomains in monitoring mode. Risky because attackers spoof legit-looking.example.com.
• p=none; sp=reject — unusual but valid if subdomains are unused and you want to protect them immediately.

If you do not publish sp=, it inherits from p=.

Common mistakes

Jumping to p=reject without monitoring first. Breaks legitimate mail from your payroll provider, CRM, or ticketing system. Always collect aggregate reports first.

Forgetting rua=. Without a reporting mailbox, you are flying blind. You will not see the sources failing alignment.

Ignoring reports because they are XML. The aggregate reports are machine-readable and need parsing. Set up a parser or use a service that aggregates them.

Publishing p=quarantine but not aligning DKIM. If your main mail flow relies on SPF alignment alone and something breaks SPF (e.g., forwarding), the message gets quarantined. Always have both SPF and DKIM aligned.

Assuming pct is honored. Microsoft and a few other receivers ignore pct. If you publish p=reject; pct=10, a Microsoft recipient rejects 100% of failing mail from your domain.

Leaving an old test domain on p=reject. If you once enabled DMARC on a staging domain and forgot about it, new services on that domain break silently.

How to read a DMARC aggregate report

Every Gmail, Yahoo, Microsoft, and most other major receiver sends a daily XML report to your rua= address. Each report contains per-IP counts of messages that claimed to be from your domain, with SPF and DKIM result, alignment result, and the policy that was applied.

You are looking for:

1. IPs you recognize that are failing. These are misconfigured legitimate senders — fix them.
2. IPs you do not recognize that are failing. These are spoofers. Your DMARC policy is your protection.
3. High volume from one unknown IP. Possibly a forgotten internal service.

Use any DMARC aggregator — hosted or self-hosted — to parse the XML. Many good open-source parsers exist; avoid vendor lock-in when possible.

When to use IntoDNS.ai

IntoDNS.ai shows you exactly which DMARC policy you publish, whether alignment is configured correctly, and whether your rua= reporting address is valid. It does not parse your aggregate reports (those flow to your mailbox), but it tells you whether the record itself will produce useful data and whether your current policy matches your stated security goals.

Case studies: what each policy actually blocks

A SaaS company at p=none: aggregate reports show an unknown IP sending 50,000 spoofed "password reset" messages per day, all failing DMARC. None are blocked. Users receive the phishing. Support tickets spike. Business impact: real.

The same company at p=quarantine: the same spoof attempt produces 50,000 failed authentications, and receivers drop the mail into spam folders. Some users fish it out and click, but the volume of clicks drops 95% compared to inbox delivery. Business impact: contained.

The same company at p=reject: the spoof attempt produces 50,000 SMTP bounces back to the attacker's infrastructure. Zero delivered messages. Attackers switch to look-alike domains or display-name spoofing. Business impact: the DMARC attack vector is closed; residual risk moves to lookalikes and user education.

A regulated industry (banking, healthcare): p=reject is effectively mandatory in 2026 for compliance with frameworks like PCI DSS 4.0 and HIPAA guidance. Being at p=none can produce audit findings.

A university or research institution: often stuck at p=quarantine because faculty use mailing lists heavily and some cannot be migrated to ARC-capable relays. Moving to reject breaks legitimate scholarly communication. The tradeoff is acceptable if spoofing is low-impact.

Overriding DMARC: the pct trick in detail

pct is interpreted as "apply the stated policy to this percentage of failing mail; the rest gets downgraded to the next lower policy." So:

• p=reject; pct=50 — 50% rejected, 50% quarantined.
• p=reject; pct=10 — 10% rejected, 90% quarantined.
• p=quarantine; pct=50 — 50% quarantined, 50% treated as p=none (deliver).
• p=none; pct=50 — has no effect; none is already minimum.

This is why many senders use p=reject; pct=100 rather than p=quarantine; pct=100. The latter is the lower of the two and sits below what you probably want.

When to skip p=quarantine entirely

Small domains with a single sending source and no mailing list traffic can sometimes go straight from p=none to p=reject with pct ramping. If your aggregate reports for two weeks show zero legitimate failures, and you have only one or two sending platforms, skipping quarantine speeds up the timeline without meaningful added risk.

For everyone else, the quarantine phase is a safety net that surfaces edge cases (a forgotten Salesforce trigger, a subsidiary using your main domain) before they are rejected.