The figures come from Artem Berezin’s July 30 analysis for RIPE Labs, which The Register highlighted this week. Berezin classifies the MX and SPF records of domains in the Tranco Top 1 Million using daily OpenINTEL DNS measurements. In his July 18 snapshot, Google Workspace held 21.8% of domains with detectable MX records and Microsoft 365 held 16.8%; Proofpoint, the next named provider, accounted for 1.9%.
The direction is credible, and it matches an earlier academic observation: the migration toward Microsoft and Google has been visible for years. But the headline needs a tighter reading. This is a measurement of popular domains’ advertised inbound-mail destinations, not a census of organizations, users, mailboxes, or the volume of messages handled by each provider. A single global domain can receive vastly more mail than hundreds of small domains, while a company may publish multiple MX records or run separate systems for inbound, outbound, and bulk mail.
Microsoft 365’s growing role is visible in DNS, not mailbox counts
Berezin’s method starts with public DNS records. An MX record identifies where a domain says other servers should attempt delivery. SPF identifies authorized sending infrastructure, while DMARC publishes instructions for a receiver when an email claiming to be from a domain fails authentication checks.
OpenINTEL provides a sound foundation for tracking changes in DNS over time. Its forward-DNS system measures large parts of the namespace daily and includes list-based snapshots such as Tranco’s top-ranked domains. That makes it appropriate for showing whether the same kind of domain sample moves toward or away from particular MX providers.
It does not, however, prove that Microsoft 365 and Google process 38.6% of all internet email. The RIPE Labs analysis itself describes the result as the “measured Internet,” and its methodology identifies the primary MX — the lowest-preference target — to classify a domain’s mailbox provider. That is a useful, conservative way to categorize domains, but it cannot see every backup route, downstream gateway, hybrid Exchange deployment, forwarding service, or real-world message flow.
The distinction matters operationally. A Microsoft 365 tenant with several hundred users and a multinational company with hundreds of thousands of users each contribute one or more domains to this kind of count. The study is evidence of administrative concentration: more organizations are outsourcing the responsibility for accepting mail. It is not a mail-traffic market-share audit.
Still, Microsoft’s 16.8% share in this sample is substantial. It means an outage, transport-policy change, spam-filtering adjustment, or sender-reputation decision at Microsoft can affect a large population of otherwise unrelated domains at the same time. Google’s corresponding reach compounds that dependence.
Self-hosting is losing ground because running SMTP has become an operations job
Running a Postfix, Exchange Server, Exim, or other SMTP stack is still possible. It also means accepting responsibility for patching, TLS configuration, DNS, reverse DNS, IP reputation, spam handling, authentication, abuse response, backups, continuity planning, monitoring, and incident response. Those obligations were always present; they are simply more visible as phishing and spam defenses have hardened.
Microsoft 365 and Google Workspace bundle much of that work into a managed service. For smaller IT teams, the calculation is often straightforward: the cost of maintaining a secure, deliverable mail service is harder to justify than a per-user subscription. The remaining self-hosted population is likely to be disproportionately made up of specialized operators, privacy-focused organizations, regional providers, legacy environments, and enterprises that require tighter control over routing or data.
That migration changes the burden for those who remain. Independent senders need to satisfy the authentication, DNS, reputation, and traffic-quality expectations established by the biggest receiving platforms. A technically correct mail server can still struggle with inbox placement if it sends from a new IP range, has weak domain reputation, mishandles bounces, or lacks a valid reverse-DNS configuration.
Google’s published sender rules spell out the baseline. Bulk senders — those sending more than 5,000 messages per day to Gmail accounts — must use SPF, DKIM, and DMARC; authenticate domain alignment; publish valid forward and reverse DNS; use TLS; keep spam rates below the stated threshold; and support one-click unsubscribe for marketing and subscription mail. Microsoft’s Outlook.com filtering decisions are less completely exposed, but self-hosted operators know that a clean server configuration does not guarantee good delivery.
The practical consequence is that self-hosting email has become less like deploying a web application and more like operating a small reputation-sensitive network service. The software may be free; dependable acceptance by major recipients is not.
The DMARC finding exposes a weakness in the 2024 rules
Berezin found 458,467 domains in the current sample publishing a DMARC record. Only 46.9% of those records, by his definition, enforced a meaningful policy: p=quarantine or p=reject with a 100% enforcement percentage. The most common record was the minimal v=DMARC1; p=none;, which asks receivers to monitor rather than quarantine or reject failures.
This result is often framed as proof that the 2024 Gmail and Yahoo requirements failed to produce DMARC enforcement. It is more accurate to say the requirements achieved what they explicitly demanded — widespread DMARC publication — while leaving enforcement optional.
Google’s bulk-sender guidance has always allowed a DMARC policy of p=none. Yahoo’s sender requirements likewise require bulk senders to publish a valid DMARC policy with at least p=none. Those rules were meant to establish authentication and alignment before providers imposed stronger rejection behavior on noncompliant traffic. They were never a mandate that every domain move immediately to quarantine or reject.
That is not a trivial semantic difference. A DMARC record at p=none can be a legitimate deployment stage, especially for organizations with third-party marketing platforms, ticketing systems, help desks, printers, scanners, CRM tools, and mailing lists sending under the corporate domain. Enforcing DMARC before mapping those legitimate sources can cause real mail to fail.
But p=none is supposed to be a staging point, not an endpoint. A record without a reporting address offers little evidence that the domain owner is even reviewing failures. Berezin’s criticism lands there: a large number of domains appear to have deployed DMARC to meet a checkbox requirement and stopped before turning it into an anti-spoofing control.
Microsoft 365 administrators should treat DNS as part of their security boundary
For organizations on Microsoft 365, the study is less a reason to abandon hosted email than a reason to avoid passive configuration. Moving mailboxes to Exchange Online does not automatically make every application and third-party sender compliant with the domain’s authentication policy.
Administrators should verify a few fundamentals before tightening DMARC:
- Every legitimate sending service should authenticate with DKIM where supported, including marketing, customer-support, invoicing, HR, and SaaS notification platforms.
- SPF should include only authorized senders and should be kept within DNS lookup limits rather than expanded through fragile record chains.
- DMARC aggregate reports should be collected and reviewed before moving from
p=noneto a stagedp=quarantine, then top=reject. - Domains that do not send mail should still publish a restrictive DMARC policy so they are harder to impersonate.
- Hybrid Exchange environments need particular attention, because on-premises relays, connectors, legacy line-of-business systems, and cloud services can all create authentication gaps.
A hosted mailbox provider also does not remove the need for continuity planning. If an organization’s MX points only to Microsoft 365, a Microsoft-side service incident becomes an inbound-mail dependency. That is usually an acceptable trade-off, but it should be an explicit one, with documented alternatives for urgent communications and a tested process for handling queued or delayed mail.
Email does have resilience mechanisms that Berezin’s “no graceful fallback” phrasing understates: SMTP senders normally retry temporary delivery failures for a period of time, and properly configured receiving systems can use multiple MX targets. A permanent rejection is different; it can end delivery immediately. The operational risk is therefore not that every Microsoft 365 or Google Workspace disruption makes messages vanish, but that centralized filtering and policy decisions can affect many domains simultaneously and leave senders with limited recourse.
The trend is toward fewer independent mail operators
The strongest conclusion from the RIPE Labs data is not that Microsoft and Google have somehow replaced email’s open standards. SMTP, MX, SPF, DKIM, and DMARC still provide interoperable building blocks. The change is that a shrinking share of organizations chooses to operate those building blocks itself.
That makes the policy decisions of Microsoft 365 and Google Workspace more consequential for everyone else. The companies’ authentication demands have improved resistance to impersonation and low-quality bulk mail, but they also raise the operational bar for small independent senders. As the self-hosted share contracts, the experience and infrastructure needed to remain independent become rarer — and more expensive to maintain.
For Windows and Microsoft 365 administrators, the immediate action is straightforward: treat mail authentication, sender reputation, and third-party senders as production security controls, not DNS housekeeping. The next time a business-critical message is rejected or routed to junk, the cause may be a missing record, a misaligned service, or a reputation signal — and the receiving policy increasingly belongs to Microsoft or Google.