How many domains carry a Microsoft 365 tenant marker, and how many route mail there today?

The September 2026 census finds the ms verification token, the MS= record, on 8,218,984 domains, which is 4.90% of txt_present, the domains where at least one apex TXT record was observed. The same census classifies 14,697,578 domains as routing mail to Microsoft 365, which is 8.47% of domains_with_mx, the 173,425,856 domains that publish an MX record at all. Those are two measurements of two different things, taken over two different populations, and they don’t combine into one.

Two signals, two populations

A domain can say it belongs to a Microsoft 365 tenant in two places. One is a TXT record at the apex that a tenant admin pasted in once to prove ownership. The other is the MX record set that tells the rest of the internet where to deliver mail for that domain right now. They get written at different times, usually by different hands, and when one changes the other is routinely left behind.

The census counts them separately because they come from different record types with different denominators. The token count runs over txt_present: 167,692,006 domains carried at least one apex TXT record in the September 2026 edition. The MX count runs over domains_with_mx: 173,425,856 domains published MX, which is 54.78% of the 316,600,902 domains graded. A domain can sit in one population and not the other, and a domain in both can carry one signal without the other. Because the two denominators are different sets, the two percentages don’t compare with each other, and the two counts can’t be subtracted to give a third.

So the declared signal is a string in apex TXT, counted over domains that have apex TXT, and the enforced signal is a provider match on MX targets, counted over domains that have MX, which is why each line in the table further down carries its own base.

What the MS= record proves

When you add a domain to a Microsoft 365 tenant, the admin centre asks you to prove you control it. The usual route is a TXT record at the apex that looks like this:

example.com.  3600  IN  TXT  "MS=ms12345678"

The census counts the string on the left of the equals sign, lowercased, so the token in the ranked table is ms. Other Microsoft-shaped strings turn up in apex TXT, including ms-domain-verification and mscid, and each of those sits as its own row in the ranked table. None of them is folded into the ms count.

The record proves one thing: at some point somebody verified this domain against a tenant. It can’t tell you whether that tenant still exists or whether the domain is still attached to it. Nor does it say whether a mailbox was ever created there. Verification tokens don’t expire on their own. Once the wizard is done, the record stays in the zone until somebody deletes it, and there’s rarely a prompt to do so. A domain that moved to another provider three years ago can still carry the marker today, and so can a domain that was verified only to license a desktop product, or to try a trial that lapsed.

There’s also a counting rule in the census itself. A token is counted only where at least three domains in the same TLD carry it, so a tail of one-off and two-off strings in small TLDs isn’t in any of these sums. For a token this widespread that tail is small, but you should know it exists before you quote the number.

What the MX record proves

An MX record is an instruction, and receivers act on it for the next message they send. If the MX for a domain points at the provider’s own mail routing hostnames, mail for that domain lands in that provider’s infrastructure today, whatever any TXT record says. If you change the MX, delivery moves within the TTL, whereas a TXT record left behind goes unnoticed.

That’s what makes the MX classification the enforced signal. The census reads the MX set for each domain, matches the target hostnames against known provider patterns, and assigns one provider per domain. The Microsoft 365 line in that classification is 14,697,578 domains, 8.47% of domains_with_mx. The same classification puts Google Workspace at 21,565,780 domains, 12.44% of domains_with_mx, which sits on the same denominator and comes from the same edition, so the two providers can be read together.

A domain that routes through a third-party filtering gateway in front of a Microsoft 365 tenant shows the gateway’s hostnames in MX, and the census classifies it as that gateway, or as “Self-hosted / other” if the pattern is unknown. So the enforced count misses tenants that sit behind a gateway, in the same way the declared count includes tenants that no longer exist. The two errors point in opposite directions, and nothing nets them off against each other.

The two counts side by side

The ms token was seen in 822 TLDs and makes up 18.56% of token_present, the domains carrying at least one verification-style token of any kind. Read across a row and the count, the base and the share belong together. Read down the count column and you’re comparing a claim with an instruction, over two different sets of domains, and the two shapes disagree. That disagreement is what the census can show. It can’t show how much of one count lives inside the other, because the two were never measured against the same base.

Why these figures won’t match a vendor slide

Most published hosting splits come from one of two places: a provider’s own customer count, or a crawl of the top million or so sites by traffic. The census counts the registered internet, every domain the source lists produced that resolved, so it keeps the parked and dormant domains a popularity list drops, along with the one-person outfits, and that difference in base is most of why these shares sit where they do.

For the MX split it means the denominator carries the long tail of domains that publish MX for a registrar’s default mailbox or a forwarding catch-all nobody reads. Both provider shares come out lower than a survey of active businesses would report, and that’s a property of the base, which is one more reason to name it when you quote the share. For the token count it means the numerator carries domains whose owner ran a verification wizard once and then did something else with the domain, which is why a declared count from a whole-internet source drifts further from live usage than the same count taken from a list of companies you’ve already confirmed are trading.

Neither of those is a flaw to correct, because they’re the two measurements a whole-internet count can make, and each is usable as long as it travels with its base.

Reading your own zone

Pull the apex TXT and MX for your domain and look at both.

dig +short TXT example.com
dig +short MX example.com

When TXT returns an MS= string and MX points at the provider’s own routing hostnames, both signals agree and your domain sits in both counts. A marker in TXT with MX pointing somewhere else puts your domain in the declared count only: a verification somebody did once and left behind, which is also a record that tells anyone reading your zone which tenant you used to be attached to. Where MX routes to Microsoft 365 and there’s no MS= string, your domain sits in the enforced count only, which happens when the verification was done by a different method or the record was tidied up afterwards.

Run the free scan on your domain and it reads the apex TXT and the MX set, plus the records that decide whether mail claiming to be from you gets trusted, then grades the lot in one pass. The DNS pillar covers what else lives at your apex and which of it a receiver looks at, and email delivery covers what happens after a receiver picks your MX and starts checking the sender. If your MX turns out to route to Google Workspace, the default signing domain problem is the record to check next, because a default signature passes without proving anything about your domain.

Which number to cite

For “how many domains have been attached to a Microsoft 365 tenant at some point”, cite the declared count, 8,218,984, and name txt_present as the base. For “how many domains receive mail through Microsoft 365 today”, cite the enforced count, 14,697,578, and name domains_with_mx. If what you’re after is the hosting split between the two providers, cite the two MX lines together, on the one denominator they share, and say which edition they came from. Whichever you pick, quote the denominator in the same sentence, since a bare count tends to get read as a share of the whole internet when it’s only a share of the domains that carry the record.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.