If you have been running cold outreach in 2025 or 2026 and your bounce rates suddenly jumped from 1% to 5-7% despite using a "premium" verification tool, this post is for you.

The short version: most email verification APIs cannot reliably verify Microsoft 365 / Outlook mailboxes anymore, but they will not tell you that. Instead, they return valid or catch_all and let you find out at send-time. This post is about why that happens and what you can actually do about it.

I run cold email infrastructure at scale. We send around 1.6M emails per day for ourselves and process roughly 6-7M for clients. When bounce rates on Outlook-heavy lists started climbing across multiple providers we use, I went down a rabbit hole. What I found is technically simple and structurally embarrassing for the verification industry.

How SMTP-based email verification is supposed to work

Email verification without sending is not magic. The standard technique has been the same since the SMTP RFCs:

1. Resolve the MX records for the domain
2. Open a TCP connection to the mail server on port 25
3. Send HELO to identify yourself
4. Send MAIL FROM: with a verification sender
5. Send RCPT TO: with the email being verified
6. Read the response code

A clean exchange looks like this:

S: 220 mx.example.com ESMTP ready
C: HELO verifier.example
S: 250 mx.example.com Hello verifier.example
C: MAIL FROM: <verify@verifier.example>
S: 250 OK
C: RCPT TO: <real-mailbox@example.com>
S: 250 Accepted
C: QUIT

A 250 response on RCPT TO traditionally meant "yes, this mailbox exists and I will accept mail for it." A 550 meant "no such mailbox." This is what every email verification tool was built on. The server told you the truth, no email got delivered, and you walked away with a confident yes/no answer.

That contract is broken on the largest mailbox provider in B2B.

What changed with Microsoft 365 and Outlook

Microsoft's mail infrastructure no longer reveals mailbox existence at the SMTP layer in the way smaller mail servers do. There are two technical reasons for this, both well-documented in Microsoft's own materials.

Reason one: anti-abuse by design. Microsoft Exchange Online does not validate recipients during the RCPT TO phase the way classical SMTP servers do. By default, Exchange accepts the recipient with 250 OK and only checks whether the mailbox actually exists later in the pipeline, often after DATA. From Microsoft's own documentation describing Exchange behavior: invalid recipients can get a 250 OK response unless an administrator explicitly enables Directory Based Edge Blocking (DBEB). DBEB is opt-in, not the default, and many tenants never turn it on.

Reason two: enumeration protection. Microsoft and Google both treat RCPT TO enumeration as a hostile pattern. If you connect from an unfamiliar IP and start probing addresses, the server returns generic responses precisely so you cannot distinguish real mailboxes from fake ones. This is good security and bad news for verifiers.

The consequence is that when a verifier sends RCPT TO: <random-string-12345@somecompany.com> to an Office 365 tenant, the server is very likely to answer 250 whether or not the mailbox exists. That is not a bug. That is the system protecting itself.

Why this matters for your bounce rate

Microsoft 365 is roughly 50-70% of B2B mailboxes depending on the segment. If your verifier cannot reliably distinguish a real Outlook mailbox from a fake one, half your verified list is essentially unverified. You will not see this as unknown results. You will see it as one of two things:

• The verifier marks Outlook addresses as valid because the SMTP server said 250. You send. Some bounce. Your reputation tanks.
• The verifier marks every Outlook tenant as catch_all because it is technically true that the server accepts everything. You skip these emails. You lose 60% of your TAM.

Both behaviors look fine on the verifier's dashboard. Your bounce rate looks fine until it does not. The verifier has plausible deniability because catch-all and valid are both legitimate SMTP states.

What honest verification looks like

There is no single SMTP trick that fixes this. Working around Microsoft's protections requires a stack of techniques, none of which are cheap to build:

Distributed source IPs with rotation. Microsoft's response varies based on the reputation of the IP making the request. A single egress IP burns out fast. Verifying at scale requires a pool of warm IPs rotating across requests, otherwise responses degrade to "always 250" within hours.

