DMARC has a marketing problem. Every security vendor announces record adoption every year. The logos pile up. The dashboards fill with green checkmarks. And a spoofed email from your CFO still arrives in a finance team’s inbox on Tuesday morning because publishing a DMARC record is not the same as enforcing one. Two-thirds of the deployed DMARC records on the internet sit at p=none — a policy that tells receiving mailbox providers, in effect, “let it through anyway.”
Valimail’s 2026 State of DMARC report ( valimail.com, retrieved 2026-09-03) pins DMARC publication across the top million domains at 78%. In the same corpus, only 42% of those domains are at a real enforcement policy — p=quarantine or p=reject. The remaining 36 percentage points are the enforcement gap: records that exist, cost nothing to publish, and stop nothing.
This piece walks through what that gap actually costs, why Google and Yahoo’s February 2024 bulk-sender rules didn’t close it, and the exact 30-day migration a small team can run to move a domain from monitor-only to enforcement without breaking legitimate mail.
The 78%/42% gap in one paragraph
DMARC has three enforcement states, and the difference between them is the entire ballgame:
p=none— monitor only. Receiving mailbox providers deliver the message normally and email a daily aggregate report (rua) to you telling you which IPs are sending mail claiming your domain. Nothing is blocked. Nothing is quarantined. From an attacker’s perspective this policy does not exist.p=quarantine— send to spam. Messages that fail DMARC alignment are routed to the recipient’s spam folder. Not perfect (users do open spam), but a real filter.p=reject— refuse outright. Mailbox providers return an SMTP rejection and the message never lands in a folder. This is the only policy that actually stops spoofed mail from reaching a human.
The 78%/42% split from Valimail 2026 means the majority of DMARC records on the internet are at rest at p=none — the state that provides visibility and nothing else. EasyDMARC’s 2026 adoption survey ( easydmarc.com, retrieved 2026-09-03) shows the same shape: publication is climbing at ~4 points a year, enforcement is climbing at less than 2. The gap widens.
p=none is identical to a domain with no DMARC record at all. The forensic reports you receive tell you the attack happened; they do not stop the attack.Why p=none protects nobody
p=none exists for a good reason. It is the ramp. When you first publish DMARC, you almost certainly do not have a full inventory of every legitimate service sending mail on your behalf — payroll platforms, HR notification tools, marketing automation vendors, bulk transactional providers, plus every SaaS trial someone in the org signed up for. Turning p=reject on day one blocks legitimate mail alongside spoofed mail. The ramp exists to let you fix that first.
The problem is that most organisations never come off the ramp. The rua reports pile up in an unmonitored mailbox. The XML never gets parsed. The senders never get inventoried. Six months in, someone in IT confirms “DMARC is deployed” on a compliance checklist and the ticket closes. The domain stays at p=none forever.
For a walk-through of what those aggregate reports actually contain and how to read them, the DMARC report reading guide is the fastest way in. For the underlying protocol mechanics, see what is DMARC and the DMARC glossary entry.
What Feb 2024 Google/Yahoo rules actually changed
On February 1, 2024, Google and Yahoo enforced a shared set of bulk-sender requirements that the industry had been calling the “5,000 message rule” ( Google Sender Guidelines, retrieved 2026-09-03; Yahoo Sender Best Practices, retrieved 2026-09-03). If your domain sends 5,000 or more messages a day to Gmail or Yahoo Mail addresses, you must:
- Authenticate with SPF and DKIM (previously either was enough).
- Publish a DMARC record. Any policy — including
p=none— satisfies the letter of the rule. - Keep spam complaint rates below 0.3%.
- Include a functional one-click list-unsubscribe header on marketing mail.
What changed in real terms: publication rates jumped. What did not change: enforcement rates. Because the rule accepts p=none, a spoofing-vulnerable domain that adds a monitor-only record on February 1 is compliant with the letter of the rule and still spoofable by every phishing crew on February 2.
Google’s next round of tightening — currently telegraphed as a phased move to require enforcement (p=quarantine minimum) for high-volume senders — has been on the roadmap since late 2025 but does not have a firm compliance date at the time of writing. Domains that want to be ahead of it are moving to p=reject now.
Fortune 500: 93.8% publish, 62.7% enforce
The large-enterprise segment is roughly where the top million was three years ago. Valimail’s cut of the Fortune 500 in the 2026 report ( valimail.com) shows 93.8% at any DMARC record and 62.7% at real enforcement. That is the best-instrumented, best-funded segment of the corporate internet. Nearly a third of them still cannot answer “is a spoofed email from your CEO delivered to your board?” with a confident “no.”
The Federal Civilian Executive Branch is the counter-example. BOD 18-01 forced US federal .gov domains to p=reject starting in 2018, and CISA reports adoption above 92% at enforcement in that population ( CISA BOD 18-01, retrieved 2026-09-03). The lesson is that publication rises with vendor tailwind, but enforcement only rises with a hard deadline.
Why the gap exists — three real reasons
None of these are technical. All of them are organisational.
- Fear of blocking legitimate mail. A domain at
p=nonehas zero risk of breaking payroll notifications, invoice emails, marketing sends, or partner integrations. Moving top=rejectwithout a full sender inventory can, and does, break exactly those flows on day one. Every team that got burned once stays atp=nonepermanently. - Report fatigue. A mid-sized domain generates hundreds of megabytes of aggregate XML per month. Without a parser, the reports are unreadable. Without ownership, the parser never gets bought. Without insight, the case for advancing policy never gets made to leadership.
- Shared-domain politics. Marketing sends through vendor A. HR sends through vendor B. Sales sends through vendor C. Every one of those vendors has to be authenticated correctly for enforcement not to break them. Coordinating four vendors across three business functions is a project, not a task, and it does not have an owner in most orgs.
Business email compromise is the counterweight. The FBI Internet Crime Complaint Center attributes approximately $2.77 billion in reported US losses to BEC in 2024 ( IC3 2024 Report, retrieved 2026-09-03) — a class of attack that a domain at p=reject largely prevents against its own recipients. The Facebook and Google $121M BEC incident (2013-2015, perpetrator Evaldas Rimasauskas) is the canonical case study for what enforcement would have caught. For the full incident story, see the Facebook/Google BEC breakdown.
The 30-day path from p=none to p=reject
The migration is not a full-time project. It is four weeks of part-time work if a single engineer owns it end-to-end. The steps are boring and mechanical, which is the point.
- Week 1 — instrument. Publish or confirm
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;. Pointruaat a mailbox you actually watch. Sign up for a free tier of a DMARC report parser (Postmark DMARC Digests, Google Postmaster Tools, or a paid vendor). Wait seven days for reports to arrive. - Week 2 — inventory. Read the reports. List every source IP and every d= domain sending mail that claims to be your domain. Classify each as legitimate (with owner), unknown, or spoofed. Nine times out of ten the surprise is not phishers — it is a legitimate vendor someone forgot to configure.
- Week 3 — align. For every legitimate source, ensure both SPF and DKIM produce aligned passes. Add the vendor to your SPF include list. Publish the vendor’s DKIM selector. Verify with a test send. When your reports show 100% aligned pass on legitimate mail — and only failures on the unknown / spoofed rows — you are ready.
- Week 4 — advance. Move to
p=quarantine; pct=25;. Watch for 5 days. Increase topct=100;. Watch for 5 more days. Move top=reject; sp=reject;. Publish. You are done.
The sp=reject is not optional. Without an explicit subdomain policy, every subdomain under your apex — including invoice.yourdomain.com, secure-payments-2026.yourdomain.com, and every other lookalike an attacker feels like inventing — inherits no policy. That is a wide-open spoofing gap.
pct= tag scales enforcement by percentage of failing mail. At pct=25, mailbox providers apply the policy to 25% of failing messages and let 75% through. This is your safety valve. If a legitimate sender you missed is suddenly failing, you see the volume in reports before it costs you a support incident.What monitoring looks like after enforcement
Once you are at p=reject; sp=reject; the failure modes change. You now care about three signals no one paid attention to before:
- New sender appears. A vendor onboarded by marketing starts sending on your domain tomorrow without an SPF/DKIM update. Their entire send fails DMARC and gets rejected. Marketing thinks the vendor is broken; you look at the reports and see the alignment failure. Fix time: hours if you notice, days if you don’t.
- Selector rotation breaks DKIM. Your ESP rotates the DKIM selector. You forgot to publish the new key in DNS. Every message fails DKIM, and if SPF is misaligned too, every message rejects. Silent until someone reports a missing invoice.
- Subdomain drift. A team stands up a new subdomain and starts sending from it. It inherits
sp=reject, everything fails, they file a ticket asking why. The correct answer is “publish an explicit DMARC / SPF / DKIM for the new subdomain,” but that answer requires that someone knows the subdomain was stood up in the first place.
DomainScan monitors DMARC posture continuously as part of the DMARC guided journey (Pro tier). Add a domain, get graded on where you are on the p=none → p=reject ramp, get RUA report ingest that parses XML into readable dashboards, and get alerted the moment your SPF or DKIM stops aligning. Free forever for 2 domains, no credit card.
FAQ
Is p=none better than no DMARC record at all?
Slightly. p=none gives you the aggregate reports, which tell you who is sending mail using your domain. That visibility is worth having — but it does not stop a single spoofed message from reaching an inbox. Treat p=none as a two-week diagnostic phase, not a resting state.
Will moving to p=reject break my legitimate mail?
Only the legitimate mail that fails alignment. If your SPF include list and DKIM selectors are complete and aligned, no legitimate mail fails. The 30-day plan above exists specifically to inventory every source before flipping the policy — with the pct= tag as a safety valve.
Do I need a paid DMARC vendor to parse the reports?
For a domain sending under 100K messages a month, free tiers from Postmark DMARC Digests or Google Postmaster Tools are enough. Above that, or once you have five or more sending sources to track, a paid parser (Dmarcian, EasyDMARC, Valimail Monitor) saves enough time to be worth it. DomainScan’s Pro tier includes RUA ingest as part of the subscription rather than as a per-domain add-on.
What is DMARC alignment, exactly?
DMARC passes if the domain in the visible From: header matches either the SPF envelope sender domain or the DKIM signing domain. Relaxed alignment (default) accepts subdomain matches — mail.example.com aligns with example.com. Strict alignment requires exact match. Get either one right on a per-source basis and DMARC passes.
Do I need DKIM if SPF is passing?
Yes. SPF alone fails on forwarded mail (the forwarder’s IP is not in your SPF record). DKIM survives forwarding because the signature travels with the message. Both together are the minimum to keep legitimate mail delivering under p=reject.
Can attackers see my DMARC policy?
Yes. DMARC records are public DNS. Anyone can query _dmarc.yourdomain.com. A domain at p=none is publicly advertising to phishers that it is spoofable. A domain at p=reject is publicly advertising the opposite. This is a feature — the policy is meant to be discoverable so that mailbox providers can enforce it.