How to Read a Company's DMARC Verdict in Ten Seconds (And Why Half of Them Chicken Out)

Type one line into your terminal and you can find out whether your bank actually stops criminals from sending email in its name. Try it: dig txt _dmarc.yourbank.com +short. What comes back is a short string of settings, and buried in it is a single instruction — p=none, p=quarantine, or p=reject — that tells every receiving mail server what to do when someone forges that domain.

Here's the part that should annoy you. A huge share of well-known brands publish p=none. That policy is the email equivalent of installing a security camera and unplugging it. You get the reports. You watch the impersonation happen. You instruct the world's inboxes to do nothing about it.

Let me translate the three verdicts in plain English.

• p=none: "Please monitor, but deliver forgeries anyway." It's a listening mode, meant to be temporary while a company checks that legitimate mail passes. Too many treat it as a permanent parking spot.
• p=quarantine: "If it fails, drop it in spam." Now forgeries get pushed to the junk folder instead of the front door.
• p=reject: "If it fails authentication, bounce it. Don't deliver it at all." This is the only setting that genuinely blocks a spoofed message from reaching a human.

DMARC works by checking whether a message actually came from the domain it claims, using SPF and DKIM as the underlying proof, and lining those results up against the visible "From" address you see (DMARC.org's spec calls this "identifier alignment"). SPF checks the sending server. DKIM checks a cryptographic signature. DMARC ties them to the name on the envelope and then applies the policy. If a scammer blasts "[email protected]" from a random server, alignment fails — and the p= line decides the message's fate.

At p=none, its fate is: your inbox.

The adoption numbers are the quiet scandal here. Valimail's DMARC research has repeatedly found that of domains with any DMARC record at all, only around a third are configured to actually enforce — meaning the rest sit at p=none, publishing a policy that protects no one. A record exists. The teeth do not.

Why do big, competent companies stall at monitoring? Usually not laziness — fear of collateral damage. Enforcement can accidentally block legitimate mail from a payroll vendor, a marketing platform, a support desk nobody documented. Turning on p=reject means finding every service that sends on your behalf and authenticating it properly, which is tedious. So the record sits at none, quarter after quarter, while phishers keep the brand name warm.

You don't need a terminal to check. Free lookup tools like MXToolbox or dmarcian's inspector will fetch the record and read it for you. Paste in a domain, and you'll see the policy spelled out. Do it for your bank, your payroll provider, the airline you fly. If you see p=reject, someone there did the unglamorous work. If you see p=none, understand what it confesses: they can see the impersonation and they're leaving your inbox to sort it out.

This is also why Google and Yahoo's 2024 bulk-sender rules mattered more than they got credit for — they forced high-volume senders toward DMARC enforcement instead of letting none ride forever. Regulation by inbox, essentially.

Next time an email from a big brand sets off your gut, don't guess. Look up the verdict yourself. The brand already knows the answer — they just published it where almost nobody thinks to read.