Your Email Domain Is Probably Spoofable: DMARCbis and the 68% Enforcement Gap

Every organisation has a security control it assumes someone else already handled. Email authentication is usually it. Marketing thinks it’s IT. IT thinks it’s the email provider. The development team, which actually owns most of the domains sending mail, often doesn’t know it’s in scope at all.

The numbers say that assumption is wrong almost everywhere. A CipherCue analysis published in late July 2026, covering 67,336 domains observed between 14 April and 28 July, found that 68.4% of domains have no meaningful DMARC enforcement — 45.1% publish no DMARC record whatsoever, and another 23.3% sit at p=none, which instructs receiving servers to do precisely nothing. That’s a single vendor’s tracked cohort rather than a census of the internet, so treat the exact figure with appropriate caution. The shape of the problem, though, matches what we see on nearly every infrastructure audit we run.

Meanwhile, the specification itself changed in May 2026 for the first time in a decade. If your DMARC record was written before then, it contains at least one tag that is now formally deprecated.

TL;DR

• 68.4% of domains lack DMARC enforcement — 45.1% have no record at all, 23.3% are stuck at p=none, according to a July 2026 analysis of 67,336 domains.
• DMARCbis landed in May 2026 as RFC 9989, 9990 and 9991, replacing the decade-old RFC 7489 and promoting DMARC from Informational to Proposed Standard.
• The pct=, rf= and ri= tags are deprecated. New np= (non-existent subdomain policy), psd= and t=y testing mode replace them, and a DNS tree walk replaces the Public Suffix List.
• Mailbox providers stopped being polite. Microsoft rejects non-compliant bulk mail outright with 550 5.7.515; Gmail moved from temporary deferrals to permanent rejections in November 2025.
• The blocker is operational, not technical. Teams stall at p=none because they cannot identify every system sending mail as their domain — which is a discovery problem your engineering team is best placed to solve.

Why this is an engineering problem, not a marketing one

The instinct is to file email authentication under “deliverability” and hand it to whoever owns the newsletter. That framing is why so many domains are stuck.

Marketing knows about one sending source: the ESP. Your application sends far more. Password resets and transactional notifications from your app servers. Invoices from Stripe or Xero. Support replies from Zendesk or Intercom. Alerts from your CI/CD pipeline, your monitoring stack, your status page. Calendar invites from a booking tool nobody has logged into since 2023. Every one of those is mail claiming to be your domain, and every one of them needs to authenticate correctly before you can safely tell the world’s mail servers to reject anything that doesn’t.

That inventory exercise is the actual work. It’s also why the CipherCue data on aggregate reporting is the most revealing finding in the whole analysis: across 26,179 rua= reporting addresses, there were 10,268 distinct reporting domains, and 79% of them appeared exactly once. Reporting is fragmented to the point of being unusable at scale. Administrators publish a record, point reports somewhere, and then face a firehose of XML describing sender streams they cannot identify. So they never advance the policy. Monitoring mode becomes permanent.

What DMARCbis actually changed

In May 2026 the IETF published three documents that replace RFC 7489: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). DMARC moved from Informational status to the standards track as a Proposed Standard — a decade after it became load-bearing infrastructure for global email.

The practical changes worth acting on:

• pct= is gone. Percentage-based rollout was implemented inconsistently across receivers and never behaved the way most administrators believed it did. Delete it. The replacement is t=y, an explicit testing-mode flag that tells receivers your enforcement is provisional.
• rf= and ri= are deprecated too. Only one report format was ever used, and receivers ignored the report interval in practice. Both were configuration theatre.
• The Public Suffix List is out. Organisational domain discovery now uses a deterministic DNS tree walk, capped at eight lookups. No more depending on an externally maintained file that your receiver may or may not have updated.
• np= is a genuine security win. It sets policy for non-existent subdomains separately from sp=. Attackers routinely spoof subdomains that were never registered, precisely because they inherit weaker handling. You can publish np=reject today with essentially zero risk to legitimate mail, because by definition no legitimate mail comes from a subdomain that doesn’t exist.
• External destination verification is now a MUST, not a SHOULD — relevant if you send aggregate reports to a third-party DMARC platform.
• p=reject is formally downgraded to quarantine for indirect mail flows, codifying what Gmail and Microsoft already did for mailing lists and forwarders. This removes one of the longest-standing objections to enforcement.

