Skip to content
Email Security CheckPlatformTrustPricingProductGuidesContactCustomer Portal
Customer Portal
ENSV
  1. Start
  2. Guides
  3. From p=none to p=reject

Guides

How to move from p=none to p=reject safely

Published 2026-11-10

A DMARC record at p=none reports on spoofing but does not stop it. This guide shows how to find every legitimate sender, fix alignment, and step up to p=reject without losing real mail.

Short answer

With p=none your domain is watching but not blocking, so forged messages are still delivered normally. Use the reports to find every service that sends as you, make each one pass with your own domain, then move through quarantine to reject in stages so your real mail keeps flowing.

Why is p=none not enough?

With p=none, receivers deliver mail that fails DMARC as if the record did not exist. Someone who sends mail with your domain in the From address still reaches the inbox, unless the receiver's own filters stop it.

p=none is the right place to start, because it lets you see who sends mail as your domain without risk. It is not a place to stay. Many organisations publish p=none to meet the Google, Yahoo and Microsoft sender requirements and never move on, which leaves the domain open to spoofing.

How do I find all legitimate senders for my domain?

Start with the aggregate (rua) reports. Collect at least a few weeks of them before you change anything. Group the sending sources by IP address and by the DKIM and SPF domains, and mark each one as yours, a service you use, or unknown.

  • Your own mail platform, such as Microsoft 365 or Google Workspace.
  • Marketing and newsletter platforms.
  • CRM and sales tools that send on behalf of staff.
  • Ticketing and customer support systems.
  • Invoicing, payroll and accounting systems.
  • Web forms, booking systems, printers and scanners, and on-premises servers.

Ask each department which services send mail for them. Reports only show senders that sent mail during the period, so a service that sends once a month or once a quarter can be missed.

How do I fix SPF and DKIM alignment for third-party senders?

Each legitimate sender needs to pass SPF or DKIM with a domain that aligns with your From domain. DKIM is the better choice, because it survives forwarding and does not depend on SPF's limit of ten DNS lookups.

  1. In the service's settings, look for custom domain authentication or DKIM for your own domain. Publish the DKIM keys or CNAME records it gives you.
  2. If the service supports a custom Return-Path or bounce domain on a subdomain of yours, set it up so SPF also aligns.
  3. Add the service to your SPF record only if SPF alignment is needed, and check that the record stays within ten lookups.
  4. Watch the next reports to confirm the service now shows aligned passes.

If a service cannot sign with your domain, consider sending from a dedicated subdomain for it, or replacing the service. Mail from it will fail once you reach p=reject.

What does p=quarantine with pct do?

When the reports show that all legitimate mail passes, move to p=quarantine. The pct= tag lets you apply the policy to a share of the failing mail. With pct=25, receivers apply quarantine to about a quarter of failing messages and treat the rest as p=none.

pct is widely supported today, but the updated DMARC specification (DMARCbis) drops it. It is replaced by a t= test flag, where t=y means the policy is published but should not be fully applied. Receivers will move to the new tag over time, so treat pct as a useful step today rather than something to depend on.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=reject; pct=25; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

When pct is below 100 on p=reject, the messages outside the share are quarantined instead. Leaving pct out is the same as pct=100.

How long should I wait between each step?

There is no fixed rule. It is a judgement based on what the reports show. A common practice is to wait a few weeks at each step, and to move on only when the reports have been clean for that time.

Make sure each period covers at least one full monthly cycle. Payroll, invoicing and month-end reports often send only once a month, and they are the senders most often missed. If you find a new legitimate sender, fix it and give it time to show clean results before the next step.

How do I protect subdomains and parked domains?

Subdomains inherit the main policy unless you set sp=. You can use sp=reject early for subdomains that do not send mail, while the main domain is still at p=none or p=quarantine. If a subdomain does send mail, give it its own DMARC record or include it in your inventory.

Domains that never send mail should be locked down straight away. Publish all three records on each parked domain:

_dmarc.parked-example.com. TXT "v=DMARC1; p=reject;"
parked-example.com. TXT "v=spf1 -all"
parked-example.com. MX 0 .

The SPF record says no server may send for the domain. The null MX record (RFC 7505) says the domain does not receive mail. Adding a rua= address to the parked domain's DMARC record lets you see whether anyone tries to use it.

What should I monitor after reaching p=reject?

  • New sending sources in the aggregate reports, especially services that start failing.
  • Changes in DKIM results after key rotation or a change of mail platform.
  • SPF records that grow past ten DNS lookups when services are added.
  • Reports from staff or customers about missing mail.
  • New services bought by other departments, which should go through the same alignment check before they start sending.

Keep the rua address in the record. Reports are just as useful at p=reject, because they show both spoofing attempts and legitimate mail that has started to fail. DMARC Vision collects these reports and explains them, and the site's free DMARC record checker and Email Security Check can help you check your setup.

How do I roll back if legitimate mail fails?

If a legitimate sender starts failing, step back one level instead of removing the record. Move from p=reject to p=quarantine, or lower pct, while you fix the sender. Do not delete the DMARC record, because you lose both protection and reports.

DNS changes take effect as caches expire, so keep the TTL on the _dmarc record short while you are making changes. Once the sender passes again, return to the previous policy.

Frequently asked questions

Can I go straight from p=none to p=reject?

You can, but only if the reports show that all legitimate mail already passes with alignment. Most organisations find at least one forgotten sender, so a staged move through p=quarantine is safer.

Does p=reject affect forwarded mail?

Forwarding often breaks SPF, so forwarded mail relies on DKIM to pass. If the forwarder changes the message, for example by adding a footer, DKIM can break too. This is one reason to sign all mail with DKIM.

Is pct still supported?

Most receivers support pct today. The updated DMARC specification replaces it with the t= test flag, so expect support for pct to fade over time.

Should parked domains have a DMARC record?

Yes. A domain that does not send mail should publish p=reject, an SPF record of v=spf1 -all and a null MX record, so it cannot be used for spoofing.

Try it on your own domain

  • DMARC Record Checker
  • Email Security Check

More guides

  • What is DMARC?
  • From p=none to p=reject
  • SPF's 10-lookup limit
  • DKIM signatures
  • Domains that send no email
  • MTA-STS and TLS-RPT
  • DNSSEC for email
  • Reading your check report

Email domain protection with EU processing and storage

Legal and policy

  • Privacy policy
  • General terms
  • Data processing agreement
  • Security and sub-processors
  • Accessibility statement
  • Company details

Company

Nansec Software AB559602-3696
  • About DMARC Vision

Free tools and guides

  • Email Security Check
  • DMARC Record Checker
  • SPF Record Checker
  • Guides

Contact

  • Contact
  • Pricing