Your DMARC says p=none. Do you know what that allows?

Run dig +short TXT _dmarc.yourdomain.com and look at the p= tag. If it reads p=none, here is what that one word does the next time someone forges a message from your domain: a receiving server delivers it to the inbox as normal, then mails you a report about it later.

That is the part the green checkmark hides. You set up DMARC, you found a generator, you pasted the record into DNS, a checker turned green, and the box got ticked. The box says you have DMARC. It doesn't say what your DMARC tells a receiver to do when a forgery shows up, and with p=none the instruction is to do nothing at all.

What p=none actually does

DMARC sits on top of SPF and DKIM and adds the one thing they're missing: an instruction. SPF says who may send. DKIM signs your real mail. DMARC tells the receiver what to do when a message claiming your domain fails those checks, and it gives you a place to publish that decision. The policy lives in the p= tag of your DMARC TXT record, at _dmarc.yourdomain.com.

There are three values. p=none means "take no action, just monitor." p=quarantine means "send failures to the spam folder." p=reject means "refuse failures outright, they never reach the inbox." Only the last two stop anything.

p=none exists for a real reason. It's the monitoring mode you start in so you can collect reports, find every legitimate service that sends as you, and fix your SPF and DKIM before you turn on enforcement. The trap is that it works perfectly as a permanent state. Mail keeps flowing, nothing breaks, the record looks present and correct in any basic checker, and so it sits at p=none for years. The whole time, it is watching spoofed mail go out and doing exactly nothing to stop it.

What a stranger reads into it

DMARC records are public. Anyone can look up yours in one command, and the people running phishing campaigns absolutely do. They check the p= value before they spend effort, because it tells them whether their forgery will land.

A domain at p=none, or with no DMARC at all, is a soft target. The attacker knows a message forging your billing@ address will not be rejected and will not be quarantined on policy grounds. It goes to the inbox to be judged on content alone, and a clean, well-written invoice email passes that bar easily. A domain at p=reject is a different story: the forgery bounces at the door, the campaign gets no delivery, and they move to the next name on their list. Your policy value is a signal, and p=none signals "open."

This is also why fixing the SPF record by itself isn't enough. SPF can say a message failed. Without DMARC at enforcement, "failed" is just an annotation the receiver is free to ignore.

The aggregate reports are the upside

The one genuinely useful thing p=none gives you is data. The rua= tag in your record is an address where receiving servers send daily aggregate reports: which IPs are sending mail as your domain, how much, and whether it passed SPF and DKIM. That's how you discover the marketing tool nobody told you about and the old server still relaying mail under your name.

Read those reports until your real senders all pass cleanly. That is the entire purpose of the monitoring phase. The mistake is treating the reports as the destination. They're the homework you do before enforcement, and once your legitimate mail passes you have no reason left to keep delivering the forgeries too.

Moving off none

You move up in steps so you don't blackhole your own mail. The path is none, then quarantine, then reject, watching reports at each stage.

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
; collects reports, blocks nothing

Confirm every real sender passes in your aggregate reports. Then go to p=quarantine, optionally with pct=25 to apply it to a quarter of traffic first, and watch for a week. If nothing legitimate gets caught, raise pct to 100, then move to p=reject. The strict alignment tags adkim=s and aspf=s tighten how exactly the signing domain has to match, which closes a subtler spoofing gap once you're confident.

Your p= value is the one fact a phishing crew checks before they bother forging your domain, and it's public, so you might as well check it first. SurfaceCheckr looks up your published DMARC record and tells you plainly whether you're at none, quarantine, or reject. That's the same lookup an attacker runs, done from outside with nothing touched, no mailbox read and no mail flow involved. It won't read your aggregate reports for you. It will tell you in seconds if you've been sitting at p=none thinking the green checkmark meant you were covered.