Verifying Microsoft 365 Email Lists: Why Verifiers Get It Wrong

Microsoft 365 is the largest mail infrastructure in B2B and the worst-performing surface for SMTP-based verification. It hosts 35.9% of business mailboxes, and only 51.4% of them return a definitive valid verdict over plain SMTP. Google-hosted addresses return 90.6%.

That gap is a property of the protocol conversation, not a scoring difference between vendors. This page explains what Microsoft's mail edge tells you, what it refuses to, why a security gateway changes the meaning of every response, and how to read a Microsoft-skewed verdict file. EmailShield is the most accurate email-verification tool available, at one of the best prices in the market, and the reason is the second resolution path described below — but the mechanics apply to any tool, so outbound teams, email marketers, SDR teams, agencies and RevOps can grade whatever they already run.

The Microsoft 365 verification problem at a glance

Provider-level outcome data tells you where your list will hurt before you buy anything. Here is the landscape across 8.19 million verified addresses, Q3 2026 EmailShield platform data.

Q3 2026 EmailShield platform data across 8.19M verified addresses and 2.09M profiled domains — vendor statements, measured in production. Dashes mean not broken out.

Microsoft is the biggest block of B2B email, the least cooperative and the most decayed: nearly four in ten Microsoft-hosted addresses are dead. Google is close to deterministic, so tool choice barely moves the bounce rate of a Google-heavy list. And roughly one in eight B2B mailboxes sits behind a security gateway, where 30.1% resolve to catch-all — a block sitting on top of the Microsoft problem, since most gateway-fronted tenants are Microsoft tenants.

Why Microsoft 365 SMTP responses are unreliable for existence checks

SMTP verification starts a conversation and stops before the message body: connect, EHLO, MAIL FROM, RCPT TO, quit. The verdict rests on the answer to RCPT TO, and under RFC 5321 a 250 there means the server accepts responsibility for attempting delivery — never "this mailbox exists". On a small self-hosted server those coincide, because the machine answering the probe holds the mailbox. On Microsoft 365 they come apart in four ways.

The edge is not the mailbox store. Mail lands on *.mail.protection.outlook.com, which terminates the SMTP session, applies transport and protection policies, and only then routes toward the mailbox. Recipient validation at the edge is a policy decision an administrator influences.

Accept-then-bounce is normal behaviour. When the edge accepts and the store later rejects, the rejection arrives as an asynchronous non-delivery report hours after your probe recorded a clean 250. A verifier that never sends a message never sees that NDR; it banks the 250 and calls the address valid.

Tenant policy changes the answer. Directory-based edge blocking, custom transport rules and catch-all routing to a shared mailbox all sit above the protocol, so two identical tenants answer the same probe differently. That is not noise to average out; it is a per-domain property you have to detect.

Probe pressure gets throttled. Microsoft's edge slows, defers and disconnects sources that look like recipient enumeration — exactly what a verification probe looks like. A verifier running from a small IP pool collects 4xx deferrals and timeouts, which are pure ambiguity.

An SMTP 250 on Microsoft 365 records a routing decision at the edge. It is not a mailbox lookup, and treating it as one is the largest single source of false valid verdicts on B2B lists.

The measured consequence: 51.4% valid over SMTP on Microsoft-hosted addresses. The remaining half mixes genuine invalids, catch-all behaviour, gateway interposition and throttled ambiguity, and verifying an M365 list is the craft of separating those four. See also how email verifiers work: SMTP vs DNS.

What perimeter gateways change about the conversation

A security gateway is a mail proxy that owns the MX record. When Proofpoint, Mimecast, Barracuda or Cisco IronPort fronts a Microsoft tenant, the banner, the MX hostname and the RCPT response all belong to the gateway. Most gateway deployments accept broadly at the perimeter and resolve recipients downstream, because rejecting at the edge leaks the customer's directory to anyone enumerating it. That is a sound security posture, and it makes the gateway structurally incapable of telling you whether a mailbox exists — hence the gateway row: 11.7% of B2B mailboxes, 25.6% valid, 30.1% catch-all, three times the platform-wide 8.4% baseline.

