DMARC Policy none, quarantine, reject, and when to advance

The three policy values

• p=none: monitoring mode. Receivers still process the message normally, but they send you aggregate reports (the rua field) so you can see who's sending on your domain. No enforcement. The safe starting point for any new DMARC rollout.
• p=quarantine: failed mail goes to the spam folder. The recipient might still see it if they check spam. Real damage to a forgotten third-party sender shows up here, but a real human can recover the message manually.
• p=reject: failed mail is refused at SMTP. The sender gets a bounce, the recipient never sees anything. Strongest brand protection, harshest failure mode for any sender you missed during your audit.

Why you shouldn't stay on p=none forever

Plenty of teams publish a p=none record, watch the reports come in for a week, then leave it that way for two years. The intent is monitoring. The effect is theatrics. p=none doesn't block anyone from spoofing your domain. The aggregate reports are useful only if someone is actually reading them and feeding the findings back into your authentication setup.

Mailbox providers know this. Gmail and Yahoo announced bulk-sender enforcement in early 2024 that effectively requires p=quarantine or stronger for senders pushing 5,000+ messages a day. Several engagement-signal heuristics also start to factor in DMARC enforcement level. Staying on p=none indefinitely now costs you deliverability, not just protection.

The percent flag: gradual enforcement

The pct= tag tells receivers to apply your policy to only that percentage of failing messages. p=quarantine; pct=10 means a tenth of failing mail goes to spam; the other 90% is treated as if you had p=none. This is the rollout knob.

A safe ramp looks like: p=quarantine; pct=10 for a week, watch reports. Bump to pct=25, then 50, then 100. Hold at 100% quarantine for at least two weeks before moving to p=reject; pct=10. Total time from monitoring to full reject: 8 to 12 weeks if nothing breaks. If something breaks, longer.

Subdomain policy: the sp= field

By default, subdomains inherit your organisational domain's DMARC policy. The sp= field lets you override that. A common pattern: p=reject; sp=quarantine. Your organisational domain (the one humans recognise as your brand) gets the strictest enforcement. Subdomains you haven't audited yet stay one rung softer so a forgotten sender on support.example.com doesn't disappear silently.

The opposite pattern, p=none; sp=reject, is useful when you have a busy organisational domain but want to lock down unused subdomains against spoofing.

When it's safe to advance

Three signals to watch in your aggregate reports before bumping enforcement:

• Pass rate on aligned mail. Sum the messages where SPF or DKIM alignment passed. If that's below 99% of your legitimate volume, something is mis-aligned. Don't advance until you've fixed it.
• Identified vs unidentified failing sources. The reports show IP addresses of failing senders. Reverse-resolve them, group by sender. If any group is something you recognise (a forgotten marketing tool, an old CRM), you need to add it to your SPF record or have it sign with DKIM first.
• Volume of clear spoofing attempts. Failing mail from IPs you don't recognise, geographically scattered, hitting many recipients per source: that's the spoofing you want enforcement to block. The higher this share of the failures, the safer it is to advance.

Strict vs relaxed alignment

The adkim= and aspf= fields control how strictly the "alignment" check runs. Relaxed (the default, r) lets organisational-domain match work, so a DKIM signature on mail.example.com aligns with a From of example.com. Strict (s) requires exact match: subdomain must equal subdomain.

Most senders should stay on relaxed. Strict alignment usually fails on otherwise-legitimate mail (third-party platforms sending on behalf of you using subdomain DKIM) without adding meaningful security. Switch to strict only if you have a specific spoofing pattern that relaxed allows through.

How sendmsg.io handles DMARC policy

When you add a sending domain on sendmsg.io, we publish a DMARC record at p=quarantine; pct=10 by default and surface an aggregate-report dashboard built from your rua destination. The dashboard tracks the three advance signals above and tells you when each is green. Two-week stable green on all three, and the platform suggests bumping enforcement.

We never auto-advance enforcement without your sign-off. DMARC failures aren't recoverable: once p=reject blocks a legitimate sender, that message is gone. The platform's job is to surface the signal cleanly. The decision belongs to whoever owns the domain.