100% Inbox Delivery

HomeBlog › DMARC p=reject: The One DNS Line That Stops People Pretending to Be You

DMARC p=reject: The One DNS Line That Stops People Pretending to Be You

Published July 28, 2026 · Updated August 5, 2026 · Email Security

Two of the three DMARC policies do not block a single spoofed email. Here is exactly what p=none, p=quarantine, and p=reject actually do, and how to move through them safely.

The three DMARC policies

  • p=none — monitoring only. Failing messages are delivered exactly as if DMARC didn't exist. You just get reports.
  • p=quarantine — failing messages are typically routed to spam/junk instead of the inbox.
  • p=reject — failing messages are rejected outright at the receiving server. This is the only policy that actually stops spoofed mail from being delivered anywhere.

Why most domains start at p=none

Jumping straight to p=reject is risky if you haven't confirmed every legitimate sending source (your website's contact form, a marketing tool, a CRM) is properly authenticated. Do that first and you'll block your own mail along with the spoofed traffic. p=none exists so you can collect DMARC aggregate reports and see exactly what's sending on your domain's behalf before you start blocking anything.

A safe rollout to p=reject

  1. Start at p=none and collect aggregate reports (rua) for at least 1–2 weeks.
  2. Identify every legitimate sender in those reports and make sure each one passes SPF or DKIM.
  3. Move to p=quarantine at a low percentage (pct=10) and watch for problems.
  4. Increase pct gradually toward 100 as reports stay clean.
  5. Move to p=reject once quarantine has run clean at 100% for a couple of weeks.

A minimal DMARC record

A record ready for the monitoring stage looks like this, published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Tip: Every dedicated SMTP server here ships with SPF, DKIM, and a DMARC record already configured — the rollout above matters most for your own website/company domain, not the sending subdomain we provision for you.

Aggregate reports vs. forensic reports

The rua address receives aggregate reports — periodic XML summaries of pass/fail counts by source, the ones most senders actually use. The ruf address, if configured, receives forensic reports with details of individual failing messages in near real time — far noisier and less commonly used, since aggregate reports alone are usually enough to identify and fix a missed sender.

A quick way to read an aggregate report without raw XML

Most free DMARC report analysers accept the XML attachment your rua address receives and render it as a simple table of sending IPs, pass/fail counts, and identified services — far faster than reading the XML by hand, and the standard way anyone managing DMARC actually reviews reports week to week.

Related reading:
Free SPF/DKIM/DMARC generator · Email authentication tools
Pay your way

Dedicated SMTP, flexible billing

Dedicated IP, unlimited sending, and your choice of payment method. From $39.99/mo, cancel anytime.

See the unlimited SMTP server →Get started now

Frequently asked questions

Will p=reject block my own emails?

Only if a legitimate sending source isn't properly authenticated first. That's why the rollout goes through monitoring and quarantine before reject — to catch exactly this before it can happen.

How long should I stay at p=none?

At least 1–2 weeks, long enough to see a full reporting cycle and catch any legitimate sender you might have missed.

What does p=quarantine actually do to spoofed mail?

It tells the receiving mail server to treat a failing message with suspicion — typically routed to spam/junk rather than being delivered to the inbox or rejected outright.