How do I move to DMARC p=reject without blocking my own email?

Stage it: start at p=none with reporting, use the aggregate reports to find and align every legitimate sender (aligned DKIM and/or SPF), move to p=quarantine to confirm, then p=reject. Never skip straight to reject.

What is DMARC alignment?

A message passes DMARC only if the visible From domain matches the domain that SPF or DKIM validated. A sender can pass raw SPF/DKIM but still fail alignment, which is why some mail breaks at p=reject.

Do I keep the DMARC reporting address after reaching reject?

Yes. Keep the rua reporting address permanently so you are alerted if a new, unaligned sender appears later and starts getting rejected.

DMARC p=reject: how to roll it out safely

DMARC p=reject is the goal — it tells receivers to bin anything that fails authentication, which stops spoofing of your domain. But jumping straight to it will block your own newsletters, invoices and app mail if your senders are not aligned first. Here is the staged rollout that gets you there safely.

What p=reject does (and why alignment matters)

A DMARC policy has three levels: `p=none` (monitor only), `p=quarantine` (send failures to spam), and `p=reject` (refuse them outright). At reject, any message that fails DMARC alignment is dropped before it reaches the inbox.

"Alignment" is the catch: a message passes DMARC only if the domain in the visible From address matches the domain validated by SPF or DKIM. A tool that sends "as you" but authenticates with its own domain will pass raw SPF/DKIM yet fail DMARC alignment — and at p=reject, that mail disappears.

Stage 1 — observe with p=none

Publish `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com` and leave it for a couple of weeks. This changes nothing about delivery but starts the flow of aggregate (RUA) reports — XML summaries from receivers showing every source sending as your domain and whether it aligned.

Use the reports to build a complete list of your legitimate senders: mail host, marketing platform, help desk, CRM, billing, app transactional mail.

Stage 2 — align every sender

For each legitimate source, make it align: enable DKIM signing with your domain, and where possible set a custom return-path/envelope domain so SPF aligns too. Most SaaS senders document a "DKIM/DMARC setup" or "authenticate your domain" step for exactly this.

Re-check the reports until every legitimate source passes via aligned SPF or aligned DKIM. Only then is it safe to tighten.

Stage 3 — quarantine, then reject

Move to `p=quarantine` (optionally with `pct=` to ramp gradually), watch for a week that nothing legitimate is being quarantined, then move to `p=reject`. Keep the `rua` reporting address in place permanently so you notice if a new sender appears later.

Check your current DMARC policy any time with the free SPF & DMARC checker, and read the full SPF/DKIM/DMARC fix guide if any record needs repair first.

Keep it enforced

The risk after reaching reject is a new tool that starts sending unaligned and gets silently rejected — you would only find out when someone says "I never got your email". VigilDog's email monitoring watches your DMARC record and setup so a change is a heads-up, not a mystery.

Frequently asked

How do I move to DMARC p=reject without blocking my own email?: Stage it: start at p=none with reporting, use the aggregate reports to find and align every legitimate sender (aligned DKIM and/or SPF), move to p=quarantine to confirm, then p=reject. Never skip straight to reject.
What is DMARC alignment?: A message passes DMARC only if the visible From domain matches the domain that SPF or DKIM validated. A sender can pass raw SPF/DKIM but still fail alignment, which is why some mail breaks at p=reject.
Do I keep the DMARC reporting address after reaching reject?: Yes. Keep the rua reporting address permanently so you are alerted if a new, unaligned sender appears later and starts getting rejected.