A decade ago, publishing a DMARC record at p=reject gave you uneven protection. Major providers checked it, but enforcement across the wider mail ecosystem was inconsistent: some receivers honoured the policy as written, plenty didn’t check it at all, and a corporate mail server buried somewhere in a regional provider’s infrastructure might do something completely different from the one next to it. An attacker spoofing your domain still had somewhere to land.

That’s changed, and not because DMARC got better. The mail world got smaller instead.

But infrastructure and visibility are two different problems, and they’re moving at two different speeds. The receiving side of email has consolidated. What a security team can actually see happening on that infrastructure hasn’t kept pace.

Consolidation is real, the numbers are messy

How much smaller depends on who’s counting. Internet Society’s Pulse blog, drawing on OpenINTEL’s daily DNS scan of the Tranco top-million domains, put Google Workspace at 21.8% and Microsoft 365 at 16.8%, for a combined 38.6% of measured mailbox infrastructure in 2026. ReplyLead’s 2026 analysis of 9,058,780 domains with a usable MX record put the combined figure at 54.32%, with 6.45% sitting behind a secure email gateway and 14.8% still self-hosted.

The gap is largely a measurement problem. The two studies use different domain populations and methodologies, so neither number should be treated as a definitive share of global business email.

What they do agree on is the direction: email hosting has consolidated significantly, while self-hosted mail has declined. Internet Society’s longer view has self-hosting falling from 44.6% of domains a decade ago to 22.4% today, and the domains that left didn’t all land in the same place. Some went to Google Workspace or Microsoft 365. Others went to a different hosted provider, a secure gateway, or another cloud platform entirely.

Real consolidation, then. Just not the “virtually everyone” story the marketing decks tell.

The gateway that sits in front

Here’s the piece that gets lost in any version of the domain-count story: for the recipients an attacker actually wants to reach, a third system often makes the first call, and it’s a system whose behaviour doesn’t show up in a domain-share table at all.

Allegrow’s 2026 census of every Fortune 500 domain found 55% sitting behind a secure email gateway before the message ever reaches the underlying mailbox, with Proofpoint alone accounting for 80% of those gateways. Microsoft 365 was the mailbox platform behind 82% of the Fortune 500 domains in the study. It just wasn’t the system doing the filtering on most of them.

So “two companies decide what happens to your mail” is accurate for a lot of the addressable world: small and mid-size businesses running natively on Google Workspace or Microsoft 365, and the personal Gmail and Outlook.com inboxes both companies’ bulk sender rules explicitly target. It’s less accurate for your highest-value enterprise recipients, where the gateway in front of the mailbox is often the one setting the terms, and often the one deciding what you get to see afterwards.

Where Google and Microsoft’s rules actually bind

That first layer, the one without a gateway in front of it, is still where the enforcement teeth are, and it’s where both companies have put real deadlines behind their policies.

Google began enforcing its sender requirements in February 2024. For bulk senders, that means SPF, DKIM, and DMARC, along with additional requirements around DNS, TLS, spam rates, and unsubscribe handling.

Microsoft followed on 2 April 2025, introducing similar authentication requirements for domains sending 5,000 or more messages a day to Outlook.com and related consumer services. Non-compliant high-volume mail can be rejected with 550 5.7.515. Not a spam-folder placement. A hard rejection, generated by one of the two platforms actually receiving the mail that never passes through a gateway first.

A secure email gateway sitting in front of a mailbox isn’t a reason to skip authentication. It adds another layer of filtering, while authentication still plays its part in how the receiving infrastructure evaluates the message either way. An unauthenticated domain that might have slipped past a lenient corporate mail server a decade ago now has two separate systems checking it: whatever the gateway does with the message, and the DMARC policy the domain owner did or didn’t publish.

The blind spot underneath all of it

None of that makes the visibility any cleaner. This is where the two halves of the story actually meet.

Microsoft’s own documentation confirms that DMARC aggregate reports are sent only when a domain’s MX record points directly to Microsoft 365, rather than when a gateway or hybrid routing sits in front. Microsoft doesn’t send forensic reports. Google and Yahoo both provide DMARC aggregate reporting, but no receiver is obligated to send reports, and plenty of the long tail never will.

So what lands in your inbox never reflects every message to every recipient. It reflects whichever receivers, out of an increasingly consolidated but still incomplete set, chose to tell you what happened.

The receiving infrastructure is becoming concentrated. The visibility into that infrastructure isn’t.

Getting to reject is still the move

That incomplete picture is still better than the alternative: waiting for a complete one before doing anything. It’ll never arrive. Some receivers will always skip reporting, gateways will keep suppressing what Microsoft would otherwise send, and the long tail of smaller providers was never built to standardise.

None of that changes what p=none actually does: it gives you visibility, not enforcement. The protection against unauthorised use of your domain starts when you move to p=quarantine or p=reject, and that’s where most teams stall, because nobody wants to be the one who breaks a legitimate sender nobody remembered still existed.

DMARCS helps you identify the systems sending from your domain, see where SPF, DKIM and DMARC are failing, and move from p=none to p=reject with the visibility to do it safely.