# Microsoft 365, Outlook.com and Exchange Online: MX records and email verification

How Microsoft-hosted domains look in DNS, why many Microsoft 365 tenants answer as catch-all, and which verdicts to expect for Outlook and Exchange addresses.

Updated: 2026-09-03

Microsoft runs two very different mail services on one inbound platform: consumer Outlook.com (with the older hotmail.com, live.com and msn.com domains) and Exchange Online, the mail service behind Microsoft 365 for companies. Spaw reports both as `mx_provider: "microsoft"`.

## How Microsoft shows up in DNS

Exchange Online tenants publish a single MX record shaped like `contoso-com.mail.protection.outlook.com`: the customer's domain with the dots replaced by dashes, under `mail.protection.outlook.com`. Consumer domains use the sibling `olc.protection.outlook.com` zone, for example `outlook-com.olc.protection.outlook.com`. Microsoft has begun rolling out a second naming scheme under `.mx.microsoft`, which Spaw matches as well.

Microsoft is a mailbox host, but the MX target is the Exchange Online Protection edge, a filtering layer that sits in front of every tenant's mailboxes. That edge, not the mailbox server, answers the SMTP handshake, and its behaviour depends on how the tenant is configured.

## How Microsoft answers a verification handshake

Consumer Outlook.com addresses are answered like Gmail: an unknown username is rejected at `RCPT TO`, an existing one is accepted.

Exchange Online tenants are the complicated case. Microsoft documents Directory-Based Edge Blocking, which rejects messages to recipients that are not in the tenant's directory at the network perimeter with `550 5.4.1 Recipient address rejected: Access denied`. It is in effect automatically when every recipient of the domain lives in Exchange Online. When a domain is set to Internal Relay instead, which is common during migrations and in hybrid setups with on-premises Exchange, the edge accepts every recipient and sorts the invalid ones out later with a bounce. From the outside that tenant is a catch-all, and it is a frequent configuration.

## What that means for your verdicts

Expect three patterns. Tenants with edge blocking answer cleanly: `deliverable` with `mailbox_exists: true`, or `undeliverable` with `reason: mailbox_not_found` and `smtp_reason: no_mailbox`. Internal-relay and hybrid tenants answer `risky` with `reason: catch_all`; Spaw remembers the domain as catch-all for seven days, spends no further probes on it, and returns `mailbox_confidence` instead, which for a Microsoft domain starts with the ten-point bonus for an established provider and then moves with DMARC, SPF, the shape of the username and your own delivery feedback. Disabled or de-licensed accounts commonly answer as missing, so a departed employee shows up as `mailbox_not_found` rather than `mailbox_disabled`.

For the consumer domains (outlook.com and its country variants, hotmail.com, live.com, msn.com), Microsoft's own username rules apply before any probe: letters, digits, dots, underscores and hyphens, at most 64 characters. Anything else is `undeliverable` with `reason: invalid_local_part` and costs nothing.

## SPF and DMARC at Microsoft

Microsoft's documentation for custom domains in Microsoft 365 is `v=spf1 include:spf.protection.outlook.com -all`, with separate includes for the government and 21Vianet clouds, and it recommends the hard-fail form together with DKIM and DMARC. Spaw shows the live result in `has_spf` and `dmarc_policy`; a company domain without SPF adds ten risk points to every address on it. Consumer Outlook.com users have nothing to configure.

## Practical notes for sending to Microsoft users

Because catch-all is so common on Microsoft 365, a list of business addresses often comes back with more `risky` answers than a list of consumer ones. That is not a defect of the list; it is the tenant declining to say which mailboxes exist. Use `mailbox_confidence` to rank those addresses, and report delivery outcomes back through the feedback endpoint: after a delivered report, later lookups of the same address answer `smtp_reason: delivered_recently` with a confirmed mailbox, and bounces lower the confidence for the whole domain. Plus-addressing works on Outlook.com and Exchange Online, and Spaw reports it as `is_alias: true`.

For a live look at any Microsoft-hosted domain, run it through the free MX lookup and the SPF and DMARC checker.

Reference: https://spaw.co/email-providers/microsoft