Multi-port and multi-protocol probing. Port 25 is only one signal. Cross-checking against domain-level signals (MX configuration, autodiscovery records, tenant-level metadata) and behavioral signals (response timing, error code variation, follow-up bounces) gives a much higher-confidence answer than a single SMTP transaction.

Catch-all classification, not catch-all dismissal. A real verifier should distinguish between domains that genuinely accept all mail (small business catch-alls) and Microsoft 365 tenants that appear to be catch-all because of enumeration protection. These require completely different downstream handling and most tools collapse them into one bucket.

Honest unknown responses. When a verifier cannot make a high-confidence call, the correct answer is unknown with the reason exposed. Not valid. Not catch_all. The number of tools that will return unknown to a paying customer is approximately zero, because customers interpret unknown as the tool failing.

If you build verification yourself, this is the architecture you need. If you buy verification, this is what you should be asking your vendor about.

How to test your current verifier in 5 minutes

This is the test I run before trusting any new verification tool. It takes about five minutes and a few cents in credits.

1. Pick a known Microsoft 365 domain you control or have permission to test against. Confirm via dig MX yourdomain.com that it resolves to *.mail.protection.outlook.com.
2. Generate 20 obviously fake addresses at that domain: qwertyrandom1@yourdomain.com, nonexistent_xyz_2026@yourdomain.com, and so on.
3. Mix them with 10 real mailboxes from the same domain.
4. Submit all 30 to your verifier.

Now look at the results. If your verifier marks the 20 fake addresses as valid, it is lying. If it marks the entire domain as catch_all and refuses to verify the 10 real addresses, it has given up. Either way, you now know what you are paying for.

A verifier that handles Microsoft correctly will return valid for the real mailboxes, invalid or unknown for the fakes (with a clear reason), and never claim to be 100% confident about the entire domain just because the SMTP server is hiding behind enumeration protection.

You can also do this with Gmail Workspace domains. The behavior is similar but generally less aggressive than Microsoft's.

What this means if you are building infrastructure

If you are a developer who needs email verification as part of a signup flow, CRM cleanup, or outreach pipeline, three things matter:

Treat verifier output as probabilistic, not boolean. Even with the best implementation, a valid on Outlook is more like "85% confident" than "yes." Build retry and bounce-handling logic that assumes some percentage of valid will still bounce. If you treat the API response as ground truth, you will eventually destroy a sender reputation.

Audit your verifier's actual behavior, not its marketing copy. Run the test above on your current tool. Run it again every few months. Verifiers degrade silently, and accuracy claims on landing pages are not audited by anyone.

Push providers to expose unknown. A vendor that admits uncertainty is more useful than one that fabricates confidence. If your tool only returns valid, invalid, and catch_all, with no way to express "I tried and could not tell," it is a worse product than one that does.

This is also why we built our own verification platform after burning through every commercial option. The tool is called EmailShield (emailshield.co) and it returns honest unknown results when the SMTP layer cannot give a high-confidence answer, including a reason code. It is currently in public beta with 40K free credits if you want to run the test above on it. No affiliate, no paywall to test, just the tool we wished existed.

Closing

Email verification is one of those infrastructure layers that is invisible until it fails, and when it fails it fails by silently inflating your bounce rate while every dashboard you look at says "list is clean." The Microsoft 365 problem is not new. It has been quietly worsening for two years. Most of the industry has chosen to paper over it because returning unknown looks bad on a sales call.

If you are building anything that touches cold email, transactional email, or signup validation in 2026, you need to understand that SMTP verification has become a probabilistic signal, not a deterministic one, and your tooling needs to reflect that.

Test your verifier this week. You will probably be unhappy with what you find.

If you found this useful and want more posts on email infrastructure, deliverability internals, and the gap between what cold email tools claim and what they actually do, follow me here.