To verify an Outlook or Microsoft 365 email address, check its syntax, domain, MX records, known risk signals, and the recipient response from the mail server. Interpret the SMTP response carefully. A Microsoft server accepting the recipient does not always prove that the individual mailbox exists.
This is mailbox verification, not Microsoft account identity verification. Mailthentic cannot tell you who owns an account or confirm that the person who supplied an address controls it. A confirmation email is still required when proof of control matters.
Outlook.com, Hotmail, Live, and Microsoft 365
outlook.com, hotmail.com, live.com, and msn.com are Microsoft consumer domains. Microsoft 365 also hosts mail for business domains. The visible business domain may not contain the word Microsoft, so an MX record lookup is the useful clue.
A Microsoft 365 MX target normally ends in mail.protection.outlook.com. A third party security gateway can sit in front of Microsoft, so provider detection from one hostname is evidence, not proof of the complete delivery path.
A practical verification workflow
- Normalize the address. Reject malformed local parts and missing domains before making network requests.
- Resolve the domain and MX. Confirm the inbound route and identify likely Microsoft infrastructure.
- Check risk signals. Keep disposable domains, role addresses, and prior bounce evidence as separate signals.
- Probe SMTP when permitted. A permanent rejection can support an invalid result. A temporary response needs a retry. An accept can remain unconfirmed.
- Use consent and engagement evidence. Double opt-in proves control. Prior delivery can help with decisions SMTP cannot resolve.
How to interpret the result
| Result | Meaning | Action |
|---|---|---|
| Deliverable confirmed | The available checks produced a strong recipient signal. | Keep it while respecting consent and suppression rules. |
| Deliverable unconfirmed | The route works, but Microsoft did not provide evidence that proves the mailbox exists. | Use acquisition source, confirmation, bounce history, and engagement. |
| Risky | A catch-all, role, or domain authentication signal needs review. | Segment it. Risky is not the same as invalid. |
| Unknown | DNS failed temporarily, SMTP was unavailable, or the server deferred the check. | Retry later. Do not turn a temporary response into a hard rejection. |
| Invalid | Syntax, domain, MX, disposable-domain data, or a clear permanent recipient response failed. | Suppress it unless the source can be corrected. |
Why an SMTP accept is not enough
SMTP moves mail. It is not a public user directory. Hosted gateways can accept a recipient at the edge and decide later. Microsoft 365 tenant settings also differ. The same 250 class response can therefore carry different information across tenants.
Mailthentic treats Microsoft-hosted recipient accepts as ambiguous unless other evidence confirms the mailbox. Repeated probing does not make an ambiguous server authoritative and can trigger throttling.
Choose the right check
Use the free email checker for a DNS-level view. It shows syntax, MX, provider, authentication, and disposable-domain signals without claiming mailbox confirmation. The Outlook provider guide covers Microsoft SMTP behavior in more depth.
For a permission-based list, use the bulk email verifier. Developers checking new records can use the email verification API. Keep unknown results for a controlled retry instead of deleting them automatically.
Source and review date
Last reviewed 2026-07-31. See Microsoft's Exchange Online DNS guidance.
Check without overstating the result
Check without sending a message
Read how to verify an address without sending email, including why Microsoft-hosted responses can remain uncertain.
Ready to verify your email list?
Start free with 50 verification credits. No credit card required.