DMARC: From p=none to p=reject Without Breaking Your Email

You set DMARC to p=reject on a Tuesday. By Friday, your invoices stopped reaching customers, your Slack notifications dropped, and someone in marketing was screaming about a calendar invite no one received. Welcome to the club. Almost everyone who ships DMARC fast has a version of this story, and the lucky ones catch it before a customer escalates.

We're the JustEmails team — JustEmails is built by Velocity Digital Labs, and DMARC is the single configuration we get the most support tickets about. Not because it's hard to understand. Because the deployment path is unforgiving if you skip steps, and most guides hand-wave the part where you actually move from p=none to p=reject. This post is the ramp we use ourselves.

Why p=reject Matters in 2026

If you're already running p=none and getting reports, you know why DMARC exists. The thing that changed is the cost of not enforcing it. Gmail's February 2024 sender requirements pushed bulk senders (5,000+ messages a day to Gmail addresses) to authenticate with both SPF and DKIM aligned to the From domain, publish a DMARC policy of at least p=none, and stay under a 0.3% spam complaint rate. Yahoo published a near-identical set of requirements the same month. Microsoft has been tightening Outlook.com's filters the same direction.

The practical effect: p=none is now the floor, not the goal. If you stay there forever, you're authenticated but unprotected. Anyone can still spoof your domain — DMARC is just watching it happen and reporting it. p=quarantine and p=reject are what actually stop the spoofing.

For a domain that sends real customer mail, p=reject is the destination. Skip p=reject for transactional-only domains under 1000 sends/day. The risk isn't worth it — at that volume, the spoofing surface is small and the cost of a misconfigured policy outweighs the gain. For everyone else, the question isn't whether to ramp, it's how fast.

Pre-flight: Get SPF and DKIM Clean First

DMARC enforces alignment between SPF/DKIM and the From domain. If your SPF and DKIM aren't already correct and aligned, no DMARC policy will save you — it'll just block your own mail.

Before you touch the DMARC record, audit two things.

SPF: one record, every legitimate sender included.

Pull your current SPF with dig +short TXT yourdomain.com and look for the v=spf1 record. There should be exactly one. A clean SPF for a domain using Google Workspace plus a transactional sender plus a marketing tool looks like:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

Two SPF records — even if both look "right" — invalidates SPF entirely. So does going over 10 DNS lookups (each include: counts; nested includes count too). If you're brushing against the lookup limit, an SPF flattening service helps, but the cleaner fix is dropping senders you don't actually use.

DKIM: signed and aligned for every sender.

For each service that sends from your domain, DKIM has to be enabled and the signing domain (d=) has to match your From domain (or a subdomain that aligns in relaxed mode). Send a test message from each tool to a Gmail account, open "Show original," and look for dkim=pass with header.d=yourdomain.com. If header.d= shows the vendor's domain (sendgrid.net, mailgun.org, etc.) instead of yours, you haven't enabled custom DKIM — find the "DKIM" or "Domain Authentication" section of their dashboard and add the CNAME records they give you.

The distinction that trips people up: SPF authenticates the Return-Path (envelope sender), DKIM authenticates a header you sign. DMARC requires that at least one of these aligns with the visible From domain. A vendor sending with their own Return-Path can still pass DMARC if their DKIM is signed with your domain. That's why DKIM alignment is the more important of the two for ramping to reject.

Step 1: p=none With Reporting Turned On

The DMARC record itself is a single TXT record at _dmarc.yourdomain.com. Here's the starting policy:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1; adkim=r; aspf=r

What each tag does:

p=none — observe only, don't act on failures
rua — aggregate reports (daily XML summaries) go here
ruf — forensic reports (per-message failure detail) go here
fo=1 — generate forensic reports if either SPF or DKIM fails alignment
adkim=r / aspf=r — relaxed alignment mode (subdomain matches), which is what you want for most setups

Use a dedicated mailbox or a service address for rua. Aggregate reports are XML and unreadable raw — pay $30/mo for dmarcian or roll your own parser, but don't try to read them by hand. Postmark's DMARC Digests is free for low-volume domains and good enough to start. If you self-host, the IETF schema is RFC 7489.

Run p=none for at least 4 weeks. You're looking for two things in the reports: every legitimate sending source identified, and every one of them passing DKIM and/or SPF with alignment. The aggregate report groups by source IP and shows pass/fail counts per authentication mechanism. When the legitimate column is 100% green and you recognize every source, you can move on.

Do not move on if you see a sender you can't identify. We've seen forgotten billing tools, an ex-employee's personal Mailchimp account still pointed at the company domain, and one memorable case where a recruiting agency had been sending email "as" a client for three years. Track them all down before tightening the policy.

Step 2: p=quarantine with pct=10

Don't go straight to p=quarantine for 100% of mail. The pct tag lets you ramp:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1; adkim=r; aspf=r

This applies the quarantine policy to 10% of failing mail and treats the other 90% as p=none. Translation: if something is broken, only 10% of the affected mail goes to spam — enough that you'll see complaints in your support inbox or notice yourself, but not enough to take down a customer-facing flow.

Stay here for a week. Watch your aggregate reports for new failures, watch your support inbox for "your email went to spam," watch Google Postmaster Tools for changes in your domain reputation. If nothing breaks, ramp up.

Step 3: Ramp pct From 10 to 100