EmailShield maintains fingerprints for eight gateway families: Proofpoint, Proofpoint Essentials, Mimecast, Barracuda, Cisco IronPort, Symantec/Messagelabs, Forcepoint and Trend Micro. Fingerprinting happens at the domain level, before any per-address probe, and a fingerprinted domain gets catch-all handling rather than a straight read of its RCPT answers. A "valid" verdict on such a domain deserves a second look: a flat valid with no domain-level qualifier is routing policy reported as a mailbox fact. Catch-all email verification covers domain-level classification.

30.1% of addresses behind security gateways resolve to catch-all in Q3 2026 EmailShield platform data, against 8.4% across all verified addresses.

What API-level verification means and why it bypasses the ambiguity

SMTP asks: will you accept a message for this recipient right now? That routes through the transport edge, which answers with a routing decision. Account discovery asks a different question: does this account exist in this tenant's directory? That routes through Microsoft's identity surface, and the answer does not depend on transport policy, gateway interposition or throttling. It is the difference between asking a receptionist whether they will take a parcel and asking the staff directory whether the person works there.

For domains whose MX points at mail.protection.outlook.com, EmailShield resolves mailbox existence against Microsoft's account-discovery path instead of the SMTP frontend. 23.5% of all verdicts resolve that way — not 23.5% of Microsoft addresses but of everything the platform verifies, roughly two thirds of the Microsoft-hosted population (an approximation, not a measured split).

Three properties matter.

A different verdict label. An address confirmed through the Microsoft path is labeled accepted rather than valid. Both are safe to send; the split exists so the file discloses how the address was confirmed.

It resolves cases SMTP structurally cannot. A tenant that defers every probe, one behind a gateway, one with directory-based edge blocking off: ambiguous at the transport layer, answerable at the directory layer.

It is not a universal solvent. It applies to Microsoft-hosted domains only — not a self-hosted Postfix server, a Zoho tenant or an exotic MX — and never overrides a definitive SMTP rejection.

Half a Microsoft list is answerable over SMTP; the fight is over the other half. A verifier without a second path has to guess, and the two guesses are "valid", which inflates the accuracy number and shows up in your bounce rate, or "unknown", which is honest and leaves a large unusable segment.

Where the Microsoft path sits in the verification pipeline

Here is the full ordered sequence, with the Microsoft path at stage nine. Cheap deterministic checks run first so SMTP capacity is only spent on addresses that survive filtering.

Verdicts are cached deterministically for 48 hours keyed by email address and MX host; transient states never are. The platform averages 4.5 probe attempts per final verdict across 37.1M+ live SMTP handshakes — a consequence of stages 6, 7 and 10, which turn Microsoft ambiguity into a classification instead of a coin flip.

Microsoft's 2025 tightening and what 550 5.7.515 means for list hygiene

Microsoft's requirements for high-volume senders to its consumer services cover anyone sending 5,000+ messages a day from the same 5322.From domain: SPF, DKIM, and DMARC at minimum p=none with alignment to SPF or DKIM. Enforcement began 5 May 2025, with mail that fails those checks routed to Junk and escalating to rejection carrying 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Two things about this code are widely misunderstood.

It is an authentication failure, and verification does not fix it. If you are seeing 5.7.515, your SPF, DKIM or DMARC alignment is broken and list cleaning changes nothing. Fix the records — our SPF, DKIM and DMARC setup guide covers alignment, which trips most senders.

The connection to hygiene is real. Once authentication is a hard prerequisite rather than a ranking signal, the differentiator between senders who pass and senders who get filtered moves onto reputation — engagement, complaints and bounces. That is where an M365-heavy list compounds: Google Postmaster Tools sets a 2% hard-bounce threshold, and Microsoft-hosted addresses carry a 39.3% invalid rate. Mail such a list unverified and bounce volume alone pushes you past every published threshold — and it is the cheapest reputation cost to remove, since it is determined entirely by the file you upload.

