SPF and DMARC Statistics 2026: What 173 Million Mail Domains Publish

52.6% of the domains that can receive mail publish no SPF

We read the DNS of every domain on the internet, 2,847,611,085 records. 206,770,685 domains publish at least one MX, SPF or DMARC record, and 173,136,975 of them publish an MX record, which means they can receive mail and can therefore be impersonated. That is the population of this report and every share below is a share of it.

81,981,471 of them publish SPF, 47.4%. 50,246,481 publish DMARC, 29.0%. And 21,685,399, 12.5%, publish a DMARC policy that asks a receiver to do anything about a forgery.

Both standards are older than most of the domains using them. SPF was published in 2006 and DMARC in 2015, and neither costs anything to deploy beyond the time it takes to write one DNS record.

Seven mail domains in eight are still unprotected against somebody sending mail in their name, twenty years after the fix was specified.

Websites with no mail are the easiest to forge: 88.2% publish neither SPF nor DMARC

The headline number blends three different kinds of domain, and they behave nothing alike. A domain is a website here when its web server answered our crawl, and a mail domain when it publishes an MX record.

The going concern, 89,684,073 domains with both a website and mail, is the population that actually needs this: 49.0% publish SPF and 12.4% enforce DMARC. Domains with mail and no website publish DMARC far less often, 20.9% against 36.6%, publish SPF a little less, 45.6% against 49.0%, and enforce at the same rate, 12.6%.

Websites with no mail are the easiest to forge because nothing on the name says it never sends mail. Of the 61,965,672 websites without an MX record, 54,672,880 publish neither SPF nor DMARC, 88.2%, and 8.7% enforce DMARC, against 12.5% of mail domains. A receiver checking a message forged from one of these names looks up the records, finds nothing, and delivers it. Closing that costs two DNS records: an SPF record of v=spf1 -all, which says no server may send for the name, and a DMARC policy of p=reject, which tells the receiver to refuse anything that fails.

The 7.3 million that do publish are a different story: 73.7% of them enforce DMARC, six times the rate among websites with mail. That is not diligence, it is a registrar. Parking services publish exactly those two records across their whole book automatically. The best authentication records on the internet sit on names with nothing to protect, because a machine wrote them, and the going concerns are configured by people.

56.4% of live websites publish neither record

The three kinds of domain above split on what a domain is for. This one splits on how visible it is, and asks the simpler question behind the whole report: of the domains that publish nothing at all, no SPF and no DMARC, where do they sit?

85,567,141 live websites publish neither record, 56.4% of the 151,649,745 whose web server answered. Among domains with mail configured the figure is 38.9%, 67,331,703 of 173,136,975.

The gradient runs one way and it is steep. 18.2% of top ten thousand websites publish nothing, against 56.7% of the unranked. A site nobody visits is about 3.1 times more likely to be wide open than one everybody does.

A live website is worse than a mail domain in every band, because most websites never had mail set up on the name and publish nothing at all, which leaves the name open to forgery just the same. Mail domains without a website are the next worst, 43.9% of the 83,452,902 of them publishing neither record, the shape you would expect from a name a company uses for staff addresses and nothing else: nobody browses to it, nobody audits it, and it publishes an MX record because somebody set up mailboxes years ago. 170,594,000 unranked domains carry mail configuration, and 39.1% of them have neither record.

The domains most worth forging are the best protected, and there are very few of them. Everything below the first million is where a forged invoice actually gets sent from.

45.8% of published DMARC does nothing

DMARC has three settings and only two of them do anything. p=none asks receivers to send reports and deliver the message regardless. p=quarantine sends a failing message to spam. p=reject refuses it.

30,281,845 domains publish p=none, 45.8% of every DMARC record on the internet. It is the correct place to start, because it lets an operator see which of their own systems would break before they turn enforcement on. It is not a place to stay, and the published adoption figures never separate the two.

This is why "DMARC adoption" and "DMARC protection" are different numbers, and only the first one is ever quoted. 29.0% of mail domains publish DMARC and 12.5% are protected by it.

Publishing SPF does not make a domain any safer

