2026-07-20 · RESEARCH · The Offensive Technology team

How exposed are the world's busiest domains to email spoofing?

Short answer: We took the 1,000 busiest domains on the internet, resolved 994 of them, and read their public email-authentication DNS records. 41.5% publish no enforcing DMARC policy, which means mail that forges their domain in the From line is not rejected or quarantined on that basis and can reach inboxes. Just under 30% (29.6%) publish no DMARC record at all, and another 11.9% publish one set to monitor only (p=none), which watches for spoofing without stopping it. The deeper controls are rarer still: 13.6% use DNSSEC and 3.2% announce MTA-STS. Every number here comes from passive public DNS lookups we ran ourselves against a published top-sites list. No host was contacted, nothing was scanned. Here is exactly how we measured it, and what it does and does not prove.

The finding in one chart

For each domain we asked four public questions. Does it publish an SPF record? Does it publish a DMARC record, and is the policy actually enforcing? Is the zone signed with DNSSEC? Does it announce MTA-STS? The answers thin out fast as the controls get stronger:

The one number that matters: enforcing DMARC

Email has three well-known authentication records, and it is easy to mistake having some of them for being protected. SPF (RFC 7208) lists which servers may send mail for a domain. DKIM (RFC 6376) signs a message so a receiver can verify it was not tampered with. Neither, on its own, protects the address a human actually reads.

Here is the gap an attacker uses. SPF validates the envelope sender, the hidden Return-Path used during delivery, not the From address shown in the mail client. A message can pass SPF for some throwaway domain the attacker controls while displaying your domain in the From line. DKIM only helps if something checks that the signature aligns with the visible domain and rejects mail when it does not. The record that ties authentication to the visible From address, and tells receivers what to do when it fails, is DMARC (RFC 7489).

DMARC has three policy settings, and the difference between them is the whole game:

• p=reject tells receivers to refuse mail that fails. This is the setting that actually stops domain forgery.
• p=quarantine tells receivers to treat failing mail as suspicious, typically routing it to spam. Enforcing, if weaker than reject.
• p=none tells receivers to do nothing except send the domain owner reports. Forged mail still lands. It is monitoring, not defense.

So the honest question is not "does this domain have DMARC" but "does its DMARC actually enforce." When you count only quarantine and reject as enforcement, 58.5% of the domains we resolved qualify. The other 41.5% are the exposed population: no record, or a record that only watches.

Read the bottom three rows together. That is the 41.5%: forged mail bearing their domain is not stopped by DMARC. It is worth saying plainly that SPF adoption is higher, at 73.7%, precisely because SPF is the record people set first and think of as "done." It is not the record that stops someone impersonating them to a customer or a finance team, which is the attack we described in our guide to what attackers can see about your company.

The deeper layers are barely there

Two further controls harden mail and DNS beyond the SPF-DKIM-DMARC trio, and both are rare even among the busiest domains.

DNSSEC (RFC 4033 and its companions) cryptographically signs DNS answers so a resolver can detect a forged response. We treated a domain as signed when its parent zone published a DS record. Only 13.6% did. DNSSEC underpins stronger email schemes such as DANE, so its scarcity caps how far mail security can go for most of these domains.

MTA-STS (RFC 8461) lets a domain tell sending servers to require TLS when delivering mail to it, which resists downgrade and interception between mail servers. Just 3.2% announced it. We checked only the DNS announcement (the _mta-sts TXT record) and deliberately did not fetch the policy file over HTTPS, because that would mean connecting to the domain's host, which is a line we do not cross for research.

How we measured this

A skeptic should be able to rebuild this from scratch, so here is the whole method with nothing hidden.

