We read the DMARC record of the 100 busiest domains that take email: 57 reject fakes, 13 only watch

Should your domain's DMARC say reject, quarantine or none? Instead of arguing about it, we read the record of the 100 busiest domains that take email. 57 tell receivers to refuse a fake. 13, outlook.com among them, only watch. Here is the table, what the big ones do that small ones skip, and where to start.

Somebody sends an invoice "from" your domain. It isn't from you. Whether Gmail lets it through, drops it in spam or refuses it depends partly on one line of text you publish: your DMARC record.

We've explained what DMARC is before. The question people actually type is narrower: which setting? Since February 2024 Gmail and Yahoo want a DMARC record from anyone who sends them a few thousand emails a day, but they only ask for p=none. So is none enough? Is reject asking for trouble?

On 28 October 2026 we looked at what the busiest domains on the internet actually chose.

How we checked

• The list: the first 300 domains of the Tranco top-sites list (list GQ3LK, downloaded that morning). Tranco ranks domains by traffic, so it is full of plumbing like CDNs and DNS services, not only brands.
• Only domains that take email: 188 of the 300 have a mail server (an MX record). We took the first 100 of those, ranks 1 to 162. The other 112 come up near the end.
• The checks: the same DNS code that runs our deep email check: MX, SPF, DMARC, and DKIM under eleven common selector names, asked of the public resolvers 1.1.1.1 and 8.8.8.8. No email was sent to anyone.
• When: 04:48 to 04:49 UTC. Records change, so this is a snapshot.

What the 100 tell receivers to do

73 of the 100 enforce something. The 14 with no record are nearly all infrastructure: CDNs, DNS hosts and registrars whose domains exist to carry traffic, not to write to people. Among names you would expect an email from, a missing record was rare. The one that surprised us was europa.eu.

The p=none group is more interesting than it looks. Microsoft's consumer domains, outlook.com, live.com and msn.com, sit at none for the main domain but set sp=quarantine, so a fake from any subdomain goes to spam. For a domain that millions of people send from, through every app and forwarder there is, that reads as a choice, not an oversight.

What the big ones agree on

• Almost everyone collects reports. 82 of the 86 records carry a rua= address for the daily summary every big receiver sends back: who sent mail in your name, from where, and whether it passed. A policy without reports is a lock nobody checks.
• Nobody half-applies it. The pct= tag lets you enforce on, say, a tenth of failing mail while you test. None of the 86 uses a number below 100. They test with p=none and reports, then switch.
• A quarter write a separate rule for subdomains. apple.com and github.com send fakes of the main domain to spam and refuse fakes from every subdomain. If your subdomains never send mail, sp=reject costs you nothing.

Reject doesn't need a strict SPF

A worry we hear: "I can't set reject, my SPF ends in a soft fail." The rejecters don't share it:

DMARC passes when either SPF or DKIM passes and matches the From domain. The record doing the enforcing is DMARC, so a soft ~all at the end of SPF is fine under a reject. google.com does exactly that.

An honest note from our side: during this test our deep check marked the nine redirect= records as "no 'all' rule at the end". That was our check being too strict: a redirect hands the whole rule to another record, which ends in its own all. We fixed it the same day, and those records now pass.

The 112 domains that never send email

The other 112 domains in the top 300 have no mail server at all. They can still be faked, because a From line is only text. Of the 112:

• 32 lock the door with two short records, v=spf1 -all (no server sends for us) and p=reject: googleapis.com, cloudfront.net, t.co, workers.dev and google-analytics.com among them.
• 56 publish neither SPF nor DMARC, so a receiver has nothing to go on.
• The other 24 have one of the two, or a policy of none.

If you own a spare domain, an old brand name or a typo of your name, these two records are the whole job:

yourspare.com.         TXT  "v=spf1 -all"
_dmarc.yourspare.com.  TXT  "v=DMARC1; p=reject"

What it means for a small domain

1. Start where the big ones started: p=none with a rua= address. That alone meets what Gmail and Yahoo ask for.
2. Read two to four weeks of reports. Every service that sends as you should show up passing: your mailbox provider, the newsletter tool, the invoicing app, the shop. Anything failing is either a forgotten tool to fix or someone faking you.
3. Move to quarantine, then reject. 73 of the 100 are there. The step they skipped, pct below 100, you can skip too.
4. Add sp=reject if no subdomain of yours sends mail, and lock every domain you own that sends nothing.

For the record, email59.com is at p=quarantine with reports today, in the same group as apple.com and amazon.com.

Reading reports without reading XML

Step 2 is where most people stop, because the reports arrive as zipped XML. Our DMARC digest gives you an address to put in rua= and turns what arrives into a short list of who sent as your domain and whether it passed. To see where a domain stands right now, run any address on it through the deep email check.

Open the DMARC digest

The short version

• Of the 100 busiest domains that take email, 57 reject fakes, 16 quarantine them, 13 only watch and 14 have no record (mostly CDNs and DNS hosts).
• 82 of the 86 records ask for reports; none enforces on only part of the mail.
• 20 of the 57 rejecters, google.com included, end SPF with a soft ~all.
• Start at none with reports, move to quarantine and reject once every sender passes, and lock the domains that never send.

Sources

• Tranco top-sites list GQ3LK (first 300 rows)
• RFC 7489, DMARC (the p, sp, pct and rua tags)
• Google, Email sender guidelines
• Yahoo, Sender best practices
• Our own measurement: one row per domain with MX, SPF, DMARC tags and DKIM selectors, 28 October 2026, 04:48 UTC.