p=none to p=reject: A DMARC Deliverability Decision

The difference is what a receiving server does with mail that fails your DMARC checks: p=quarantine sends it to the spam folder, while p=reject refuses it outright so it never arrives. p=reject is the level that actually stops spoofing entirely, which is why it gets talked about like the finish line.

But choosing between them, and moving from p=none to p=quarantine to p=reject (the progression laid out in the DMARC enforcement roadmap), is primarily a deliverability decision, not a security one. Each step affects which of your legitimate emails land in inboxes versus spam versus nowhere. Do it wrong and you'll silently break your own email delivery while thinking you're making things safer.

Here's how to know whether you're ready, and what "ready" actually means.

What p=reject does and doesn't do

p=reject tells receiving mail servers to refuse delivery of messages that fail DMARC alignment. A message fails alignment when neither DKIM nor SPF aligns with your From domain.

It does not affect messages that pass alignment; those are delivered normally. It does not affect your own outgoing mail server's behavior. It only influences what receiving servers do with messages claiming to be from your domain.

The risk is direct: if any of your legitimate sending services aren't properly authenticated with aligned DKIM, their messages will be rejected entirely. Bounced. No spam folder, no delivery attempt. Gone.

This applies to everything you use:

• Transactional email services (Postmark, Resend, SendGrid, AWS SES)
• Marketing platforms (Mailchimp, Klaviyo, Campaign Monitor)
• Business tools (Intercom, Help Scout, Calendly, Zapier)
• Your app's SMTP (if you send directly instead of via an ESP)
• Forwarded email (less controllable, often fails SPF even with legitimate forwarding)

Every one of these needs either DKIM configured with a key aligned to your domain, or SPF alignment through the envelope sender. Miss one, and those messages don't land in spam; they disappear.

How to read your alignment rate

Your aggregate reports give you the raw material. For each record in each report, you have a <count> and a policy_evaluated result showing whether DKIM and SPF passed alignment.

A useful metric is: what percentage of your total message volume achieves alignment? If 9,800 of 10,000 messages align, your rate is 98%. The 200 that don't might be forwarded messages (which inherently break SPF alignment) or a sending source you forgot to configure.

You should monitor this over at least 30 days before considering a policy change. Weekly variance can be significant if your volume is low.

The practical threshold

Most email authentication guidance suggests 95% alignment before moving to p=quarantine, and sustained 98-99%+ before moving to p=reject.

For indie developers with multiple domains, the alignment rate is often lower than expected because of services that were set up years ago with a different domain, or transactional services that send through a subdomain without proper DKIM alignment.

The typical blockers when moving toward reject:

1. Forwarded email: When someone has their corporate address forward to Gmail, the forwarded message often fails SPF alignment. This is expected and hard to fix. It won't count against you at most receivers if DKIM passes.

2. Old marketing tool: You set up a Mailchimp account in 2019 and never configured DKIM. Those messages now fail alignment.

3. Password reset emails: Your app was sending through SMTP with a different envelope domain than your From address. Easy to fix, but you have to notice it first.

A reasonable timeline

Week 1-4: Enable DMARC at p=none with a rua= address. Start collecting reports. If you send bulk email to Gmail or Yahoo addresses, run the Gmail and Yahoo compliance checker to confirm you meet their baseline requirements before tightening policy.

Week 5-8: Monitor alignment rates across all sending sources. Use a tool to read the reports (don't pretend you'll parse XML by hand). Identify any sources below 95% alignment and fix them: add DKIM record, update SPF include, or configure envelope sender alignment in your ESP. Test each fix.

Month 3: Move to p=quarantine; pct=10. The pct= tag applies the policy to only that percentage of failing messages. This lets you test the impact without immediately affecting 100% of failing mail. Watch your bounce rates and complaints during this period.

Month 4-5: Increase pct= gradually (pct=25, pct=50) if deliverability is stable and alignment is holding at 98%+. Move to pct=100 once you're confident.

Month 6+: Move to p=reject once you've sustained 98%+ alignment for a full month at pct=100, and you're confident there are no remaining blind spots.

This timeline assumes you're actually reading your reports. If your reports are sitting unread in a folder, the timeline extends indefinitely, which is exactly the problem. You can't safely enforce policy without knowing your alignment rate. That's why monitoring tools exist. Use one.