Half the internet's mail domains publish SPF and one in eight enforces anything, and the obvious question is how both can be true. The answer is that the two standards are independent and only one of them tells a receiver what to do.

SPF says which servers may send. It does not say what to do about a message from anywhere else, and on its own a receiver is free to deliver the forgery anyway. DMARC is the part that turns a failure into an action. A domain can publish a careful SPF record for a decade and nothing at the other end ever changes.

The numbers are blunter than that. Domains with no SPF at all enforce DMARC on 12.3%, and domains that publish SPF ending in ~all enforce on 8.5%, which is less. Publishing a soft fail and then leaving DMARC alone is the commonest configuration on the internet and it protects nothing: the domain has told the world which servers are legitimate, and told receivers to deliver mail from everywhere else regardless.

Only the hard fail group behaves differently, at 21.0% enforcing. Whoever is willing to write -all is the same person willing to set p=reject, which is the real finding: it is not a technical dependency, it is whether anyone owns the problem.

SPF adoption is the most quoted number in mail security and it is close to meaningless on its own.

The two commonest DMARC records on the internet were each written once

The single commonest DMARC record on the internet is v=DMARC1; p=none;, published by 11,543,817 domains. The commonest thing anybody publishes is the setting that does nothing.

The second commonest is one identical string on 11,329,644 domains: v=DMARC1; p=quarantine; adkim=r; aspf=r; followed by a rua address at onsecureserver.net, which is GoDaddy. A further 2,192,747 publish the same string at p=reject. In total 13,786,006 domains send their DMARC reports to GoDaddy.

The detail that matters is where those domains are. 10,158,033 of them have no MX record at all, so GoDaddy switched on an enforcing policy for millions of parked domains. That is the right thing to do, and it also means any chart showing DMARC enforcement rising is substantially a chart of parked domains changing hands.

Among domains that actually receive mail, GoDaddy's template is 15.6% of all enforcing policies.

The same lesson keeps arriving in a different file. Measure a configuration at internet scale and what you are mostly measuring is what a handful of large platforms decided on their customers' behalf.

57.7% of DMARC policies report to nobody

A DMARC record's rua tag names the mailbox that receives the daily aggregate reports. Without it an operator publishes a policy and never learns whether it is working, or whether it is quietly rejecting their own invoices.

38,148,614 domains publishing DMARC, 57.7%, have no rua tag. A further 5,878,716 send the reports to a mailbox on their own domain and 267,578 to a personal Gmail or Outlook address, where compressed XML attachments arrive daily and nobody opens them.

Domains where we detect the service, which is the figure each row's own page carries

Chart Table view

These are our own detection counts, the same figure each service's technology page carries, so a row and the page it links to agree. The share of DMARC publishers above is measured separately, from the reporting address in the record itself.

Embed this figure

<a href="https://www.stackscan.com/blog/spf-dmarc-statistics#fig-vendors"><img src="https://content.stackscan.com/charts/spf-dmarc-statistics-vendors.webp" alt="The services DMARC reports are sent to" width="880" style="max-width:100%"></a> <p>Source: <a href="https://www.stackscan.com/blog/spf-dmarc-statistics#fig-vendors">StackScan mail analysis</a></p>

3,129,895 domains, 4.7%, send their reports to a specialist DMARC vendor. That figure is the real size of the DMARC tooling market: dmarcian, Valimail, DMARC Analyzer, Postmark, OnDMARC, GlockApps and the rest of the category serve three million domains between them.

The chart below counts the same services a different way, the way their own pages on this site count them, which is every domain where we detect the service rather than only the domains whose reporting address names it. A service listed as somebody's second reporting address is in the chart and not in the share above, so the chart runs higher.

A policy nobody monitors is a policy nobody will ever tighten, which is most of the reason the p=none figure has barely moved.

679,765 domains have SPF that does nothing

Only the last mechanism in an SPF record matters. -all tells a receiver to refuse anything from an unlisted server, ~all tells it to accept the message anyway and mark it, and ?all says nothing at all. The split is almost even: 48.4% end in ~all and 46.1% in -all.

