A headline saying "Microsoft 365 beats Google Workspace" is meaningless unless the researcher explains how domains behind secure email gateways were classified.
Distinguish direct routing from inferred mailbox platforms
Direct Microsoft MX records and Google Workspace mail exchangers offer strong evidence of public mail routing. Some Google configurations use alternative MX patterns, and Microsoft-hosted domains can sit behind third-party secure email gateways. A study that classifies only direct MX will systematically undercount workspaces concealed by gateways.
Research status: no market-share results or sample counts are asserted here. This page defines the method needed before SecuTest publishes original comparisons from independently collected domains.
Create explicit workspace states
A practical classifier should produce microsoft, google, unknown or not_applicable with a confidence field. It should also preserve the recognized gateway as a separate observation. Do not map Entra ID alone to Microsoft 365 mail hosting; that is an identity signal and may exist in mixed environments.
| Evidence pattern | Workspace output |
|---|---|
| Validated direct Microsoft mail-protection MX | Microsoft, strong routing evidence |
| Validated direct Google mail MX | Google, strong routing evidence |
| Third-party gateway with independent Microsoft clues | Microsoft likely, evidence-based inference |
| Third-party gateway without secondary clues | Unknown |
| Entra evidence alone | Unknown for mail; identity clue retained |
Build comparison cohorts
Compare like with like. Geographic and company-size composition can alter workspace prevalence. Large enterprises may be overrepresented among gateway users; small companies may route directly. If company-size estimates are missing for many records, report that limitation instead of silently filtering them away.
Audit the detector, then calculate
Sample direct Microsoft, direct Google, inferred Microsoft and unknown classifications. Verify that the rules handle alternate published MX forms, stale Autodiscover/DKIM and partial migrations. Calculate shares using a clearly stated denominator. Preserve all exclusions and the observation window.
Do not combine an observation collected months ago with today's result and label both as current. Time alignment matters when comparing platforms.
Explain what the result would be useful for
MSPs might use a trustworthy workspace distribution to estimate addressable segments or evaluate expansion into migrations and managed services. But a detected workspace is not evidence of license count, spend, contract expiry or readiness to switch. The commercial result is more informed market selection.
Explore Find Leads for the current domain-level technology filters, or Scan Prospects when validating your own domains. A future market report should link its published methodology and dataset date, not pretend data that has not been analyzed.
Why the denominator can reverse the narrative
Imagine, purely as a mathematical illustration, that a study includes domains with recognizable direct MX as well as domains behind independent gateways. If a large enterprise-focused segment routes disproportionately through gateways, dropping those unknown backends can make one workspace appear smaller than it is. That is a sampling artifact, not evidence of market decline.
A defensible publication should therefore report direct-routing shares, inferred-backend shares and unresolved domains separately. It should also make clear that these are domain-level observations, not counts of organizations, employees, paid licenses or email users. Several domains can belong to one company, and a company can operate mixed workspaces. Transparency here is a competitive advantage, not a weakness.
Turn infrastructure signals into a qualified prospect list.
Analyze domains you already know, or find new companies that match the technologies you target. Public DNS observations support discovery, not proof of an internal security weakness.