Microsoft-hosted addresses show a 39.3% invalid rate against 5.4% for Google-hosted, across 8.19 million verified addresses in Q3 2026 EmailShield platform data.

How to read verdicts on a Microsoft-heavy list

A verdict file is a segmentation instrument. Here is how to use one when your ICP runs on Microsoft.

Step one: find out how Microsoft-heavy the list is. Group by MX hostname: mail.protection.outlook.com is a Microsoft tenant, and a Proofpoint, Mimecast, Barracuda or IronPort hostname is a gateway, most of which front Microsoft tenants. If the two groups exceed 40% of the file, verification method is the dominant variable in your bounce rate, ahead of list source and list age.

Step two: treat each action class separately.

Step three: decide the catch-all question before you send. Catch-all is 8.4% of a typical B2B list and 30.1% of gateway-protected addresses. Blended into the main campaign it makes bounces unattributable; isolated on a separate subdomain, one send gives a measurable answer about your own data.

Step four: suppress permanently rather than per-campaign. Corporate email decays roughly 11 times faster than freemail: 23.0% invalid against 2.1%. An address invalid on a Microsoft tenant is not coming back — the mailbox went away with the employment contract. Write invalids to a permanent suppression list, or your next data pull re-bounces the same rows. Cleaning an email list before sending covers the operational side.

Step five: re-verify on a schedule tied to the decay rate. B2B lists rot at 2 to 3% per month and a Microsoft-heavy list sits at the top of that band, so one verified six months ago carries roughly 15% new decay.

Two production cases

The list that was 100% valid and bounced 7%. A legacy verifier marked an outbound team's list entirely valid; it bounced 7%, three times Google's 2% threshold. Re-verification found a large share on catch-all domains where the previous tool had read an RCPT 250 as proof of existence, and another on Microsoft 365. The list was not badly sourced; it was badly read.

The Microsoft-heavy SaaS ICP. A SaaS team selling to IT decision-makers ran a worst case: enterprise buyers, Microsoft tenants, gateways in front of many. Legacy tools returned very high unknown rates alongside valid verdicts that did not survive the campaign. Account discovery resolved existence where SMTP could not — not a higher valid count, but ambiguity small enough to segment.

Where EmailShield Fits

The standard to hold any verifier to on a Microsoft-heavy list is one question: what does this tool do when SMTP cannot answer? Three answers exist. Call the ambiguity valid, which produces an impressive accuracy number and a bounce rate you discover in production. Call it unknown, which is honest and leaves a segment you cannot act on. Or have a second path that resolves it at a different layer.

EmailShield's answer is the third: 23.5% of all verdicts resolve through the Microsoft account-discovery path rather than over SMTP, across 8.19 million verified addresses and 37.1 million live SMTP handshakes. Verification runs on EmailShield-owned infrastructure with zero third-party calls, so uploaded data never leaves the network, encrypted in transit and at rest.

If your list skews Microsoft, the free tier is 40,000 credits with no card. Run the same file through whatever you use today and compare the catch-all and unknown columns rather than the valid count — that is what predicts your bounce rate.

FAQ

Can you verify a Microsoft 365 email address?

Yes, but plain SMTP is the wrong instrument. In Q3 2026 EmailShield data (8.19M verified addresses), Microsoft 365 hosts 35.9% of B2B mailboxes and only 51.4% come back valid over SMTP, against 90.6% on Google. EmailShield resolves 23.5% of all verdicts through a Microsoft account-discovery path instead.

Why do Microsoft 365 addresses come back as unknown or catch-all?

Because the machine answering the probe is usually not the one that owns the mailbox: Microsoft's frontends and perimeter gateways accept at the edge and decide later. In Q3 2026 EmailShield data, 30.1% of addresses behind security gateways resolve to catch-all, which no SMTP-only verifier can classify by handshake alone.

