Email security maturity

DMARC deep-dive representative

DMARC (Domain-based Message Authentication, Reporting & Conformance) lets a domain owner declare a policy — none, quarantine, or reject — for handling messages that fail SPF/DKIM alignment, plus an address to receive aggregate XML reports. Among the 458,388 domains with a valid `v=DMARC1` TXT, 43.8% are in monitor-only (p=none) mode, 24.1% quarantine, 23.9% reject, and 9.3% are syntactically invalid (missing `p=` tag or unknown value). An additional layer of nuance is `pct=`, which throttles enforcement to a fraction of mail; only 20.4% of records explicitly state `pct=100` — most either inherit the 100 default or apply a partial roll-out. The `sp=` subdomain policy is set explicitly on 17.8% of records; the rest inherit the parent `p=`. Aggregate reports (`rua=`) point at 31 distinct reporting endpoints; we classify the top 20 commercial DMARC services covering 325,225 domains.

MTA-STS adoption limited data

MTA-STS (RFC 8461) lets a domain advertise a policy file via HTTPS that mandates TLS for inbound SMTP connections. Discovery uses a TXT record at `_mta-sts.<domain>` containing `v=STSv1; id=<token>;`. Adoption requires three coordinated artefacts: the discovery TXT, a `mta-sts.<domain>` HTTPS endpoint serving the policy, and an MX-set with TLS certificates that match the policy `mx:` patterns. Because OpenINTEL Tranco does not query the `_mta-sts.<domain>` label, we cannot measure true adoption from this dataset. The 62 domains shown here are anomalous: they publish `v=STSv1` at the apex TXT, where no consuming MTA will discover it. They appear because of wildcard records, copy-paste mistakes, or operators who confused the discovery label with the apex. Treat this number as a lower bound on misconfiguration, not an upper bound on adoption. A follow-up scan that resolves `_mta-sts.<domain>` directly would be needed to publish accurate adoption percentages.

BIMI adoption limited data

BIMI (Brand Indicators for Message Identification) lets a domain advertise a brand logo, optionally backed by a Verified Mark Certificate, that supporting mailbox providers (Gmail, Yahoo, Apple Mail, Fastmail, etc.) display next to authenticated messages. Discovery uses a TXT record at `default._bimi.<domain>` (or a named selector) containing `v=BIMI1; l=<svg-url>; a=<vmc-url>`. Because OpenINTEL Tranco does not query the `default._bimi.<domain>` label, the 356 records visible here are apex-misconfigured — they live at the bare domain TXT where no consuming MTA will look. Among these mis-published records, the most common logo hosts are Entrust's BIMI service and DigiCert's VMC pipeline, indicating operators who already paid for a Verified Mark Certificate but missed the discovery-label step. Treating this as a lower bound on 'people who tried BIMI', the larger truth — what fraction of the Tranco top-1M actually serves a usable BIMI record — needs a targeted DNS sweep we have not yet wired in.

TLS-RPT adoption limited data

TLS-RPT (SMTP TLS Reporting, RFC 8460) lets a domain receive daily JSON reports about TLS-negotiation failures from sending MTAs. Discovery uses a TXT record at `_smtp._tls.<domain>` containing `v=TLSRPTv1; rua=mailto:…`. It is typically deployed alongside MTA-STS (or DANE) to gain feedback on policy enforcement. Because OpenINTEL Tranco does not query the `_smtp._tls.<domain>` label, the 73 records visible here are apex-misconfigured and represent a lower bound on misconfiguration rather than an upper bound on adoption. The few correctly-classified `rua=` reporters we can extract from those records still demonstrate which TLS-RPT services are gaining traction — UK government's NCSC mailcheck service and dmarcian's TLS endpoint show up most often, alongside self-hosted endpoints at the domain's own `smtp-tls-reports@` alias. A targeted sweep of the standard `_smtp._tls.<d>` label would yield true adoption figures.

DKIM selector portfolio data unavailable

DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to outgoing mail. Verifiers fetch the public key via DNS at `<selector>._domainkey.<domain>`. Each sender (mailbox provider, ESP, transactional service, marketing platform) chooses its own selector name — Google Workspace uses `google._domainkey`, Microsoft 365 uses `selector1` / `selector2`, SendGrid uses `s1` / `s2`, Mailgun uses `k1` / `k2` / `k3`, Mailchimp uses `k1`, Zoho uses `zoho` / `zmail`, Fastmail uses `fm1` / `fm2` / `fm3`, MimeCast uses `mimecast`, Cisco uses `cisco`, and so on across hundreds of vendor-specific patterns. OpenINTEL Tranco does not enumerate these selector subdomains, so we cannot build a selector portfolio from the current dataset. A follow-up batch DNS scan over a curated 200-selector list per MX-domain would reconstruct the senders an organisation has configured to sign on its behalf — effectively an attribution layer that complements the SPF `include:` portfolio we already report on the SaaS senders page.

Not yet measured. The OpenINTEL Tranco snapshot does not enumerate <selector>._domainkey.<domain> labels. A targeted DNS sweep over a 200-selector candidate list per MX-domain is planned as a follow-up to populate this section.