Soft fail is the cautious setting, and on nearly half the internet it is permanent. An operator who cannot be certain they have listed every sender leaves it at ~all, and nothing ever forces the question.

Three failures are worth counting separately. 679,765 domains publish more than one SPF record, which RFC 7208 says is a permanent error: a receiver does not pick one, it gives up, and SPF does nothing at all on those domains. 29,234 publish +all, which explicitly authorises every server on the internet to send as them. And 110,713 publish a record longer than a single DNS string can hold.

An SPF record that is broken and an SPF record that is absent protect a domain equally well, and the broken ones come with the belief that the job is done.

545,620 domains published DMARC where nothing will look for it

A DMARC record does not live on the domain. It lives on a subdomain called _dmarc, so a receiver checking example.com looks up _dmarc.example.com and nowhere else. A v=DMARC1 string published on example.com itself is a TXT record that no mail server on earth will ever read.

545,620 domains have done exactly that. 355,492 of them have no record at _dmarc either, so the policy they believe they published does not exist as far as any receiver is concerned. The other 190,128 have a working record too and the stray one is merely litter.

The mistake thins out towards the top of the web. 0.16% of top ten thousand domains that published DMARC put it in the wrong place, against 0.68% of the ranked long tail: ten domains against 6,825.

Then the bottom row breaks the pattern. The unranked, 65,000,075 domains that no ranking has heard of, get it wrong 0.53% of the time, better than the ranked tail above them. Whatever that column is measuring, it is not care.

Domains publishing DMARC on each provider's nameservers, and the share that published it at the wrong name

DNS provider	Domains publishing DMARC	Published it at the wrong name	Share
Wix	214,642	8,042	3.75%
OVH	323,789	6,089	1.88%
UltraDNS	115,340	840	0.73%
Azure DNS	177,899	1,199	0.67%
NS1	305,416	2,016	0.66%
Nameservers we cannot attribute	43,403,340	265,740	0.61%
Cloudflare	6,120,844	36,444	0.60%
AWS Route 53	752,218	3,418	0.45%
Squarespace	218,222	922	0.42%
Namecheap	1,174,055	4,355	0.37%
GoDaddy	11,203,327	21,227	0.19%
WordPress	373,947	647	0.17%
Google	2,038,051	3,151	0.15%

Every wrong record is counted; the domains publishing DMARC behind each provider are measured on a one in a hundred sample, because joining 122 million provider records to 66 million publishers in a single pass does not fit in memory. The smallest provider named here is worth about 1,100 sampled domains. Each row counts only the domains on that provider that published a DMARC record at all, so it is a slice of the provider's own page, not its total.

Embed this figure

<a href="https://www.stackscan.com/blog/spf-dmarc-statistics#fig-panels"><img src="https://content.stackscan.com/charts/spf-dmarc-statistics-panels.webp" alt="Which DNS provider the misplaced record was published through" width="880" style="max-width:100%"></a> <p>Source: <a href="https://www.stackscan.com/blog/spf-dmarc-statistics#fig-panels">StackScan mail analysis</a></p>

It is measuring which DNS provider the record was typed into, and the spread is wider than anything rank produces. Domains on Google's nameservers publish it at the wrong name 0.15% of the time and domains on GoDaddy's 0.19%. Wix is at 3.75%, twenty-five times Google's rate for the same record, and OVH at 1.88%.

That is the whole of the anomaly. 17.2% of unranked DMARC publishers sit on GoDaddy's nameservers and 8.8% on Cloudflare's. In the ranked tail those proportions invert, 7.7% and 23.8%, and Cloudflare's domains get this wrong 0.60% of the time against GoDaddy's 0.19%. The ranked long tail is not less careful than the unranked one. It is on different nameservers.

It is the cheapest failure in this report. A correct record moved one label to the left, and 355,492 owners are running with a policy that exists only in their own DNS panel.

GoDaddy mail customers publish SPF on 6.7% of their domains

Domains whose MX record points at the provider, and what those domains publish

