Verifying Outlook and Hotmail Addresses: What Actually Works

Outlook and Hotmail addresses can be checked over SMTP without sending, but "Microsoft" is really three different systems. Consumer Outlook.com (hotmail, live, msn) answers with 550 5.5.0 for unavailable mailboxes. Microsoft 365 with edge blocking rejects unknown recipients with 550 5.4.1. 365 behind a gateway or in hybrid mode may accept everything. Identify which one first.

Most guides lump all of these together as "Outlook", which is why advice on verifying them is so contradictory. This one starts by telling them apart, using DNS lookups we ran on 1 October 2026, and then uses Microsoft's own documentation for what each system says.

Step 1: find out which Microsoft you are talking to

The MX record tells you which system will answer, and each system answers differently. Here is what dig MX returned for a set of Microsoft-hosted domains:

Domain	MX host	System
outlook.com	outlook-com.olc.protection.outlook.com	Consumer Outlook.com
hotmail.com	hotmail-com.olc.protection.outlook.com	Consumer Outlook.com
live.com	live-com.olc.protection.outlook.com	Consumer Outlook.com
msn.com	msn-com.olc.protection.outlook.com	Consumer Outlook.com
hotmail.co.uk, outlook.fr	eur.olc.protection.outlook.com	Consumer Outlook.com (European regional domains)
microsoft.com	microsoft-com.mail.protection.outlook.com	Microsoft 365 (Exchange Online)
A company behind a security gateway	e.g. a pphosted.com host	Unknown: the gateway answers, not Microsoft

The pattern is simple. olc.protection.outlook.com means a consumer mailbox. mail.protection.outlook.com means a business tenant on Microsoft 365. Anything else, even for a company you know uses Outlook internally, means a third-party gateway sits in front and you are verifying against the gateway's rules. You can run the same lookup on any domain with the MX lookup tool.

Consumer Outlook.com, Hotmail, Live and MSN

Consumer Microsoft servers can reject unavailable mailboxes at the RCPT TO step, but the rejection is less specific than Gmail's. The reply you will see is:

550 5.5.0 Requested action not taken: mailbox unavailable

That exact text appears in bounce logs posted to Microsoft's own Q&A forum. Microsoft does not publish a reference table for its consumer service's SMTP replies in the way Google does for Gmail, so the meaning has to be read from how it behaves.

And the behaviour is the complication. In that same Q&A thread, a sender reported messages to the same Outlook.com mailboxes being delivered on some attempts and refused with 550 5.5.0 on others. Among the causes discussed was that some of the accounts were locked and required phone verification before they would receive mail.

So 550 5.5.0 from a consumer Microsoft server can mean:

• The address never existed or has been closed. Treat as invalid.
• The account exists but is locked or suspended. Real person, not reachable right now.

Compare that with Gmail, where 550 5.1.1 means "does not exist" and a separate code, 550 5.2.1, means "inactive". See how to check if a Gmail address exists. With Microsoft consumer mail, a single 550 is good evidence, and a 550 on two checks a day or more apart is strong evidence.

Hotmail addresses decay faster than most

Microsoft closes unused consumer mailboxes after one year, which makes old Hotmail-heavy lists decay quickly. Microsoft's support page on missing Outlook.com email says: "If you haven't signed in to your Outlook.com mailbox at least once in a one-year period, Microsoft will close your Outlook.com mailbox and all email will be deleted." The Microsoft Services Agreement adds that you "must sign in at least once in a two-year period to keep your Microsoft account" active.

Google's equivalent window for personal Gmail accounts is two years. A consumer list with a lot of hotmail.com and live.com addresses that has not been mailed or verified for a year or more should be re-verified before anything else happens to it. See how often to re-verify your list.

We could not find a Microsoft statement on whether a closed Outlook.com address can later be registered by someone else, so we are not making a claim either way.

Microsoft 365 business tenants

