Why p=none without DMARC reporting can be worse than no DMARC at all

A domain with no DMARC record is at least honestly described. Anyone who looks can see there is nothing there. A domain publishing v=DMARC1; p=none is the harder case, because it looks finished. It shows up as configured on an IT provider's report. It ticks the box on an insurance questionnaire. It satisfies the kind of automated scan that only asks whether a record exists. And if that record carries no reporting address, it is doing almost none of the work its owner believes it is doing.

Worth being precise about the claim, because a lot of writing on this overstates it. Publishing p=none does not make your domain easier to spoof. The domain was already open to impersonation before the record existed, and adding the record changes nothing an attacker can do. The danger is not technical. It is that a record in this state can persuade a business a job is finished when it has barely started, and that belief is what stops anybody looking again.

What p=none actually asks receivers to do

DMARC lets you tell receiving mail systems two things: how to check that a message claiming to be from your domain really came from you, and what to do when that check fails. The policy tag carries the second part. p=none asks receivers to take no DMARC-based action at all. Deliver the message, apply your own spam filtering as you normally would, and make a note of what you saw.

That last part is the whole value of monitoring mode. p=none is not a protective setting and was never designed as one. It is an observation window, deliberately harmless, so a business can find out who is sending email as its domain before it starts refusing any of it. Used that way it is exactly the right first move.

One detail worth knowing if you ever meet it. Under RFC 9989, the current DMARC standard published in May 2026, the t tag asks receivers to treat a published policy as a test and apply the level below it. It has no effect on a policy of none, because there is nothing weaker than none to fall back to.

Leave out rua and the observation window closes

The reporting side of DMARC is the rua tag. It names an address that receiving providers send daily aggregate reports to: which servers sent mail claiming to be you, how much of it there was, and whether it authenticated. Those reports are how a business discovers the payroll system nobody mentioned, the invoicing platform the bookkeeper signed up for, and the host in another country sending quotes in its name.

The standard is unusually blunt about what happens when the tag is missing. If rua is not provided, receivers must not generate aggregate reports for the domain. Not may not. Must not. There is no fallback address and no default, so nothing is sent anywhere.

Which means a record reading v=DMARC1; p=none and nothing else asks the world to take no action and to tell nobody. It is monitoring mode with the monitoring taken out. Every receiving provider does precisely what it was asked, which is nothing, and the domain owner has no way of finding out whether that was the right answer.

Four states, and where each one leaves you

The second row is the one worth sitting with. It is the only state on that list where what the business believes and what is actually happening have come apart. The first row is honest about itself. The third and fourth are work in progress and work finished. The second reads as done from the outside and from the inside, and delivers what the first delivers.

What this looks like in a real business

The pattern below is a composite rather than one client, but every part of it is ordinary.

A small building company has DMARC added during an IT handover. The record says p=none, chosen as the safe default rather than as a stage in a plan, and it carries no reporting address because nobody asked for one and there was nowhere for reports to go. The ticket closes that afternoon and the item goes onto the compliance sheet as done.

Eighteen months later somebody is emailing the company's suppliers with its exact domain in the From line. Some of it lands in junk because the receiving provider's own filtering did not like it. Some lands in inboxes. One supplier updates a bank account. Nobody at the building company sees any of this, because none of the mail goes to them and nothing in their own systems records messages they never sent.

They find out when a supplier rings to query an invoice. The two useful questions at that point are how long it has been going on and who else received one, and both answers are unavailable, because the record that was meant to be watching was never asked to report anything. Had a reporting address been there, the sending host would have shown up in aggregate reports from the major providers within a day or two of the first message.

Why going straight to reject is its own risk

The obvious reaction, having read this far, is to publish p=reject this afternoon. That is the right destination and the wrong first step, for a reason that has nothing to do with attackers.

Enforcement applies to every message that fails DMARC, and a message fails DMARC when it is not authenticated as your domain. Whether you authorised the sender has no bearing on it. Your accounting package sending invoices, your booking system sending confirmations, your mailing list, alerts from your alarm monitoring, mail forwarded through a staff member's personal address: anything that has never been set up to authenticate as your domain will fail, and at p=reject it is refused outright rather than delivered.

Most businesses have more sending services than anyone can list from memory. That is not a criticism, it is what a decade of signing up for things looks like. Reports are how you find them, which is why the order matters. Report first, fix what is genuinely yours, then enforce.

The order that works

• •Publish a DMARC record with an aggregate reporting address, even if the policy stays at none for now. Nothing changes about how your mail is delivered, and reports start arriving within a day.
• •Read the first few weeks and build a list of every service sending as your domain. Expect surprises, and expect at least one nobody remembers approving.
• •Fix authentication for the senders that belong to you. SPF authorises the sending servers, DKIM signs the message itself, and DMARC needs at least one of them to line up with the address your recipients see. DKIM is usually the more durable of the two, because it survives forwarding and SPF does not.
• •Watch the pass rate for your own mail rather than the overall pass rate. Failing volume from a host you never authorised is not a reason to delay enforcement. It is the reason to get there.
• •Move to p=quarantine and keep reading. Failing mail goes to junk rather than nowhere, so a mistake at this stage is still recoverable by the recipient.
• •Move to p=reject once your own senders have passed consistently and nothing new has turned up for a few weeks.
• •Keep reading afterwards. New services get added, keys get rotated, providers change their sending infrastructure, and a record that was correct in March can be quietly wrong by September.

For most small businesses this is a few weeks of attention rather than a project, and the slow part is waiting for reports to accumulate rather than anything technical.

Two things a reporting address will not do for you

The first catches people out constantly. If your rua address sits at a different domain from the one publishing the record, which it does whenever you use a reporting service, that other domain has to publish a short authorisation record before any reports are sent to it. It goes at yourdomain.com._report._dmarc.thereportingdomain.example and contains v=DMARC1; and nothing else. Google and Microsoft both enforce this, and both decline silently. No bounce, no error, and a reporting address that looks perfectly correct in every lookup while nothing ever arrives. If you have published a rua and seen nothing after a fortnight, check this first.

The second is about what DMARC is for. Reaching reject does not guarantee your email lands in inboxes. Authentication is one input among several, alongside your sending reputation, list hygiene, message content and the receiving provider's own judgement. What DMARC does is make your domain hard to impersonate and give the receiving side a solid reason to trust what it is holding. That usually helps deliverability. It is not the same as promising it.

p=none is a stage, not a setting

There is nothing wrong with a domain sitting at p=none. It is where every properly run DMARC rollout starts, and staying there for a few weeks while reports accumulate is the careful thing to do rather than the lazy thing. What turns it into a problem is time and silence. A record that has sat at none for two years with nobody reading its reports is not a project in progress, it is a project that stopped. And where there is no reporting address, there were never any reports to stop reading.

The fix is genuinely small. Adding a reporting address to an existing DMARC record is one DNS change, it takes effect within the hour, and it changes nothing about how your mail is delivered. It just means that from tomorrow, somebody can see.