Mail provider	Websites on its page	Mail domains measured	Publish SPF	Publish DMARC	DMARC enforces
Everybody else		103,094,561	48.4%	31.6%	14.2%
Google Workspace	21,104,699	20,684,917	41.8%	29.9%	12.8%
Microsoft 365	12,382,637	14,113,680	60.0%	37.6%	20.3%
GoDaddy	15,283,956	9,377,609	6.7%	9.7%	8.7%
IONOS	8,321,724	7,939,620	58.9%	2.9%	0.8%
Namecheap	9,239,580	7,893,710	55.2%	1.3%	0.2%
Hostinger	4,143,412	3,927,900	54.6%	83.4%	1.2%
Cloudflare	1,902,228	2,028,666	50.0%	27.7%	9.0%
Zoho	2,214,126	1,939,600	53.2%	33.3%	11.4%
Yandex	1,006,449	982,168	68.6%	9.1%	3.3%
Tencent QQ	717,110	815,521	34.9%	15.1%	1.9%
Mimecast	175,658	189,375	55.6%	56.4%	35.7%
Proofpoint	1,134,258	149,648	56.4%	65.3%	47.0%

Embed this figure

<a href="https://www.stackscan.com/blog/spf-dmarc-statistics#fig-providers"><img src="https://content.stackscan.com/charts/spf-dmarc-statistics-providers.webp" alt="Mail providers, and how well their customers authenticate" width="880" style="max-width:100%"></a> <p>Source: <a href="https://www.stackscan.com/blog/spf-dmarc-statistics#fig-providers">StackScan mail analysis</a></p>

Where a domain's mail is hosted predicts its authentication better than anything else in this report.

The table carries two counts because they answer different questions. The first is the figure on the provider's own page on this site, which is every website where we detect the service. The second is the domains whose MX record points at it, which is the population the three shares are taken from. A provider's customers can run a website that names the service without routing their mail through it, and a parked domain can route mail with no website to detect, so the two never match. GoDaddy is the widest gap in the table for exactly that reason: a great many of its mail routes hang off domains with no site to detect anything on.

Microsoft 365 customers publish SPF on 60.0% of their domains and enforce DMARC on 20.3%, the best of the large providers. Google Workspace customers publish SPF on 41.8%, noticeably worse, on 20,684,917 domains.

GoDaddy is the outlier and not in a good way. Its mail customers publish SPF on 6.7% of domains and DMARC on 9.7%, the lowest of any provider here, while the same company publishes DMARC records on 13.8 million parked domains. The automation was pointed at the domains with nothing to lose.

Two more shapes. IONOS and Namecheap customers publish SPF at 58.9% and 55.2% and DMARC at almost nothing, so the registrar set up SPF and stopped. Hostinger is the mirror image: 83.4% publish DMARC and 1.2% enforce it, which is a default p=none shipped at scale.

The security filters do best because their customers bought them for this: Proofpoint at 47.0% enforcing and Mimecast at 35.7%.

A domain's mail provider decides its authentication, and most providers have decided not to.

Enforcement rises with company size, SPF does not

14.4% of two to ten person companies publish an enforcing DMARC policy. At five thousand to ten thousand staff it is 34.0%, more than twice as many.

SPF does not move. It sits between 48.5% and 55.8% across every band, which is the signature of a setting somebody else configured once rather than a decision anybody revisits. It is also, as the section above shows, the setting that predicts the least.

The gradient is not size, it is whether anyone owns the problem. SPF arrives with the hosting. DMARC enforcement needs a person who can say which systems send mail, accept that some of them will break, and answer for it when they do.

A ccTLD's numbers measure its registrars, not its awareness

Enforcement ranges from 30.0% on .ch down to 4.3% on .ru, and the temptation is to read that as some countries caring more than others. The table says otherwise if you read two columns instead of one.

49.6% of .it mail domains publish DMARC, a higher share than 33.7% on .de. Then 4.5% of them enforce it, against 24.1% on .de. Italy has not had a national conversation about mail security and decided to stop halfway. A hosting company with a large Italian book switched DMARC on at p=none and never moved it, and that one default is most of the column. Japan is the same shape, 37.1% publishing and 7.0% enforcing.

