Microsoft 365 tenant markers versus where mail actually routes

The October 2026 census finds the ms verification token, the MS= record, on 8,456,816 domains, which is 4.83% of txt_present, the domains where at least one apex TXT (Text) record was observed. The same census classifies 14,967,920 domains as routing mail to Microsoft 365, which is 8.29% of domains_with_mx, the 180,564,746 domains that publish an MX (Mail Exchange) record at all. They measure different things over different populations, so they don’t combine into one figure.

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: 174,990,877 domains carried at least one apex TXT record in this edition. The MX count runs over domains_with_mx: 180,564,746 domains published MX, which is 54.31% of the 332,492,319 domains graded or found dead. 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.

One more MX count sits alongside this one, and it helps to name it. The grade-scoring engine runs its own mx-record check, published at The MX records check: pass and fail rules, and reports 180,462,439 domains with MX, 54.3% of the same 332,492,319 domains graded or found dead. This page’s 180,564,746 counts every domain that publishes an MX record; the engine’s check counts only those whose MX also resolves, so it sits a little lower. The two come from separate passes with separate pass tests, which is why the share reads 54.31% here and 54.7% on the methodology page. Cite whichever matches the page you link, and name the base either way.

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 (Top-Level Domain) 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 (Time to Live), 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,967,920 domains, 8.29% of domains_with_mx. The same classification puts Google Workspace at 22,069,386 domains, 12.22% 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 834 TLDs and makes up 18.25% 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.

Both follow from counting the whole internet, and each count is usable when quoted 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,456,816, and name txt_present as the base. For “how many domains receive mail through Microsoft 365 today”, cite the enforced count, 14,967,920, 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 from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.