Skip to content
Neatmend
How it worksThe $149 setupFree domain check

All guides

What DMARC p=none means, and when to move to quarantine/reject

Last reviewed 2026-10-21 · Based on the official references linked below

p=none is DMARC's monitoring mode. It asks receiving mail systems to take no enforcement action because of a DMARC failure. With a working report destination, it helps you learn which services send as your domain and which messages pass.

It does not request blocking of spoofed mail, and it does not turn a failed message into a pass. Receiving systems still make their own delivery decisions.

On this page

  • What the three policies mean
  • Read a monitoring record
  • Understand alignment
  • Decide whether you are ready
  • Move in stages and keep checking

What the three policies mean

The p part of your DMARC record tells receivers your requested treatment of messages that fail DMARC:

p=none · Monitor
Request no enforcement action for the DMARC failure. Use reports to investigate your sending services and authentication results.
p=quarantine · Treat as suspicious
Ask receivers to treat failing messages as suspicious, for example by putting them in a spam or junk folder.
p=reject · Refuse
Ask receivers to reject failing messages. Legitimate mail that is still misconfigured can be affected, too.

These are policy requests to receiving systems, not promises about every message's final destination. Authentication does not promise inbox placement or prevent every form of impersonation.

Read a monitoring record

A starting record for a domain new to DMARC can look like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
  • v=DMARC1 identifies it as a DMARC record.
  • p=none sets the monitoring policy.
  • rua=mailto:… requests aggregate reports at the specified address.

The record is type TXT, usually named _dmarc in the sending domain's DNS zone. The address above is an example: prepare a real mailbox or reporting service, then replace it. If you already have DMARC, review the existing policy and report destinations before editing.

p=none alone does not give you reports. You need a working rua destination. When that address is on a different domain, its operator must also publish external-report authorization in that destination domain's DNS. Confirm that reports actually arrive.

Reports summarize sources, message counts and authentication outcomes. They depend on participating receivers and can arrive late; missing reports are not evidence that all mail is passing.

A pass needs alignment with your From domain

DMARC checks the domain people see in the message's From address. At least one of these paths must work:

  • SPF passes and aligns: the return-path domain used for SPF matches the From domain under your policy's alignment rules.
  • DKIM passes and aligns: a valid signature's signing domain matches the From domain under those rules.

A service can pass SPF or DKIM using its own unrelated domain and still fail DMARC for your business domain. Check alignment, not just the word “pass.” Likewise, a report saying no action was taken does not establish that DMARC passed.

When are you ready for a stricter policy?

Use evidence from your actual senders, rather than a fixed date or a single clean test. Before moving to quarantine, work through these checks:

  1. Account for your legitimate senders. Include staff accounts, invoices, newsletters, forms and customer-management tools. Check occasional senders, forwarding, mailing lists and sending subdomains separately.
  2. Test the mail. Send direct tests to an external receiver and inspect its trusted authentication results. Verify SPF, DKIM and alignment for the legitimate services you identified.
  3. Confirm useful report coverage. Make sure reports arrive and represent your usual sending activity. No data, gaps or a few quiet days are reasons to continue monitoring.
  4. Investigate unknown sources and legitimate failures. Match sources to your sender inventory. An unfamiliar IP is a clue to investigate, not enough by itself to authorize or block a sender.
  5. Prepare a rollback. Save the exact current policy, report addresses and TTL. Agree who will apply a change and restore the previous settings if legitimate mail is affected.

Neatmend's setup includes a review after 30 monitoring days. That review can recommend continued monitoring if data is missing or legitimate senders still fail. Thirty days is a review point, not automatic permission to enforce.

Move in stages and keep checking

Once legitimate senders reliably align and coverage is representative, the domain owner can approve a staged move to quarantine. Keep the report destination and other reviewed settings, monitor fresh reports, and check for legitimate failures.

Move toward reject after reviewing the results of quarantine and resolving remaining legitimate-sender issues. Keep monitoring after each change. If legitimate mail is affected, pause the rollout, restore the saved policy as needed, and retest after cached DNS answers expire.

If your domain already has a working quarantine or reject policy, preserve it while reviewing the setup. This guide's monitoring example is not a reason to downgrade an established policy.

Official references and setup guides

Google's DMARC report guidance explains report contents and external destinations. The linked official Google DMARC reference defines policy values and alignment.

For platform steps, use our Google Workspace guide or Microsoft 365 guide.

Want a hand with the setup?

Start with the free domain checker, or have Neatmend guide your Email Authentication Setup for $149 flat. You or your IT person apply the changes; we prepare the records, verify them, and provide a 30-day report.

Neatmend
GuidesFree checkerTermsPrivacyContact

Neatmend is a brand of Barnett Software, LLC
2302 N. 3rd Street
Phoenix, AZ 85004

Fixed-price email authentication.
hello@neatmend.com