We turned p=reject on for our own marketing domain at 9pm on a Friday. Woke up Saturday to a Slack alert that no invoices had gone out for 11 hours. Welcome to the club.

Almost everyone who ships DMARC fast has a version of this story. The lucky ones catch it before a customer escalates. We were not lucky.

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 conceptually hard. The deployment path is what's unforgiving, and most guides hand-wave the move from p=none to p=reject across a real domain with Google Workspace, a transactional sender, a marketing tool, and three forgotten SaaS tools nobody documented. This is the ramp we use ourselves now, after the Friday incident.

Why p=reject Matters in 2026

If you're already at p=none and pulling reports, you know why DMARC exists. What changed in the last two years is the cost of not enforcing it. Gmail's February 2024 bulk-sender requirements pushed senders (5,000+ messages/day to Gmail addresses) to authenticate with SPF and DKIM aligned to the From, publish a DMARC policy of at least p=none, and stay under a 0.3% spam complaint rate. Yahoo published near-identical rules the same month. Microsoft has been tightening Outlook.com filters in the same direction, just more quietly.

Practical effect: p=none is the floor now, not the goal.

Stay there forever and you're authenticated but unprotected. Anyone can still spoof your domain — DMARC is just watching it happen and reporting it back over breakfast. Only p=quarantine and p=reject actually stop the spoofing.

For any domain sending real customer mail, p=reject is the destination. (Skip it for transactional-only domains under 1,000 sends/day — the spoofing surface is small and a misconfigured policy costs more than the gain.) For everyone else, the question isn't whether to ramp. It's how fast you can ramp without taking down your own mail.

Pre-flight: Get SPF and DKIM Clean First

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

Before you touch the DMARC TXT record, audit two things.

SPF: one record, every legitimate sender included.

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

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:_spf.intuit.com ~all"

Two SPF records invalidates SPF entirely. So does going over 10 DNS lookups (each include: counts, nested includes count, and _spf.google.com alone burns three). If you're brushing the limit, the cleaner fix is dropping senders you don't actually use. We found a billing tool we'd dropped in 2024 still consuming two lookups on our record. Embarrassing.

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 — or a subdomain that aligns in relaxed mode. Send a test from each tool to a Gmail account, open "Show original," look for dkim=pass with header.d=yourdomain.com. If header.d= shows the vendor's domain (sendgrid.net, mailgun.org, amazonses.com) instead, you haven't enabled custom DKIM. Find the "Domain Authentication" section of their dashboard and add the CNAMEs they give you. A typical SendGrid setup:

s1._domainkey.yourdomain.com.   IN  CNAME  s1.domainkey.u12345.wl.sendgrid.net.
s2._domainkey.yourdomain.com.   IN  CNAME  s2.domainkey.u12345.wl.sendgrid.net.
em1234.yourdomain.com.          IN  CNAME  u12345.wl.sendgrid.net.

The distinction that trips people up: SPF authenticates the Return-Path (envelope sender), DKIM authenticates a signed header. DMARC needs at least one of those to align with the visible From. A vendor with their own Return-Path can still pass DMARC if their DKIM is signed with your domain. SPF alignment is nice. DKIM alignment is what saves you at p=reject.

Step 1: p=none With Reporting Turned On

The DMARC record itself is a single TXT record at _dmarc.yourdomain.com. Starting policy:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1; adkim=r; aspf=r; pct=100"

What each tag does:

p=none — observe only, don't act on failures
rua=mailto: — aggregate reports (daily XML summaries) go here
ruf=mailto: — forensic reports (per-message failure detail) go here
fo=1 — generate forensic reports if SPF or DKIM fails alignment
adkim=r / aspf=r — relaxed alignment (subdomain matches), which is what you want
pct=100 — explicit default, applies to all mail

Pro tip we learned the hard way: don't point rua at a personal inbox. We got 40+ XML attachments a day from Google, Microsoft, Yahoo, Comcast, and a long tail of providers we'd never heard of.

Strong opinion: DMARC 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. We tried for one (1) afternoon. Half the file is base64-encoded headers, the schema is nested four deep, and you'll be cross-referencing IPs in a spreadsheet within 20 minutes. Postmark's DMARC Digests is free for low-volume domains. dmarcian and Valimail are the paid grown-up options.

