u/Ok_Philosophy_9766

Last month we posted month two of our monthly measurement of DMARC, MTA-STS, DANE and BIMI across the top million domains. In that thread someone asked a question we didn't have an answer to: how many MX servers refuse all connections that aren't encrypted?

It's a sharper question than it looks. MTA-STS and DANE are both ways for a domain to tell senders "use TLS when you deliver to me." Neither of them says anything about what happens when a sender ignores that. So this month we went and asked the servers directly.

We took all 366,215 unique MX hostnames in the top million, resolved each to an address, connected on port 25, read the EHLO capability list, and then tried to start a mail transaction in the clear.

290,230 gave a conclusive answer. Shares below are of those, not of 366,215:

• Offers STARTTLS, accepts cleartext anyway (opportunistic): 278,502, 96.0%
• Offers no STARTTLS at all: 11,135, 3.8%
• Offers STARTTLS and refuses cleartext: 593, 0.20%

Two in a thousand. Per domain it's thinner: 598 of 620,240 cleanly measured domains, 0.096%, require TLS on every one of their MX hosts.

The cross-tab is the part we think this sub will care about, and the two protocols split. Domains publishing MTA-STS at enforce enforce inbound TLS at 0.82% against a 0.096% baseline, so 8.5x. Domains publishing DANE come in at 0.12%, which is 1.2x, i.e. no signal at all. That fits: MTA-STS is still mostly something an operator switches on deliberately, while DANE is overwhelmingly inherited from a provider default, and a default says nothing about the domain that inherited it.

Either way: 99.18% of the domains publishing an enforce policy will cheerfully accept your plaintext mail. For DANE publishers it's 99.88%.

Two things about who the 598 are. We went looking for an industry pattern and mostly didn't find one, so we're not going to pretend otherwise. What we did find was geography: .de is 4.7x over-represented, .eu 3.7x, .cz 3.5x, and German-speaking Europe overall is 15.4% of the enforcers against 3.8% of mail-eligible domains. The German names skew regulated: comdirect, DZ Bank, the federal debt agency, two hospital groups, a handful of city and regional governments. Our guess is BSI TR-03108 plus GDPR practice in health and finance, but we've measured the clustering, not the cause, so take that as a hypothesis.

The other thing: 71 of the 598 are on AWS SES Mail Manager, and 13 of that product's 14 measured hostnames enforce. That's not 71 security decisions, it's one product default. The customer list gives it away: 22 of the 71 are online casinos and gambling affiliates, 36 more are SEO and content-farm domains (seven of them near-identical .live search-spam sites), and the recognizable names left are Supercell's clashroyale.com and SAP's concursolutions.com.

Meanwhile the providers carrying most of the world's mail enforce essentially nothing: 0 of 116,692 measured Microsoft 365 tenant hostnames, 0 for Google, 0 for Cloudflare, Zoho, Proton, Fastmail and Yandex. Cisco's iphmx is the only one above zero, at 22 of 2,546. Microsoft's 119,676 hostnames collapse onto 130 addresses and exactly one refuses cleartext: not a tenant endpoint and not a consumer frontend, but outlook.com itself. Looks isolated rather than the front of a rollout, since the consumer domains that would flip first all still accept plaintext. That's our September watch item.

