Why Your DMARC Report Shows p=none When Your DNS Record Has p=quarantine

What p=none in a DMARC report actually means

Nothing is broken.

When your DMARC aggregate report shows p=none, it means the receiving server handled the message according to its default rules. No strict DMARC policy was applied. That is usually the correct outcome for legitimate email that passes authentication checks.

The confusion starts with what p=none refers to. It is not your policy. It is a field in the aggregate report describing what the receiving server did with the message. Your p=quarantine or p=reject lives in your DNS record and tells receivers what to do if a message fails DMARC. Those are separate.

Your DNS record is an instruction:

v=DMARC1; p=quarantine; rua=mailto:reports@example.com

The aggregate reports you receive are the receiver's observation log. A message can only trigger your policy if it fails DMARC. If SPF, DKIM, and alignment all succeed, the message is delivered normally and the report records p=none. Your policy was never invoked because there was nothing to enforce.

Why your DNS policy and your DMARC report do not always match

The p=none you see in a report is not a readout of your DNS policy. It is the receiver describing what it did.

A message that passes authentication gets delivered by default. A message that fails authentication is where your policy applies - and then the report shows what the receiver actually did with it. The key distinction: your p=quarantine tag tells the receiver what to do with failing messages. The p=none in a report tells you what the receiver did with a message that may have passed cleanly.

If you want to know whether your policy is actually being enforced, you need to look at failure reports - messages that actually failed DMARC and triggered your policy. Tools like DMARCFlow can aggregate those signals across all your receivers, so you can see whether your policy is being applied or ignored in practice.

Common reasons you see p=none in DMARC reports

The message passed DMARC authentication fully

This is the most common and most correct reason. Legitimate email from your domain, sent through properly configured servers, will pass SPF, DKIM, and alignment. Receivers deliver it without applying any strict policy, and the report shows p=none. This is exactly what you want.

The sending server is not enforcing your DMARC policy

Some receivers do not fully support DMARC or choose not to enforce strict policies. They may accept reports but handle messages based on their own rules. You see p=none because the receiver never applied your policy in the first place. Without a tool that tracks which receivers are actually enforcing your policy, you may not know this is happening.

SPF, DKIM, or alignment failed before DMARC could apply its policy

If a message fails SPF or DKIM outright, DMARC never reaches the point of applying your policy. The receiver handles the failure according to its own rules. Only messages that pass SPF and DKIM but fail alignment trigger your policy - and then the report shows what the receiver actually did with them.

Your domain is being forwarded through a chain

Forwarded messages often break SPF or DKIM alignment. A message forwarded through a third-party server may arrive without valid authentication credentials, even though it originated legitimately. The receiver sees a failed authentication and applies its default handling, recorded as p=none in your report.

The receiving server does not support DMARC

Smaller or older mail servers may not evaluate DMARC at all. They accept mail without checking your policy. You may not receive reports from these servers, or you receive reports showing default handling. This is a visibility gap, not a configuration problem.

How to investigate which scenario applies to you

The disposition field in your aggregate report, combined with SPF and DKIM results, tells you what actually happened:

• SPF pass, DKIM pass, alignment pass, disposition none: your email is passing DMARC cleanly. The policy was not invoked because there was nothing to reject.
• SPF or DKIM fail: identify the sending source and check whether it is authorized.
• Alignment fail: your sending infrastructure may be misconfigured, or a third party is sending on your behalf without proper DKIM signing.

Group results by source_ip to separate your own infrastructure from third parties. If you see IPs you do not recognize, that is unauthorized sending worth investigating.

Without regular monitoring, these patterns are easy to miss. DMARCFlow parses aggregate reports automatically, groups results by source, and alerts you when your policy is not being enforced by receivers who claim to support it.

How to confirm your DMARC policy is actually being enforced

Aggregate reports describe what receivers observed, not a status display of your DNS configuration. To confirm enforcement:

1. Set up failure reports (ruf=) alongside your aggregate address (rua=). Failure reports show per-message details about messages that actually triggered your policy.
2. If you set p=quarantine or p=reject and receive no failure reports, either your email genuinely passes DMARC everywhere, or you are not receiving reports from servers that enforce your policy.
3. Look for the source_ip field in your aggregate reports. Unexpected IPs mean a third party is sending on your behalf.
4. Use a monitoring tool that tracks enforcement rates across all your receivers - so you can tell the difference between "all email passes" and "I only hear from some receivers."

Frequently asked questions

Does p=none mean my DMARC policy is not working?

No. p=none means the receiver did not apply a strict policy to that specific message. Usually that means the message passed authentication. Your policy is working - it is just not being invoked because there was nothing to reject.

Should I change my policy if I only see p=none in reports?

Only if you are also seeing unauthorized sending. If all legitimate email passes DMARC cleanly, p=none is the correct outcome. If unauthorized senders are operating on your domain, that is when a stricter policy becomes relevant.

Why do I see p=none from some receivers but not others?

Receivers vary in how strictly they enforce DMARC. Some reject or quarantine messages that fail. Others handle messages according to their own rules regardless of your DMARC record. The variation reflects receiver behavior, not problems with your configuration.

Can I see which emails triggered my quarantine or reject policy?

Yes, if you configured a failure reporting address (ruf=). Failure reports give you per-message details about messages that actually matched your policy conditions.

The practical takeaway

Your DMARC aggregate report is an observation log from receivers, not a status display of your DNS policy. When you see p=none, you are usually looking at a message that passed authentication - which is the goal, not a signal that something is wrong.

The reports become most valuable when you use them to spot unauthorized sending. If a source is dispatching email that claims to be from your domain but fails authentication, that shows up in your reports regardless of your policy level. Monitoring those signals is more important than the p field in your own DNS record.

DMARCFlow collects aggregate reports from all your receivers in one place, tracks whether your policy is being enforced across each of them, and alerts you when a receiver is ignoring your policy or when unexpected sending appears on your domain.