Run p=none for at least 4 weeks. You're looking for every legitimate source identified, and every one of them passing DKIM or SPF with alignment. When the legitimate column is 100% green and you recognize every source, move on.

Don't move on if you see a sender you can't identify. We've seen forgotten billing tools (Quickbooks Online sending statements), an ex-employee's 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.

Step 2: p=quarantine with pct=10

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

_dmarc.yourdomain.com.  IN  TXT  "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 quarantine to 10% of failing mail and treats the other 90% as p=none. Translation: if something's broken, only 10% of affected mail goes to spam — enough to surface complaints in your support inbox, not enough to take down a customer-facing flow.

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

Step 3: Ramp pct From 10 to 100

Move the percentage up over 2-3 weeks. Our cadence:

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

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

At each step, check aggregate reports for new senders appearing with failures, and Postmaster Tools for spam-rate spikes. 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 — a new team using a tool nobody told ops about, a vendor rotating DKIM keys without warning, a developer wiring up an SMTP relay for app notifications — drop back to the previous pct, fix the sender, resume. We've done this twice. Both times the offending tool was set up by a well-meaning person who didn't know DMARC existed.

Step 4: p=reject

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

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

Two things to notice. We dropped pct — at p=reject the default is 100% and there's no value in ramping further. We added sp=reject to apply the same policy to subdomains, which matters for older domains that already have records on mail. or email. subdomains. rua stays because the aggregate stream remains useful as a monitoring signal forever.

This is the destination. Spoofed mail using your domain in the From now gets rejected outright at the recipient's server — no quarantine folder, no warning, just a bounce back to the spoofer. Your Gmail and Yahoo deliverability gets a small but real lift. You're done. Except for the monitoring, which never ends.

What Breaks and How to Fix It

The four breakage modes that catch every team:

Third-party senders without DKIM signing. Marketing tool, e-signature platform, billing system, recruiting ATS. Any SaaS that sends mail "from" your address needs to be authenticated against your domain — not the vendor's. Fix: enable custom DKIM in their dashboard, add their include: to your SPF, verify in aggregate reports that mail from that source shows dkim=pass with header.d=yourdomain.com. If a vendor doesn't support custom DKIM in 2026, switch tools. A vendor that can't sign with your domain is going to bounce at p=reject.

Mailing lists rewriting the From. Traditional listservs and some Google Groups setups rewrite the From header so replies go back to the list. This breaks alignment by definition. The right fix is ARC (Authenticated Received Chain), which most modern list software supports. The pragmatic fix is sending list mail from a subdomain with its own looser DMARC policy:

_dmarc.lists.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r"

That way marketing@ and support@ stay locked at reject, and the engineering listserv stays functional at quarantine.

Calendar invites and iCal. Sneaky and frustrating in equal measure. When someone forwards a calendar invite, some clients re-send the .ics on behalf of the original organizer — failing alignment because the forwarder's server is sending on your domain's behalf without DKIM. We had a CEO who couldn't get into a board meeting because the .ics had been forwarded twice and rejected on the third hop. Workaround: tell people to forward the meeting link, not the .ics file. Or accept that Google Workspace and Microsoft 365 handle it correctly if DKIM is configured, and the rest of the world is best-effort.

Transactional senders forgotten in the inventory. The application SMTP integration nobody updated during the 2024 migration. The error-monitoring tool emailing alerts. The internal Jenkins notifier. Low-volume, no clear owner. Run pct=10 quarantine for a full week specifically to surface these — 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 without telling anyone. Subdomains sprout. The aggregate report stream is the early-warning system — set an alert in your parser for any new source IP appearing with failures above a threshold, and treat it like any other production alert.

We use the same parser across every VDL domain and route alerts into the same channel as deliverability signals for JustAnalytics and JustBrowser. If nobody owns the DMARC reports, you'll find the regression the slow way: when a customer tells you their invoice never arrived.

If DMARC is the next thing on your list rather than the current one, our custom domain email setup guide for 2026 covers the DNS basics that come before this post. For a pre-launch checklist, our domain warmup playbook covers the first 30 days.

Questions about ramping or stuck on a specific aggregate report? support@justemails.app. We answer email. (Obviously.) More 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.

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares

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