Google Workspace vs Microsoft 365 Email

Google Workspace and Microsoft 365 together host email for the majority of businesses with a custom domain. They are also remarkably easy to tell apart — not by logging in or asking the IT team, but by reading the domain's public DNS records. Each platform stamps its own fingerprints across MX and SPF records, and once you know the patterns, you can identify either one in seconds.

Why the Distinction Matters

Knowing whether a prospect or partner runs Google or Microsoft is more than trivia. It shapes how teams approach several real workflows:

Sales. A company's email platform signals its broader stack. A Google Workspace shop is more likely to live in Chrome and use Google-native collaboration; a Microsoft 365 shop is more likely to standardise on Teams, SharePoint, and the rest of the Microsoft ecosystem. That context informs which integrations to lead with.
IT and migrations. If you are helping a client move from one platform to the other, confirming the current provider is the first step. DNS records tell you the starting point before any project work begins.
Security. Phishing analysis and incident response move faster when you know where the mail is hosted. The provider determines which postmaster tools, logs, and threat-intel feeds are relevant.
Deliverability. Each platform has its own sending infrastructure and reputation systems. When your mail to a domain bounces, the provider identity points you to the right remediation path.

MX Patterns: The Fastest Tell

MX records are the quickest way to separate the two platforms. Each uses hostnames that are unmistakably its own.

Google Workspace

Google publishes a set of MX records all ending in google.com or googlemail.com. A typical configuration includes:

aspmx.l.google.com — priority 1 (primary)
alt1.aspmx.l.google.com / alt2.aspmx.l.google.com — priority 5
aspmx2.googlemail.com / aspmx3.googlemail.com — priority 10

See any aspmx.l.google.com in the MX list and you are looking at Google Workspace. Our MX record primer covers how these priorities work in detail.

Microsoft 365

Microsoft takes a more uniform approach. Inbound mail for Microsoft 365 flows through a single Exchange Online Protection endpoint per tenant:

<tenant>.mail.protection.outlook.com — priority 0

The tenant prefix varies, but the mail.protection.outlook.com suffix is constant. Spot that suffix and you have confirmed Microsoft 365.

SPF Patterns: The Corroborating Signal

SPF records describe which servers are allowed to send on behalf of the domain. They usually contain an include: mechanism that names the provider's SPF range, which makes them a reliable second signal.

Google Workspace

A Google SPF record typically looks like:

v=spf1 include:_spf.google.com ~all

The _spf.google.com include is the giveaway.

Microsoft 365

Microsoft 365 SPF records usually read:

v=spf1 include:spf.protection.outlook.com ~all

Here the spf.protection.outlook.com include is the fingerprint. When MX and SPF agree, the identification is certain. When they diverge, you are likely looking at a hybrid or forwarding setup — see the gotchas section below.

Side-by-Side Cheat Sheet

MX tell (Google): hostnames ending in google.com / googlemail.com
MX tell (Microsoft): hostname ending in mail.protection.outlook.com
SPF tell (Google): include:_spf.google.com
SPF tell (Microsoft): include:spf.protection.outlook.com
Verification (Google): google-site-verification= TXT token
Verification (Microsoft): MS= TXT token at the apex

For the broader context of how these records are queried and matched, how email domain lookup works walks through the full pipeline.

What It Means for Sales and IT

For sales teams, the platform split is a segmentation signal. You can filter a prospect list by provider before outreach, tailoring messaging to the ecosystem each prospect actually uses. The Email Provider Filter does exactly this in bulk — upload your list, get the provider for each domain, and segment from there.

For IT teams, the distinction matters during migrations, acquisitions, and security reviews. Confirming the current platform from DNS means you start with facts rather than assumptions, and you can spot hybrid or legacy configurations before they surprise you mid-project. The Provider Lookup page is ideal for verifying a single domain during an assessment.

Gotchas: Hybrids, Forwarders, and Legacies

Hybrid Exchange. Some organisations run on-premises Exchange alongside Microsoft 365. You may see both an outlook.com protection host and a self-hosted MX, or mail-flow connectors that blur the line. Treat these as “Microsoft 365 hybrid” rather than a clean either/or.
Email forwarding. A domain's MX may point to a registrar or forwarding service that then relays to Google or Microsoft. The forwarding host shows up first; check SPF and verification tokens to find the real provider.
Stale records after migration. Right after a switch, old MX or SPF records can linger until their TTLs expire. If the signals conflict, re-check after the TTL window passes.
Third-party senders. A domain may include a marketing or transactional sender (Mailchimp, SendGrid) in SPF alongside the platform include. That is normal and does not change the platform identification.

The Bottom Line

Google Workspace and Microsoft 365 leave clear, public fingerprints in MX and SPF records. Google announces itself through aspmx.l.google.com and _spf.google.com; Microsoft through mail.protection.outlook.com and spf.protection.outlook.com. Read those two records and you can place almost any business domain on the right side of the divide — and when you need to do it for a whole list, the Email Provider Filter handles the matching for you. For a step-by-step version of the same logic, see how to find the email provider behind a domain.