The funnel

The path to p=reject, without breaking real mail

p=reject is the only DMARC setting that actually stops impersonation. Getting there safely is a staged move, not a switch you flip. Here is the order, and why each step matters.

  1. Step 1 p=none

    Monitor

    Reporting is on. You can see every source sending as your domain, but nothing changes about delivery. Spend two to four weeks here.

  2. Step 2 p=quarantine

    Contain

    Mail that fails is sent to spam rather than the inbox. You move here only once your genuine mail passes cleanly. Keep watching the reports.

  3. Step 3 p=reject

    Enforce

    Mail that fails is refused outright. This is the setting that actually stops someone impersonating your domain.

Why p=reject is the only setting that stops impersonation

At p=none, a receiver that catches a forged message claiming to be you does nothing about it. It still delivers. You get a report afterwards, which is useful, but the scammer's email already landed. p=quarantine is better, since failing mail goes to spam, but a determined attacker knows some people check their spam, and some filters promote quarantined mail anyway. Only p=reject tells the receiver to refuse the message. That is the difference between watching impersonation and stopping it.

Why you cannot just start at reject

Here is the catch. DMARC does not know which mail is genuinely yours and which is forged. It only knows what passes SPF and DKIM with alignment. Most organizations send legitimate mail through systems they have forgotten about: a payroll provider, a booking tool, a newsletter platform, a support desk. If you jump straight to p=reject before those are authenticated and aligned, your own mail fails the checks and gets refused along with the forgeries. That is how a DMARC project ends up blocking real invoices.

How monitoring makes the move safe

The aggregate reports you turn on at p=none are what make enforcement safe. They list every source sending as your domain, whether each one passes SPF and DKIM, and whether it is aligned. You work through that list, fix or authorize each legitimate sender, and only tighten the policy once the reports show your real mail passing cleanly. Then a move to quarantine, and later to reject, changes nothing for your genuine mail and everything for the forgeries.

The honest problem is that those reports arrive as raw XML from dozens of sources, and reading them by hand does not scale. That is the single biggest reason DMARC projects stall. We wrote about it in why most DMARC projects stall at p=none, and it is the core of why a DMARC service is worth it.

A safe order of operations

  1. Publish p=none with aggregate reporting turned on.
  2. Collect two to four weeks of data. See start with p=none.
  3. Identify every legitimate sender and get SPF and DKIM aligned.
  4. Move to p=quarantine and confirm the reports stay clean.
  5. Move to p=reject. See quarantine to reject.

Check where your domain sits right now with the free DMARC checker.