• The population. We used the Tranco list (list 64YYX, generated 19 July 2026), a research-oriented top-sites ranking that averages several providers over 30 days to resist day-to-day manipulation. It is published, versioned, and permanently citeable, which matters more for reproducibility than any single vendor's list. See tranco-list.eu and the underlying NDSS 2019 paper.
• The sample. The top 1,000 domains from that list. 994 resolved to live name servers; 6 did not and were dropped, so the denominator is 994.
• The lookups. For each domain, four passive DNS queries via dig against public recursive resolvers: TXT on the domain for SPF, TXT on _dmarc.<domain> for DMARC (parsing the p= tag), DS on the domain for DNSSEC, and TXT on _mta-sts.<domain> for the MTA-STS announcement.
• What we did not do. We never sent an email, opened a connection to a mail server, fetched a policy file, or scanned anything. Reading a public DNS record is a lookup, not a probe. This is the same line between a check and a crime that governs every engagement we run.
• What we kept. Aggregate counts and percentages only. Per-domain results lived in memory for the duration of the run and were never written to disk. No domain is named. No personal data was collected; domains and their DNS records are not personal data, and we gathered no email addresses.

What this does not prove

Honest limits, because a number without its caveats is marketing.

• It is a snapshot. DNS changes daily. These figures describe 20 July 2026, not a trend. A domain at p=none today may be mid-rollout and enforcing next month.
• It is DNS-only. We read published policy, not delivered mail. A large mail operator can layer defenses that DNS does not reveal. DMARC is simply the standardized public signal that receivers actually act on, which is why it is the right thing to measure at scale.
• The top of the list is not only mailing domains. A chunk of the busiest domains are CDNs, API endpoints, and infrastructure that never send interactive mail. For those, missing DMARC is a lower real-world risk, because nobody expects a message from them. It is still a gap: the recommended posture for a non-sending domain is a null MX plus DMARC reject, and an attacker can still forge mail as any domain that does not enforce.
• p=none is common for a reason. Deploying DMARC starts with monitoring so an organization can find its own legitimate senders before it starts rejecting. We count p=none as non-enforcing because, operationally, forged mail is not blocked while a domain sits there. That is a statement about the state, not a judgment about the owner.
• DMARC at the org level. The Tranco list is filtered to registered (pay-level) domains, so we checked policy where it belongs, at the organizational domain. Individual subdomains can differ.

Why an attacker cares, and why you should

Domain forgery is not exotic. An email that appears to come from a company's billing address, sent to that company's own finance person or to a customer, asking to change bank details, is one of the most reliable intrusion openers there is. No system is breached; an identity is borrowed because a DNS record was never set to reject. When 41.5% of the most trafficked domains on the internet leave that record non-enforcing, the technique keeps working because the defense is optional and often skipped.

The fix is unglamorous and mostly free. Publish SPF and DKIM, then deploy DMARC and walk it from p=none through p=quarantine to p=reject as your reports confirm your real senders. The hard part is never the DNS edit; it is knowing which of your sending sources you would break by enforcing, and being confident you have found them all. That is judgment, and it is the same judgment behind knowing which of your exposed surfaces actually matter and which are noise.

Email spoofing exposure: quick answers

What share of top domains can be spoofed by email?

In our July 2026 check of the 1,000 busiest domains (994 resolved), 41.5% published no enforcing DMARC policy, so mail forging their domain in the visible From line is not rejected or quarantined on that basis. About 29.6% had no DMARC record at all and another 11.9% published a monitor-only p=none policy.

Does having an SPF record stop email spoofing?

No, not on its own. SPF authorizes servers for the envelope sender, not the From address a person sees. Only DMARC set to quarantine or reject ties authentication to the visible From domain and tells receivers to act on failures.

Is DMARC p=none good enough?

No, not for blocking spoofing. p=none is monitor-only: receivers report but take no action, so forged mail still arrives. It is a fine first stage, but until the policy moves to quarantine or reject it does not stop impersonation.

How can I check my own domain's email authentication?

Read your own public DNS: dig TXT yourdomain.com for SPF, dig TXT _dmarc.yourdomain.com for DMARC and its p= policy, dig DS yourdomain.com for DNSSEC, and dig TXT _mta-sts.yourdomain.com for MTA-STS. These are passive lookups of records you publish, so it is safe and free.

Related reading

• How many top domains restrict who can issue their certificates? The same passive-DNS method, applied to CAA records.
• What can attackers actually see about your company?
• Check, scan, or full pentest?
• How much does a penetration test cost?