How to fix a DMARC p=none finding

By the zmam.ai team ·

On this page

If a scan reports that your DMARC record exists but is set to p=none, your domain is monitored but not protected. A p=none policy asks receiving mail servers to report on mail that fails authentication, but not to act on it — so an attacker can still send convincing mail as your visible “From” domain. The fix is to move, carefully, from monitoring to enforcement.

This guide assumes you already have SPF and DKIM in place. If not, start with SPF, DKIM, and DMARC explained .

Why p=none is only the starting line

p=none is the right place to begin a DMARC rollout, because it breaks nothing while you learn who sends mail as your domain. It becomes a problem when a domain is left there indefinitely: you collect reports nobody reads, and you get none of the spoofing protection DMARC exists to provide.

A note on pct

Older guides told you to ramp enforcement with a pct tag (for example pct=25). Do not rely on it: RFC 9989 , the 2026 DMARC standard, removed pct because receivers applied it inconsistently. If you want to signal a non-enforcing trial, RFC 9989 adds a t=y “testing” tag instead. The reliable way to ramp is operational, described below.

Step by step

1. Read your aggregate reports

Your p=none record should already include a reporting address:

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

Within a day or two, receivers send XML aggregate reports to that address. Use a DMARC report viewer to read them — they list every source sending as your domain and whether each passes SPF and DKIM alignment. Your goal is a complete list of your legitimate senders.

2. Fix the legitimate senders

For each real sender that is failing, fix it: add it to SPF, enable DKIM signing for it, or both. Do not advance until your genuine mail passes consistently. This step is the actual work; the policy change at the end is trivial by comparison.

3. Move to quarantine

Once legitimate mail passes reliably, tighten the policy so failing mail goes to spam:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Watch the reports for a couple of weeks. If a legitimate sender surfaces that you missed, fix it before going further.

4. Move to reject

When the reports are clean, enforce fully:

v=DMARC1; p=reject; rua=mailto:[email protected]

At p=reject, receivers refuse mail that fails authentication — the line that actually stops attackers from spoofing your domain. Note that DMARC describes your handling preference; receivers may still apply their own analysis.

Verify and retest

After each DNS change, allow time for propagation, then re-run an external check to confirm the published policy. The finding should clear once p= reaches quarantine or reject and your legitimate mail still passes.