Do I need…p=reject?

IT DEPENDS

(earn it first)

Reject is where DMARC actually protects your domain—but publish it before every legitimate sender passes and aligns, and you'll block your own mail. Monitor, fix, then enforce.

The long answer ↓

p=reject tells every receiving mail server: do not deliver anything from my domain unless it passes DMARC. It’s the strongest stance email authentication offers—highly effective against phishing that spoofs your domain, and equally effective against your own misconfigured senders.

When the answer is yes

When the answer is not yet

If you haven’t spent time in your DMARC reports (rua), you don’t actually know who sends as your domain. The billing platform, the CRM, the support desk, the survey tool marketing signed up for—any of them not passing and aligning gets bounced the moment you publish reject. With rejection, failures are loud: mail bounces, people complain, broken flows surface fast. That’s a feature when you’re ready and an outage when you’re not.

The rollout that works

  1. p=none with reporting—gather data, no enforcement.
  2. Fix what you find—authenticate every legitimate source, align domains.
  3. p=quarantine—failing mail goes to spam rather than bouncing. Beware the quiet failure mode: broken-but-legitimate senders can sit in spam-folder purgatory unnoticed.
  4. p=reject—once reports stay clean.

Two footnotes from the trenches: the pct= parameter for gradual rollout is not widely respected by mailbox providers, so don’t lean on it—and enforcement on the root domain applies to subdomains unless you say otherwise with sp=. DMARC was designed for gradual rollout; use the reports and the climb is painless.