Nothing here measures whether the people in a country understand SPF and DMARC. It measures which registrars and hosts have the largest share of that market and what those companies ship when nobody asks. A ccTLD is a proxy for a set of defaults, and reading it as a proxy for competence gets the causation backwards.

Which is the practical conclusion of the whole report. Every large movement in these numbers, GoDaddy's 13.8 million policies, Hostinger's 83.4% publishing against 1.2% enforcing, Italy's gap, came from one company changing one default. Documentation has not moved mail authentication in twenty years and defaults move it in a quarter.

Frequently asked questions

What percentage of domains have SPF?

47.4% of the domains that can receive mail, 81,981,471 of the internet's 173,136,975 domains with an MX record. Across every domain in the DNS the figure is lower, because most domains cannot receive mail at all.

What percentage of domains have DMARC?

29.0% publish a DMARC record, and only 12.5% publish one that enforces. The gap is p=none, which is 45.8% of every DMARC record on the internet.

Is p=none worth publishing?

As a first step, yes: it is how an operator learns which of their own systems fail authentication before turning enforcement on. As a destination it protects nothing, and 57.7% of DMARC publishers do not even collect the reports that make the first step useful.

What does ~all mean in SPF?

Soft fail. It tells a receiver to accept a message from an unlisted server and mark it as suspicious. -all tells the receiver to refuse it. 48.4% of SPF records end in ~all.

Can two SPF records be published on one domain?

No. RFC 7208 makes it a permanent error, and a receiver that finds two stops evaluating SPF entirely. 679,765 domains do it anyway.

Which mail provider's customers authenticate best?

Of the large providers, Microsoft 365: 60.0% SPF and 20.3% enforcing DMARC. Of all providers, the security filters, because their customers bought them for exactly this.

If I publish SPF, am I protected?

No. SPF says which servers may send for your domain and stops there; DMARC is what tells a receiver to act on a failure. Domains publishing SPF with a soft fail enforce DMARC on 8.5%, lower than the 12.3% of domains publishing no SPF at all.

Do I need DKIM as well?

Yes, and this report does not measure it. A DKIM record lives at a selector the publisher chooses, so it cannot be found without already knowing the name, and any DKIM adoption figure is really a figure about which selectors the measurer guessed.

Why do parked domains publish better records than real ones?

Because a registrar configured them in bulk and a business configured its own by hand. Among websites with no mail that publish any record at all, 73.7% enforce DMARC, against 12.4% of websites with mail. Most no-mail websites publish nothing, though, so across all 62 million of them only 8.7% enforce.

Methodology and sources

Population. We read the DNS of every domain on the internet, 2,847,611,085 records. 206,770,685 domains published at least one MX, SPF or DMARC record; 173,136,975 publish an MX record and can receive mail, and that is the denominator for every share in this report. A domain that cannot receive mail cannot be impersonated the way these standards exist to prevent.

Website or not. A domain counts as a website when its web server answered our crawl, 151,649,745 domains. That is what separates a going concern from a parked name. The CMS report counts websites from a separate technology crawl and arrives at a higher total, and each report's shares are taken over its own count. A website with no MX, SPF or DMARC record at all still counts as a website, and as one that publishes nothing; the shares for no-mail websites and for websites that publish neither record are taken over every website, not only those with some mail record.

What counts as SPF and DMARC. An SPF record is a TXT record beginning v=spf1 on the domain itself. A DMARC record is a TXT record beginning v=DMARC1 at _dmarc under it. The policy is the p tag, and enforcement means p=quarantine or p=reject. SPF's policy is the last all mechanism, which is the only part a receiver acts on.

DKIM is not measured and no figure is published for it. A DKIM key lives at selector._domainkey, and a selector is whatever the publisher chose, so finding one means guessing names. Any DKIM adoption number is a statement about the guesser's list.

The SPF lookup limit is not measured either. SPF permits ten DNS lookups and a record that exceeds them fails, but the limit is usually blown by nested includes rather than by the record in front of you. Counting it honestly means resolving every include chain, which is a separate job.

Company size comes from matching a domain to the company records we hold, which covers a minority of domains. Every share names the base it is taken from.