How Gmail, Outlook and Yahoo Respond to Email Verification (2026)

Every email verifier asks mail servers the same question: does this mailbox exist? The big providers answer it very differently. Gmail tells you plainly. Microsoft gives one answer for business tenants and a quite different one for Outlook.com. Yahoo mostly refuses to talk unless it trusts you. Knowing which is which explains why verification results for some providers come back clean and others come back Unknown.

What follows is what we see from InboxSure's own verification infrastructure, tested in October 2026. Providers change their behaviour without notice, so treat this as a snapshot. The SMTP replies are quoted as received; IP addresses are replaced.

Gmail and Google Workspace

Google is the most straightforward. For an address that does not exist, Gmail answers at RCPT TO with a clear, multi-line rejection:

550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. For more information, go to
550 5.1.1  https://support.google.com/mail/?p=NoSuchUser

For an address that exists, it answers 250 2.1.5 OK. Gmail itself is never catch-all, so a 250 on a gmail.com address is reliable. Google Workspace domains can be configured as catch-all by the customer, so they get the random-address probe.

What Google does do is rate limit. In our testing, the time Gmail takes to send its opening banner grows from about 1.4 seconds to around 6 seconds for an IP that has opened a few hundred connections in a short period, and connections are sometimes reset during the TLS handshake. The answers stay accurate; they just arrive slower. A verifier that opens one connection per address and spaces them out gets full results; one that hammers Gmail gets timeouts.

Microsoft 365 (business domains)

Company domains on Exchange Online, which you can spot by MX records ending in mail.protection.outlook.com, answer accurately. A missing mailbox gets:

550 5.4.1 Recipient address rejected: Access denied. For more information see https://aka.ms/EXOSmtpErrors

That wording is Microsoft's directory-based edge blocking: the tenant's directory has no such recipient, so the message is refused at the edge. An existing mailbox gets 250 2.1.5 Recipient OK. Tenants can turn on catch-all, and some do; the random probe catches those, and a well-known example at the time of writing is github.com, which accepts every address.

One wrinkle: the text "Access denied" and the link containing the word "Errors" can confuse a verifier that pattern-matches reply text for connection problems. We had exactly that bug, and the result was every Microsoft 365 address being reported deliverable. Match on the code and the stage of the conversation, not on words.

Outlook.com, Hotmail and Live

Microsoft's consumer service behaves differently from its business one. It is protective of its users and quick to block IPs it does not trust. An IP on its block list does not even get to name a recipient; the refusal comes at MAIL FROM:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please contact
your Internet service provider since part of their network is on our block
list (S3150).

This reply is identical for a real address and a fake one, because the address was never looked at. A verifier that feeds it into the normal classification gets the same wrong answer for every Outlook.com address on the list. The correct result is Unknown, and the fix is on the verifier's side: clean reverse DNS for its IP and a delisting request to Microsoft. We cover that process in why emails bounce from Outlook with 550 5.7.1.

From an IP Microsoft trusts, Outlook.com does answer at RCPT TO: a 550 with "mailbox unavailable" wording for a missing mailbox and 250 for a real one, and it is not catch-all. We cannot show that reply here because it is, by definition, only visible from an IP that is not blocked.

Yahoo and AOL

Yahoo checks the connecting server's reverse DNS before anything else. If the IP's PTR record does not resolve back to the same IP, the session ends at MAIL FROM:

550 5.7.25 Forward-confirmed reverse DNS failed

AOL shares Yahoo's mail infrastructure and answers the same way. As with Outlook.com, this is a verdict on the verifier, not the address, and should come back as Unknown. From an IP with matching forward and reverse DNS, Yahoo answers at RCPT TO like any other provider: a 5xx saying the user does not have an account for a missing mailbox, and 250 for a real one.

What a verifier should do with each

Why this matters when you choose a verifier

The difference between verifiers is rarely the syntax check or the DNS lookup; everyone does those. It is what they do when a provider will not answer. A service that reports Unknown honestly gives you a smaller deliverable list and a true one. A service that turns a block into a verdict gives you a bigger list and a bounce problem, or deletes real Yahoo contacts. When you test a verifier, include a few addresses you know are real and a few you know are fake at each of these providers, and see what comes back.

InboxSure reports any rejection that arrives before the recipient is named as Unknown, with the reason, so a provider block shows up as what it is. The mechanics of the check are in how email verification works without sending an email.