On method, since that's usually where these threads go. The probe stops at MAIL FROM with a null sender. Never RCPT, never DATA, so it never delivers mail and never does anything resembling a sender callout. The price of that restraint is that a server enforcing TLS only at a later stage reads as opportunistic to us, so 0.20% is a floor. Unlike a DNS lookup this is answered by a mail server that can decline to talk to you at all, so the 75,985 hostnames we couldn't measure (16,113 with no address to dial, 54,940 that resolved but wouldn't hold an SMTP conversation, 4,932 that rejected us for non-TLS reasons like greylisting or IP reputation) are kept in their own buckets and excluded from the denominator rather than counted as "doesn't require TLS." Folding those in would bias the number in exactly the flattering direction, and the hosts that refuse a prober are never a random sample of the internet.

The rest of this month, briefly: DANE grew 5.18% on a same-domain basis, its fastest reading yet, and 85% of that is Strato switching on TLSA for its entire customer base (995 of its 1,001 domains in our data gained it in one month). Last month was Migadu deleting theirs. Strip both provider events out and organic DANE growth was 0.82% in July and 0.77% in August, which is the most stable number in the whole dataset. Migadu's records never came back.

Happy to get into any of it, especially the classification logic if anyone wants to poke holes in it. And thanks to @slfyst who asked the original question, it turned into the most interesting thing we measured this month.

Last month I posted the baseline for this: a monthly measurement of how the top million domains actually deploy the four standards-track email-security protocols, DMARC, MTA-STS, DANE-for-SMTP, and BIMI. This is month two, so for the first time there are month-over-month deltas. I expected the change to be the interesting part. It was, in a way I didn't predict.

DANE was the only one of the four that went down. And it wasn't operators giving up on it. One provider, Migadu, removed the TLSA records for its entire customer fleet sometime in June. Around 500 domains that had DANE in June don't in July, still pointing at the same Migadu MX hosts, just with the TLSA records gone. Nobody on those domains touched a thing, and I doubt most of them know. Take Migadu out of the numbers and DANE grew like the rest.

That turned out to be the theme of the whole month: email security moves in provider-sized blocks, not one domain at a time. ALDI Süd switched on MTA-STS for eleven of its country domains in what was clearly one change. Of the 488 domains that gained DANE, 466 got it just by moving to a mail host that publishes it by default, mostly Cloudflare Email Routing. My favorite piece of that: about 60 of those domains are low-effort throwaways that clearly never gave email security a thought, and they picked up DANE the moment they switched hosts. The provider decided, not them.

The month-over-month changes, counting only domains present in both months (more on why in a second):

DMARC valid records: +2,282, and domains tightening their policy outnumbered those loosening it 2,488 to 567

DANE: down 249 as measured, but +258 once you remove the Migadu deletions

BIMI: +346

MTA-STS valid policy: +163, with 76 domains graduating from testing to enforce against 10 going the other way

On method, because the obvious objection to a monthly top-1M study is that the list itself churns: it does, about a quarter of it turns over every month. So I only compare domains that appear in both months. I also checked whether "leaving the list" means a domain actually changed something, and it doesn't. 48,000 domains dropped off the list in June and came back in July, and 98.5% of them had the exact same mail provider across the gap. Leaving the top 1M is a popularity-ranking dip, not a provider migration. Everything else from last month still holds: unfiltered resolvers only, a second resolver in a different region has to agree before anything is recorded, and the run is paced so we never throttle anyone.

One number I keep chewing on. If the current pace held, DMARC would reach nearly every domain by the early 2030s, while the two protocols that actually secure the connection between mail servers, MTA-STS and DANE, stay on a track that runs into the 2040s and beyond. Authenticating who sent the mail is on its way to universal. Protecting how it travels is more than a decade behind it. Real adoption curves flatten near the top so I wouldn't bet on the exact years, but the gap between the two is the thing worth watching.

Happy to get into the method, that's usually where these threads go. I run an email infrastructure company and this is our own research.

[ Removed by Reddit on account of violating the content policy. ]

One of my goals is to create a community that discusses how a new version of the SMTP protocol could look like starting with its security foundation. I posted a research article at https://www.reddit.com/r/email/comments/1tw1s8e/i_measured_dmarc_mtasts_dane_and_bimi_across_the/ to show the community the state of email security and authentication for SMTP. I cross-posted it in r/DMARC and I got more traction there even though the report was not just about DMARC. Unfortunately my article got removed by the moderator of r/email. I don't want to impose what should be published there but it surfaced the need to have a technical SMTP community where I can invite people from different organizations to contribute. I tried creating the community r/SMTP but apparently that has been banned.

[removed]