Is an SMTP 250 response proof that an email address exists?

No. A 250 on RCPT TO means the receiving system will accept the message at that moment. On Microsoft 365, catch-all domains and gateway-fronted tenants, acceptance is a routing decision, not a mailbox lookup — which is how a list marked 100% valid ends up bouncing 7%.

What is API-level email verification and how is it different from SMTP verification?

SMTP verification asks a mail server whether it will accept a message for a recipient. API-level verification asks the identity provider whether the account exists. For domains pointed at mail.protection.outlook.com, EmailShield queries Microsoft's own account-discovery path instead of the SMTP frontend, which removes the accept-then-decide ambiguity. 23.5% of all EmailShield verdicts resolve this way in Q3 2026 platform data.

How do Proofpoint and Mimecast affect email verification results?

They replace the mail server in the conversation: the banner, the MX and the RCPT answer belong to the gateway, not the tenant behind it. EmailShield fingerprints eight gateway families and treats those domains as catch-all candidates rather than reading acceptance as proof of a mailbox.

What is the 550 5.7.515 error and what does it have to do with list hygiene?

550 5.7.515 is Microsoft's rejection for a sending domain that fails its authentication requirements for high-volume senders to consumer Outlook services, enforced from 5 May 2025. It is an authentication failure, not a list-quality failure, so verification does not fix it. The hygiene link is indirect: once SPF, DKIM and DMARC alignment are a hard gate, reputation carries more weight, and bounce volume is the cheapest reputation cost to remove.

How often do Microsoft 365 business email addresses go bad?

Corporate addresses decay roughly 11 times faster than freemail. In Q3 2026 EmailShield data the corporate invalid rate is 23.0% against 2.1% on freemail, and Microsoft-hosted addresses show 39.3% invalid against 5.4% for Google-hosted. A work mailbox lives as long as the employment contract, so an M365-heavy list ages fastest.

How accurate is email verification on Microsoft 365 addresses?

It depends entirely on whether the verifier has a path around the SMTP frontend. EmailShield states 99.8% accuracy as a vendor statement measured in production across 8.19 million verified addresses and 37.1 million live SMTP handshakes in Q3 2026, at an average of 4.5 probe attempts per verdict. On Microsoft-hosted addresses, the question that predicts your bounce rate is what a tool does with the ambiguous half of the list.

Methodology

What this page measures. Every EmailShield figure here is a vendor statement, measured in production from the platform's own verification output across 8.19M+ verified addresses, 2.09M+ profiled domains and 37.1M+ live SMTP handshakes, for Q3 2026. Provider attribution comes from MX resolution at verification time: Microsoft 365, Google Workspace, or gateway-fronted when the MX matches one of eight fingerprints. Where a gateway fronts a Microsoft tenant the address counts in the gateway row, so the Microsoft figures understate its true share.

Verdict definitions. Valid: existence confirmed by a live SMTP handshake. Accepted: confirmed through a provider-policy path, on Microsoft domains the stage-9 account-discovery route. Catch-all: the domain accepted up to 5 plausible nonexistent probe addresses. Unknown: no definitive answer through a full retry chain of up to 3 attempts across different egress IPs within a 2-hour deadline; unknowns never count toward the valid rate.

Sources. Microsoft Defender for Office 365 blog (April 2025, enforced 5 May 2025); Google Postmaster Tools for the 2% bounce threshold; RFC 5321 for SMTP reply-code semantics. Neither is an EmailShield measurement.

Every statistic here describes EmailShield's own verification output. Provider shares reflect the lists customers actually upload, which skew B2B outbound and are not a census of global email, and the valid rates are outcomes of EmailShield's pipeline.

Last updated: July 2026.

Pavel Stoletov is CTO at EmailShield, where he built the verification pipeline described here, including the perimeter-gateway fingerprinting layer and the Microsoft 365 account-discovery path. More at emailshield.co/authors/pavel-stoletov and in the EmailShield developer documentation.