A Microsoft 365 domain that hosts all its mailboxes in the cloud rejects unknown recipients at the edge, with a documented code. The feature is called Directory-Based Edge Blocking (DBEB). Microsoft's DBEB documentation says that if an address does not exist, "the service blocks the message before filtering even occurs", and the response looks like this:

550 5.4.1 Recipient address rejected: Access denied

Microsoft's Exchange Online NDR reference describes that code in one line: "The recipient's address doesn't exist."

Two things trip people up here.

The words "Access denied" sound like a block, not a bad address. Senders see 5.4.1 ... Access denied, assume their IP has been blocklisted, and start troubleshooting reputation. For a single recipient at RCPT TO, it is an address that does not exist. A genuine reputation or policy block arrives as a different code, usually in the 5.7.x family such as 550 5.7.1.

The same 5.4.1 code has a second meaning. The NDR reference also lists 5.4.1 Relay Access Denied, meaning "The mail server that's generating the error doesn't accept mail for the recipient's domain." That points to a DNS or configuration problem on the recipient's side, not a dead mailbox. Read the text after the code, not just the number. The general 550 5.4.1 page covers both.

When Microsoft 365 accepts everything

DBEB only works when Microsoft knows every valid address, so some 365 domains accept unknown recipients and behave like catch-all. The DBEB documentation is explicit that it applies when "all recipients for your domain are in Exchange Online". During migrations, the domain is set to Internal relay instead of Authoritative, and in that mode mail for unknown addresses is passed on rather than rejected at the edge. Microsoft also notes that even with DBEB on, "There might be infrequent instances where recipient addresses that don't exist in your Microsoft 365 or Office 365 organization are allowed to relay through the service."

The same applies to companies whose MX points at a third-party security gateway. The gateway decides how to answer, and a gateway that accepts first and sorts out delivery later looks exactly like a catch-all from outside.

In both cases the result is the same as any catch-all domain: a made-up address is accepted, so no address on the domain can be confirmed. A verifier that tests a random address first will spot this and return risky.

Putting it together

What you see	System	Verdict
550 5.5.0 Requested action not taken: mailbox unavailable	Consumer Outlook.com	Invalid, but re-check before deleting a large share, because locked accounts produce it too
550 5.4.1 Recipient address rejected: Access denied	Microsoft 365 with DBEB	Invalid
550 5.4.1 Relay Access Denied	Microsoft 365, misconfigured domain	Domain problem. Risky
250 for the real address and for a random one	365 in Internal relay, or a gateway	Catch-all. Risky
250 for the real address, 550 for a random one	Either	Valid
Timeout, or a 4xx temporary reply	Either	Unknown. Retry later

Sending to Microsoft after you verify

Verification removes the dead mailboxes; Microsoft's sender rules decide whether the rest of your mail is accepted. Since 5 May 2025, Microsoft has enforced authentication for domains sending more than 5,000 messages a day to its consumer mailboxes. Its announcement requires SPF, DKIM and DMARC, says non-compliant mail will be rejected with "550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level", and lists as a best practice: "Remove invalid addresses regularly to reduce spam complaints, bounces, and wasted messages."

You can check your own domain's records with the deliverability audit. For the full set of Microsoft requirements, see Microsoft Outlook's bulk sender requirements. For why Outlook junk-folders mail that does get accepted, see why emails land in Outlook's junk folder.

Practical takeaway

1. Sort Microsoft addresses by MX into consumer (olc.protection.outlook.com), Microsoft 365 (mail.protection.outlook.com) and gateway-fronted.
2. Treat 550 5.4.1 Recipient address rejected as invalid, and do not mistake it for a block.
3. Treat a consumer 550 5.5.0 as invalid, but re-check if a large share of an otherwise good list returns it.
4. Expect some 365 and gateway domains to be catch-all, and handle them as risky.
5. Re-verify Hotmail-heavy lists after a year, because that is when Microsoft closes unused mailboxes.

To see which of these applies to a specific address, the free email checker shows the result and reason for one address at a time.