None of this breaks existing records. v=DMARC1 is still correct — there is no DMARC2. But a record carrying pct=50 is now expressing an intent the specification no longer defines, which is a poor position to be in during an incident review.

The providers already made this mandatory

Whatever your internal prioritisation says, the mailbox providers have made the decision for you.

Google and Yahoo introduced bulk sender requirements in February 2024 for anyone sending 5,000 or more messages a day, initially enforced with temporary deferrals. Those became permanent rejections in November 2025. Microsoft applied equivalent rules to Outlook, Hotmail and Live from 5 May 2025, with non-compliant mail bounced at 550 5.7.515 — not junked, rejected. Alongside authentication, RFC 8058 one-click unsubscribe headers are required, with opt-outs honoured within 48 hours, and spam complaint rates must stay below 0.30%. In practice, senders who want stable placement now target 0.10%.

The threshold matters less than the trajectory. Requirements introduced for bulk senders have a consistent habit of becoming baseline expectations for everyone. If your transactional mail — the password reset that gates access to your product — silently fails alignment, you will discover it as a support ticket queue, not a monitoring alert.

The AI dimension nobody has priced in

Two things changed the risk calculus in the last eighteen months.

First, phishing got cheap and good. The spelling mistakes and awkward phrasing that trained a generation of employees to spot fraudulent mail are gone. Convincing, contextually accurate impersonation of your brand is now a commodity. Sender authentication is one of the few controls that doesn’t degrade when the content improves, because it validates provenance rather than plausibility.

Second, AI assistants increasingly read, triage and act on email on a user’s behalf. An agent summarising an inbox or drafting a reply is making trust decisions about sender identity at machine speed, without the human hesitation that occasionally catches a bad message. We’ve written before about agent trust boundaries in development tooling; the same principle applies to the inbox. If your domain can be spoofed, you are handing attackers a trusted channel into systems that are becoming progressively more automated and less sceptical.

A realistic path from p=none to enforcement

This is a six-to-twelve week project for most organisations, not a one-afternoon DNS change.

1. Inventory every sender. Application servers, ESP, CRM, billing, support desk, monitoring, HR tooling, anything with an SMTP configuration. Treat it as an audit, not a memory exercise — nobody remembers all of them.
2. Publish p=none with a rua= address pointed at something that parses the reports into a readable view. Raw aggregate XML is not a reporting strategy.
3. Fix SPF and DKIM properly. SPF has a hard limit of ten DNS lookups; exceeding it fails the check silently. Use 2048-bit DKIM keys, rotate them, and verify that the signing domain aligns with the visible From domain — passing SPF or DKIM against a different domain does not satisfy DMARC.
4. Publish np=reject early. It’s the highest-value, lowest-risk change available, and it closes off a subdomain spoofing vector immediately.
5. Move to p=quarantine with t=y once reports show your known senders passing consistently for two to four weeks. Then drop the testing flag. Then move to p=reject.
6. Put the record under version control. DNS is infrastructure. Manage it through Terraform or your IaC tooling of choice, review changes in pull requests, and add DMARC, SPF and DKIM validation to your deployment checks so that adding a new SaaS tool cannot quietly break alignment.

Step six is the one that separates a project from a posture. Domains that reach p=reject and then regress do so because a new sending source was added by someone who had no idea a record existed.

The uncomfortable summary

Email authentication is unglamorous, has no dashboard anyone wants to show a board, and generates zero revenue. It is also one of the very few security controls that costs almost nothing, is fully within your control, and directly prevents your brand being used to defraud your own customers. The specification just got its first serious update in ten years, the mailbox providers have stopped issuing warnings, and the attackers have better tooling than they did last year.

If two-thirds of domains are still unprotected, the differentiator isn’t knowing about DMARC. It’s finishing the rollout.

At REPTILEHAUS we handle this as part of infrastructure and DevOps work — sender discovery, SPF and DKIM remediation, aggregate report tooling, and getting the whole thing into infrastructure-as-code so it stays fixed. If your team knows the record needs attention but nobody has the bandwidth to own the migration, get in touch.

---

📷 Photo by sue hughes on Unsplash