AgentMail. Cloudflare Email Service. Resend's agent SDK. Every AI SDR startup on Product Hunt this month. The pitch is always the same: "one API call and your agent has an inbox."
Cool. I went and measured the ground they're all standing on.
671,693 domains with MX records. 634,220 with SPF. 468,749 with DMARC. Daily forward-DNS scan of the Tranco top-1M, snapshot 2026-07-25.
Here's the number that should ruin your afternoon:
Last month the internet added 9,173 net new DMARC domains. DMARC enforcement went DOWN 0.42 percentage points.
Read it again. More people published DMARC. Less of the internet is protected. Three out of four of those new records were a p=none sticker.
That is not adoption. That is dilution wearing an adoption costume.
Gut punch #1: a quarter of all DMARC records are load-bearing nothing
Break the 468,749 DMARC-publishing domains down by what the record actually does:
| Category | Domains | Share |
|---|---|---|
Enforcing (p=quarantine / p=reject) |
~231,100 | 49.31% |
Monitoring (p=none, but reports flow) |
~120,000 | 25.61% |
Inert (p=none, no working rua=) |
117,384 | 25.04% |
| Invalid / other | ~200 | 0.04% |
That third row is my favourite thing on the internet right now.
117,384 domains publish a DMARC record with p=none and no working aggregate report address. It blocks nothing. It reports nothing. It is a TXT record whose entire function is to make a compliance checkbox turn green.
v=DMARC1; p=none;
Twenty characters of pure theatre. Somebody billed for that. (It is, verbatim, the single most common DMARC record on the internet: 58,997 domains carry exactly that string.)
And it gets funnier when you zoom out from "inert" to "blind":
35.51% of all DMARC-publishing domains — 166,442 of them — have no working
rua=address.
166,442 domains published an email authentication policy and then unplugged the telemetry. Some of them are on p=reject. Think about that: they are actively bouncing mail and they cannot see whose. If a partner integration breaks tomorrow, they find out via an angry phone call in three weeks.
You would never ship a service with the metrics endpoint deleted. A third of the web ships its email policy exactly that way.
Gut punch #2: security is a function of how famous you are
Split DMARC enforcement by Tranco rank tier:
| Tier | Enforced |
|---|---|
| top 1k | 73.05% |
| 1k–10k | 56.46% |
| 10k–100k | 43.34% |
| 100k–1M | 29.81% |
| Not in the current list | 19.10% |
The head of the internet is 3.8× more defended than the tail.
Every "email authentication is basically solved in 2026" take you have read was written by someone who checked google.com, stripe.com and their own employer, all of which live in that first row. Step outside the top 1k and most domains are wide open.
Your agent's prospects live in the tail. Your agent's customers live in the tail. Your vendors, your webhooks, your billing provider's regional subsidiary — tail, tail, tail.
Gut punch #3: self-hosting email is not dead. It is #1.
The received wisdom of the last decade: nobody self-hosts email anymore, it's Google and Microsoft, give up.
Inbound mail hosting across those 671,693 domains:
| Rank | Provider | Share |
|---|---|---|
| 1 | Self-hosted | 22.79% |
| 2 | Google Workspace | 21.83% |
| 3 | Microsoft 365 | 16.87% |
Self-hosted is the single largest category. Bigger than Google. 153,105 domains running their own MX in the year the entire industry told you it was impossible.
Google + Microsoft together are 38.70%, which is a genuinely alarming concentration number and the one everybody quotes. Nobody quotes the row above it, because it makes a decade of "just move to Workspace" content look like marketing.
Two things are true at once: the duopoly is real, and the graveyard everybody describes is full of living people.
Gut punch #4: one domain in four has a stranger in its SPF allowlist
I extracted every SPF include: / redirect= target across those 634,220 SPF-publishing domains and matched them against open dictionaries of ESPs, SaaS senders and security gateways.
Classification coverage: 82.66% of include targets. That leaves 80,991 unique include targets that no public dictionary can name. And the per-domain view is worse: only 72.37% of domains that delegate through an include: come back fully classified — more than one in four has at least one entry in its sending allowlist that cannot be identified.
This is the part that should actually scare you, and it is 100% the agent story.
Every agentic email product onboards you the same way: "add our include: to your SPF and you're done." You paste it. It stacks onto the eleven that are already there from the CRM, the ticketing tool, the marketing automation, the e-sign vendor, the abandoned 2021 webinar platform nobody has admin access to anymore.
An include: is not a config line. It is a standing grant of permission to send mail as you. Forever. There is no expiry. There is no audit log. There is no "this include has not been used in 400 days" dashboard, anywhere, from anyone.
And SPF hard-caps at 10 DNS lookups. Blow past it and the whole record fails — not degrades, fails. Which means the way most teams discover their SPF is over budget is that legitimate mail stops arriving and nobody knows why, because — see gut punch #1 — the rua= was never wired up.
Why agents turn this from "tech debt" into "outage"
A human SDR ramps slowly. Writes differently on Tuesday than on Thursday. Gets bored, gets sick, takes PTO. All of that accidental noise is what sender reputation is calibrated against.
An agent fleet does none of that:
- Volume concentration. Ten humans' worth of output leaves through one domain, one auth path, one reputation bucket.
- Content convergence. One model, one system prompt, one voice. Filters cluster on exactly that.
- Ramp velocity. Reputation builds over quarters. An agent goes zero to full throttle the afternoon you deploy it.
Bolt that onto a domain with p=none, no rua=, and twelve unaudited include: grants, and you have not built an outbound channel. You have built a very fast way to set your domain on fire, with the smoke alarm removed.
The infrastructure vendors know this — it is why the good ones now auto-configure SPF/DKIM/DMARC and warm domains for you. But their auto-config writes p=none too, because p=none never breaks a customer's onboarding. Everyone's incentives point at the sticker.
That's your −0.42 pp, right there.
Four commands. Do them before you close this tab.
# 1. Do you enforce, or do you have a sticker?
dig +short TXT _dmarc.example.com
# Sticker: "v=DMARC1; p=none;"
# Real: "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; fo=1;"
# 2. Who is allowed to be you?
dig +short TXT example.com | grep spf1
# Count the include:. Can you name every single one? Out loud? Today?
# 3. Are you over the 10-lookup cliff?
# Each include:/redirect=/a/mx/ptr/exists costs a lookup, recursively.
# Over 10 = PermError = your SPF evaluates to nothing at all.
# 4. Does your DKIM selector actually resolve?
dig +short TXT selector1._domainkey.example.com
Then the thirty-second triage:
-
rua=first, always. Before you touch the policy. You cannot enforce what you cannot see.p=nonewith working reports is an honest engineering position;p=nonewithout them is a lie you are telling yourself. - Read reports for two weeks. Actual reports, not a vendor's summary of them.
-
Then move the dial.
none→quarantine→reject. Weeks, not months. You are already late. -
Delete an
include:this quarter. Any one. It will be terrifying. That terror is the finding. -
Give your agent its own subdomain.
agent.yourdomain.com, separate DKIM key, separate reputation. When it burns — when, not if — the fire stays in the room you built for it.
On the data, because someone will ask in the comments
Full disclosure, because half of you are about to check my work and I would like you to succeed:
- Source is the daily OpenINTEL forward-DNS Tranco snapshot (University of Twente); I re-use their aggregates and drop the raw parquet after analysis, per their data agreement. Snapshot date on every number above: 2026-07-25.
- "Top-1M" is not a denominator. The measured list carried 1,087,498 apex names (2026-07-24 partition); 671,693 of them published MX. Anyone handing you a clean "x% of the top 1M" is dividing by a number that does not exist.
- The history has a seam at 2022-08-11, where the underlying list flips from Alexa to Tranco. Different populations, different sizes. Absolute values do not compare across it and I will not pretend they do.
- MX classification is 328 regex patterns. Unmatched hosts are published openly rather than quietly bucketed into "other" — the top-100 unmatched list ships with every snapshot, and reader corrections land in the next day's run.
- Known blind spots, on the record: CNAME chains on MX are not unrolled (a slice of Microsoft 365 customers shows up as "unknown"); flattened SPF hides the ESP behind raw IP ranges, so every ESP share above is a floor, not a ceiling; DKIM visibility is limited to well-known selectors. If a number here can be wrong, this is the direction it's wrong in — and it's stated.
Numbers, methodology, changelog and per-domain lookup: check.live-direct-marketing.online/email-stats. CC BY 4.0, JSON API, llms.txt, 210 archived snapshots back to 2016. Rip it apart.
The bit that keeps me up
We are, collectively, this week, standardising a protocol so autonomous software can act on our behalf. Tasks. Long-running jobs. Agents mailing agents.
Underneath it sits SPF: a 2003-era mechanism whose security model is a list of strings in a TXT record that nobody audits and nobody can fully identify. Sitting on DMARC, which a quarter of its adopters have configured to do literally nothing. Getting weaker, month over month, while the graph of things depending on it goes vertical.
We are not building on rock. We are building very fast, on a floor that measurably softened last month, and the smoke detector is a rua= address that 166,442 domains never bothered to type.
Go run dig on your own domain. Right now, before the next standup.
Bet you find something.
Data: OpenINTEL Tranco snapshot 2026-07-25, n=671,693 domains with MX. Disagree with the methodology? Good — it's published, and I'd rather be corrected than quoted.
Top comments (0)