Move the percentage up over 2-3 weeks. We use this cadence:

Week 1: pct=10
Week 2: pct=25
Week 3: pct=50
Week 4: pct=100

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r

At each step, check the aggregate reports for any new sender appearing with failures and check Postmaster Tools for spam-rate spikes. The cadence is deliberately slow — you're trading a month of calendar time for the ability to spot a regression while only half your mail is affected.

If a regression appears (new internal team starts using a tool you didn't know about, a vendor rotates their DKIM keys, a developer adds an SMTP relay for application notifications), drop back to the previous pct, fix the sender, then resume.

Step 4: p=reject

Once you've held p=quarantine; pct=100 for a week with clean reports, switch to reject:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r

Notice we dropped pct — at p=reject, the default is 100% and there's no value in ramping further. The ruf tag is also optional at this stage since fewer providers send forensic reports than aggregate ones; we keep rua because the aggregate reports remain useful as a monitoring stream forever.

This is the destination. Spoofed mail using your domain in the From now bounces at the recipient's mail server. Your Gmail and Yahoo deliverability gets a small but real lift. You're done — except for monitoring, which doesn't end.

What Breaks and How to Fix It

The four breakage modes that catch every team:

Third-party senders without SPF inclusion. Marketing tool, e-signature tool, billing system, recruiting platform. Any SaaS that sends mail "from" your address needs to be authenticated. The fix is always the same: enable custom DKIM in their dashboard, add their include to your SPF, verify in aggregate reports that mail from that source shows alignment. If they don't support custom DKIM, switch tools — there are alternatives for every category and a vendor that can't sign with your domain is a vendor that's going to bounce at p=reject.

Mailing lists rewriting the From. Traditional listservs (and some Google Groups configurations) rewrite the From header to make replies go back to the list. This breaks DMARC alignment by definition — the message now claims to be from the list, not from the original sender. The right fix is ARC (Authenticated Received Chain), which most modern mailing list software supports. The pragmatic fix is to send list mail from a subdomain (lists.yourdomain.com) with its own looser DMARC policy, so your primary domain stays at p=reject.

Calendar invites and iCal. This one is sneaky. When someone forwards a calendar invite, some clients re-send the .ics on behalf of the original organizer, which can fail alignment. If your team relies on cross-organization calendar invites, test this specifically before going to reject. Workarounds include using a calendar service that signs on your behalf (Google Workspace and Microsoft 365 both handle this if DKIM is set up correctly) or accepting that some forwarded invites will bounce.

Transactional senders forgotten in the inventory. The application-level SMTP integration nobody updated when you migrated providers. The error-monitoring tool emailing alerts. The internal Jenkins notifier. These get forgotten because they're low-volume and nobody's owning them. Run a pct=10 quarantine for a full week before moving up specifically to surface them — low-volume failures are exactly what 10% sampling catches.

Keep Monitoring After You Reach reject

p=reject isn't the end of DMARC work. New tools get adopted. Vendors rotate keys. Subdomains sprout. The aggregate report stream is the early-warning system — set up an alert in your DMARC parser for any new source IP appearing with failure counts above a threshold, and treat it like any other production alert.

We use the same parser across all VDL domains and route alerts to the same channel as our deliverability reports for JustAnalytics and JustBrowser. If nobody owns the DMARC reports, you'll discover the regression when a customer tells you their invoice never arrived.

If you're earlier in the email-setup journey and DMARC is the next thing on the list rather than the current one, our custom domain email setup guide for 2026 covers the DNS basics that come before this post.

Got questions about DMARC ramping or stuck on a specific aggregate report? We're at support@justemails.app. We answer email. (Obviously.) More posts on the JustEmails blog.

Frequently Asked Questions

How long should I stay at p=none?

At least 4 weeks, sometimes 8. You're waiting until aggregate reports show every legitimate sending source passing both SPF and DKIM with alignment. If you see a new sender pop up in week 3 (a forgotten billing tool, a recruiter platform, an old marketing automation account), the clock resets — finish authenticating that sender before moving to quarantine. Skip past p=none too quickly and you will reject your own legitimate mail.

What if SendGrid/Mailgun/Postmark sends from my domain?

Each of them needs to be on your SPF record (via include:) and needs DKIM signing enabled with a CNAME pointing to their key. Without DKIM alignment, mail from these services may pass SPF but fail DMARC alignment because the Return-Path is on their domain, not yours. Enable custom DKIM in their dashboard, add the CNAME they give you, and verify in your aggregate reports that the source is showing dkim=pass with your domain.

How do I read DMARC aggregate reports?

Don't read raw XML. Use a parser — dmarcian (around $30/month for small domains), Postmark DMARC Digests (free tier exists), or Valimail. They group reports by sending source, show pass/fail rates per IP, and surface alignment problems in a readable UI. If you insist on rolling your own, the XML schema is documented in RFC 7489 and parsers exist for every language, but the UX of self-hosted tools is consistently worse than the paid options.

Will p=reject hurt my deliverability?

If your authentication is clean, p=reject improves deliverability — Gmail and Yahoo treat strict DMARC policies as a positive sender-reputation signal, especially after the 2024 bulk-sender requirements. If your authentication isn't clean, p=reject will look like a deliverability collapse because you're now blocking your own mail. The policy itself isn't the risk; jumping to it before SPF and DKIM are aligned across every sender is.