A secure email gateway can mask mailbox routing. You need independent Microsoft signals to make a defensible M365 classification.
Why MX alone stops being enough
A direct Microsoft MX pointing to Microsoft mail-protection infrastructure is strong evidence of Microsoft-hosted inbound mail. Once a domain routes MX through Proofpoint, Mimecast, Hornetsecurity or another gateway, that MX identifies the front door, not necessarily the mailbox provider behind it.
Examine Microsoft Autodiscover
An Autodiscover CNAME pointing toward Microsoft-hosted endpoints can support an Exchange Online hypothesis. The record may also be stale or used in a mixed environment. Query it explicitly rather than interpreting the existence of a host named autodiscover as proof.
dig +short CNAME autodiscover.example.com
If the result is empty, account for alternate DNS configurations and errors; lack of one CNAME is not proof that Microsoft 365 is absent.
Treat Entra ID as an identity signal
Microsoft Entra ID evidence can indicate that the domain is registered or used for Microsoft identity. That does not establish that the organization delivers or stores its email in Exchange Online. Keep identity and mailbox classifications separate until further evidence agrees.
Inspect Microsoft-associated DKIM
Microsoft 365 domains can publish CNAMEs for DKIM selectors. Query both likely selectors and validate the targets against recognized patterns. A selector may persist after migration, so record it as supporting evidence rather than an automatic definitive classification.
dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.com
Assemble a transparent decision table
| Observations | Defensible statement |
|---|---|
| Direct Microsoft MX | Strong visible Microsoft mail-routing evidence |
| Gateway MX + Microsoft Autodiscover + independent DKIM clues | Likely Microsoft 365 behind gateway |
| Gateway MX + Entra ID only | Microsoft identity clue; mailbox platform unresolved |
| Gateway MX only | Backend workspace unknown |
The relative confidence depends on rule quality, observation recency and contradictory signals. Do not collapse every combination into a binary "M365 yes/no" output.
Apply it to MSP prospecting
Knowing a likely M365 backend can make gateway management, backup and identity-services outreach more relevant. Use Scan Prospects to inspect evidence on known companies, or Find Leads to explore available infrastructure filters. Only reference facts that your chosen evidence actually supports.
Worked classification example
Consider an illustrative domain with MX pointing to a recognized external gateway. That establishes the inbound provider, not the mailbox platform. You then query autodiscover and the DKIM selectors. If two independent Microsoft-specific clues agree, an output such as "Microsoft 365 likely behind gateway" may be defensible. If the only Microsoft clue is Entra ID, retain "workspace unknown" and expose the identity signal separately.
This is especially important when a provider-specific lead list is exported. A salesperson might otherwise say "we know you're on Microsoft 365" to an organization where Entra is used only for application authentication. The best data model stores the observations, the inference method and the confidence together, allowing the sales team to decide whether a claim is safe to use.
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.