Your DMARC Is Set to None. What Is It Actually Doing?

Your DMARC record exists. It is valid. Something still tells you the policy is at none, and the implication is that you have not finished.

That is fair. A p=none policy is a real policy, publishing it was the right first move, and leaving it there indefinitely gives you a fraction of what DMARC is for. The short answer: it collects evidence and enforces nothing, which means anyone spoofing your domain today still reaches the inbox.

What does a p=none record collect?

A DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:reports@example.com; fo=1

The p tag tells receiving servers what to do with mail that claims to be from your domain and fails DMARC. There are three values: none, quarantine, and reject.

At p=none, the receiver evaluates the message exactly as it would at any other policy. It checks whether SPF passed and whether the SPF domain aligns with the From domain your reader sees. It checks the same for DKIM. It reaches a verdict. Then it delivers the message the way it would have if you had never published DMARC at all, and mails you a report saying what it saw.

So p=none changes your reporting, not your delivery. A spoofed message claiming to be from your domain still arrives in your customer’s inbox. You just find out about it the next day, in XML.

That is genuinely useful, and it is why every safe rollout starts here. It stops being useful the moment nobody is reading the reports.

Do this: open your DMARC record and confirm there is a rua= address in it. A p=none record with no rua is the one configuration that gives you nothing at all.

Why domains get stuck at none

Three reasons cover almost every case.

Nobody read the reports. Aggregate reports arrive as gzipped XML attachments, once a day, from every provider you send to. They are unreadable by design at any volume. If the reports are going to a shared mailbox that nobody opens, the domain will sit at none forever, because moving to enforcement without reading them is genuinely dangerous.

There is one unaligned source and nobody owns it. Reports show a sending IP that fails alignment, it is sending small volumes, and nobody in the company recognises it. It is usually a forgotten invoicing tool, a form plugin, or a mailbox that a former employee configured. Enforcement would break it, so the policy stays.

A vendor cannot be aligned. Some platforms send as your From domain but sign with their own and offer no way to add a DKIM key for yours. In that case the source will never pass alignment, and you have to either replace the vendor, move it to a subdomain with its own policy, or accept that its mail gets quarantined.

The tell for each is in the reports: the first shows as a full inbox nobody has opened, the second as a low-volume IP with no matching DKIM domain, the third as a high-volume source failing alignment consistently while its own SPF passes.

Do this: classify every source in your last two weeks of reports into those three buckets before touching the policy.

Alignment is the thing people miss

DMARC does not ask whether SPF passed. It asks whether the domain that passed matches the domain your reader sees in the From line.

A message sent through a vendor can pass SPF perfectly, for the vendor’s own bounce domain, and still fail DMARC because that bounce domain has nothing to do with yours. In the aggregate report it shows up like this:

<row>
  <source_ip>198.51.100.24</source_ip>
  <count>412</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <spf><domain>vendor-bounces.net</domain><result>pass</result></spf>
</auth_results>

SPF passed. DMARC failed. The spf result inside policy_evaluated is the aligned verdict, and it is the only one that decides anything.

This is the single most common reason a setup that looks correct in every checker still fails DMARC. The checkers confirm your records parse. Alignment is about the relationship between two domains at send time, which no static record check can see.

Do this: for each failing source, compare header_from against the SPF and DKIM domains in auth_results. If they do not match, you have an alignment problem, not a record problem.

Moving up the ladder safely

The path is none, then quarantine with a percentage, then reject. The gate between each rung is the same: no legitimate source is failing.

Quarantine with a percentage is the step people skip, and it is the one that makes the whole thing safe:

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

That sends a quarter of failing mail to spam and leaves the rest alone. If you got something wrong, you find out from a quarter of the blast radius. Step pct to 50, then 100, then switch to p=reject and drop the tag.

If you have one vendor you cannot align, put it on a subdomain and give the subdomain its own weaker policy with sp=. That lets the root domain go to reject while the awkward sender keeps working.

Do this: set p=quarantine; pct=25 today if every source you own already passes, and diary the next step for two weeks out.

Verifying the change took

After any DMARC edit, two things need confirming: the record parses the way you meant, and the reports keep arriving.

The free DMARC record generator will show you the exact record string for the policy you want, which is the fastest way to check you have not fat-fingered a tag. The free email health check reads the published record back out of DNS after the TTL expires, alongside your SPF and DKIM, so you can see what receivers are actually seeing rather than what you intended to publish.

Both answer for one domain, at the moment you ask.

That is the honest limit. A DMARC policy is not a thing you set and finish. Records get edited during unrelated DNS migrations. A new vendor gets added by a colleague and starts failing alignment on Monday, and the reports that would tell you arrive on Tuesday, in XML, in a mailbox nobody opens. The gap between publishing a reject policy and knowing it still holds, with every legitimate source still passing, is where domains quietly break.

That gap is the product. LitInboxes re-checks each monitored domain every 6 hours, parses the DMARC aggregate and forensic reports into a source-by-source view instead of XML, keeps the dated history so you can see when a source appeared, and alerts you on the change rather than on a schedule. Alerts go out by email on every plan, and by Slack, Discord or webhook on Pro. There is a live demo if you want to see the report view before signing up for anything.

If the wider question behind this is why mail is landing in spam at all, DMARC is one of four signals worth checking, and the full diagnostic covers the other three.

The checklist

1. Confirm your record has a rua= address and that reports are arriving somewhere a person looks.
2. Collect at least two weeks of reports, ideally a full billing cycle.
3. List every sending source and classify it: yours, an authorized vendor, or unknown.
4. Compare header_from to the SPF and DKIM domains for each failing source to find the alignment gaps.
5. Fix alignment on everything you own, preferring DKIM.
6. Move any vendor you cannot align onto a subdomain with its own sp= policy.
7. Publish p=quarantine; pct=25 and watch the fail counts for two weeks.
8. Step pct to 100, then publish p=reject.