The conversation the mail server was having without us. Saurav had been building verification tooling for two years when he called. His pipeline was technically clean — properly retried, sensible rotation logic. He wasn't calling because something was obviously broken. He was calling because a subset of corporate domains — mid-sized companies running their own mail infrastructure or managed Microsoft 365 tenants — were returning "unknown" at almost three times the rate of similarly sized companies on Google Workspace.
The addresses weren't invalid. Saurav had independently confirmed several through LinkedIn and company websites. The companies existed, the employees existed, the format was correct. His system simply couldn't get a definitive answer from the mail servers behind those domains.
He'd tried more IPs, slower pacing, different retry windows. Nothing moved the ratio. More IPs had actually made it slightly worse — a detail he mentioned as a side note that turned out to be the most important thing he said.
Four different block types, producing four different result signatures, were all being classified as "unknown" and all attributed to the same suspected cause: IP reputation. IP reputation was one factor — but it wasn't the primary factor for three of the four block types, and for one of them, adding more IPs actively made things worse.
01What the receiving mail server actually sees
Almost every explanation of SMTP verification describes the process from the sender's side: your tool sends commands, the server responds, you interpret them. That leaves out the view that explains why blocks happen in the patterns they do.
From the receiving server's side, a verification query is an inbound connection from an IP it may have no relationship with, following a distinct pattern — EHLO, MAIL FROM, RCPT TO, then QUIT without a message. The server isn't evaluating your tool. It's evaluating the origin, and it makes a sequential decision at each stage of the handshake. Where the block occurs tells you more about the cause than the response code does.
- Block at TCP connection. A network-layer or firewall policy decision — IP reputation in the SMTP sense isn't the primary variable.
- Block after EHLO, before MAIL FROM. An identity policy decision. The server wants something your query doesn't provide. Cleaner IPs don't fix this.
- Block after MAIL FROM, before RCPT TO. A rate or sender-policy decision — both IP reputation and MAIL FROM configuration matter here.
- 250 after RCPT TO, then a silent close. A behavioral detection decision. The server recognized the probe pattern and returned a deliberately misleading response.
Saurav's instinct to add more IPs was correct for the first category and the wrong response for the last — and the last was concentrated enough in his corporate domain subset to make his aggregate ratio worse whenever he added IPs.
02Block type one: TCP connection refused before SMTP begins
An immediate TCP reset or timeout on port 25 means the handshake never started — no 220 banner, no SMTP daemon involvement at all. A firewall rule, a load-balancer connection policy, or a network-perimeter reputation database made the call before the first protocol byte.
For Microsoft 365 tenants and organizations running Proofpoint or Mimecast in front of Exchange, this is common for IPs with no prior sending relationship to that tenant. The decision isn't about email quality — it's whether the origin is trusted enough to start a conversation at all.
03Block type two: 554 policy rejection after EHLO
TCP succeeds, the 220 greeting arrives, EHLO gets sent — then a 554 policy rejection. This surprises engineers most because the handshake looked like it was progressing normally.
The common causes: an EHLO identifier that doesn't resolve in forward DNS, or reverse DNS for the connecting IP that doesn't match it; a network range an administrator has explicitly blocked at the application layer; or an AUTH requirement the verification system never satisfies.
For domains that require AUTH credentials, the right move is to classify them separately and stop retrying — no amount of pacing or IP rotation produces credentials the system doesn't have.
04Block type three: 421 or 550 after MAIL FROM
This is the block type closest to what people usually mean by "IP reputation block." The server accepted the connection and identity, then evaluated the sender address and origin and stopped.
A 421 is temporary — rate limiting or connection budgeting. A 550 is permanent policy refusal tied specifically to the MAIL FROM address or origin IP.
A configuration detail that's easy to overlook: a null sender address (the empty string, or
<>) is valid SMTP for probing, but modern Postfix, Exim, and Exchange
configurations specifically recognize it as a verification probe signature and apply a more
restrictive policy than they would to a well-formed sender.
For the 421 responses, the fix is targeted rate reduction to that specific server — not a blanket slowdown across the whole pipeline.
05Block type four: the false 250 after RCPT TO
The most technically sophisticated block, and the most misleading in its output. The full handshake succeeds through RCPT TO, the server returns 250 — the acceptance code — and then within seconds either closes the connection silently or resets it.
The 250 wasn't genuine. This is deliberate policy behavior, sometimes called a "false accept" or "tarpit with acceptance," built for connections the server has identified as systematic probing: a definitive rejection would teach the prober which addresses are invalid, so the server gives back nothing useful instead.
An IP with real sending history to a domain presents a different behavioral context — the server has more signals suggesting it isn't pure probing. A brand-new IP has no mitigating context at all, so it receives false 250s at a higher rate than an established one. Every new IP added to attack this category made the aggregate ratio worse, not better.
The practical short-term fix is calibration, not resolution: before verifying real addresses at a domain, send an RCPT TO for a username that couldn't plausibly exist there. If the server returns 250 for that, mark every RCPT TO response from that domain as unreliable and fall back to cross-source corroboration or catch-all classification instead of trusting the handshake.
06What the Microsoft 365 tenant policy layer explains
Two companies on the same Microsoft 365 tier can produce completely different block profiles depending on three settings their IT administrator configured independently:
- Inbound connector policies. Restrict which IP ranges can initiate SMTP sessions at all — producing block type one regardless of general IP trust.
- Enhanced filtering for connectors. When a security gateway like Mimecast or Proofpoint is in front of Exchange Online, this setting decides whether the tenant evaluates the original connecting IP or inherits the gateway's trusted status.
- Mailbox intelligence in Defender for Office 365. Learns from a tenant's historical received-mail patterns — an IP with a legitimate sending history is evaluated differently than one appearing for the first time in a probe-pattern conversation.
Google Workspace applies platform-level defaults consistently; Microsoft 365 doesn't. Corporate Microsoft 365 domains need to be treated as individually characterized rather than one homogeneous group — Saurav's 3x-worse ratio wasn't one problem, it was many per-tenant policy decisions clustering into the same output category.
07Diagnosing which block type you're hitting
Most verification systems don't log at the stage resolution needed to tell these apart, which is why they collapse into one "unknown" bucket. Five logging additions fix that:
- TCP completion rate per domain. A domain completing far below typical rates signals block type one — pacing and retries won't touch it.
- 220 banner receipt rate after TCP. A gap here means protocol-level filtering between network and application layers.
- EHLO success rate after 220. A systematic 554 gap identifies block type two; the accompanying message names the specific policy.
- MAIL FROM outcome rate. Track 421 vs. 550 vs. 250 separately — it tells you whether you're hitting rate policy or sender policy.
- RCPT TO calibration. Probe with an implausible username before trusting any real result from a new domain; a 250 there flags the whole domain as unreliable.
Saurav added these over two days. The resulting data let him apply targeted fixes per block type instead of generic adjustments — his corporate-domain unknown rate dropped 41% over the following three weeks, mostly from the MAIL FROM and EHLO fixes he could make immediately.
08What fixes apply to which block types — and what to stop doing
- Type one (TCP refused): origin history is the lever — more IPs with prior relationship signals help. Stop varying retry timing; the network layer isn't evaluating it.
- Type two (554 after EHLO): fix EHLO/DNS alignment. Stop adding IPs — the same misconfiguration follows every new one.
- Type three (421/550 after MAIL FROM): switch off null sender to a well-formed, SPF-aligned address for 550s; reduce rate to the specific server for 421s.
- Type four (false 250): implement the calibration probe now. Stop adding new IPs specifically for domains where this concentrates — they arrive with less history and worse false-accept rates.
09What this means for the proxy layer — honestly
Saurav assumed his problem was primarily IP reputation. It turned out to be four problems with different causes. IP reputation and origin history address block types one and four directly, contribute alongside MAIL FROM configuration for type three, and have no bearing at all on type two — a perfectly reputable IP presenting a misconfigured EHLO identity gets the same 554 as any other IP.
What residential IPs with prior sending history provide, beyond origin recognition, is the behavioral context for block type four that separates a false 250 from a genuine one — a relationship that takes time to build and can't be manufactured by rotating to fresh addresses. It's the one thing in this stack that genuinely can't be shortcut.
Start with 500 free credits
Residential proxy infrastructure with verified sending history across major enterprise mail environments — the foundation the configuration fixes above are built on.
Get started →Frequently asked questions
Why do mail servers block email verification checks?
Mail servers evaluate the origin and behavior of an inbound SMTP connection, not just the address being checked. A verification query follows a distinctive pattern — connect, greet, present a sender, ask about a recipient, then disconnect without ever sending a message — and servers configured to notice that pattern respond with anything from a network-level refusal to a deliberately misleading acceptance, depending on which policy layer makes the call.
What does a 554 error mean during SMTP verification?
A 554 returned right after EHLO is a policy rejection of the identity your system presented — usually a mismatch between the EHLO hostname and the connecting IP's reverse DNS, an explicitly blocked IP range, or a missing authentication credential the server requires. It's a configuration issue, not an IP reputation issue, so switching IPs doesn't change the outcome.
Why does my verification tool return "unknown" for valid emails?
"Unknown" is often several different server responses collapsed into one label. A tool that doesn't log at each stage of the SMTP handshake can't tell a network-level TCP refusal apart from a policy rejection, a rate limit, or a deliberately false acceptance — all of which require different fixes but look identical in an undifferentiated output category.
Should I use a null sender address for SMTP verification?
A null sender (the empty MAIL FROM) is valid SMTP, but modern Postfix, Exim, and Exchange configurations specifically recognize it as a verification-probe signature and apply stricter policy than they would to a well-formed address. Switching to a real, SPF-authorized sender address on a domain you control typically reduces policy-based rejections significantly.
Why do more IPs sometimes make email verification worse?
For blocks based on network-perimeter trust, more IPs help. But for servers that return a false acceptance to connections they've identified as probing, a brand-new IP has no sending history to soften that judgment — so it gets flagged as pure probe behavior more often than an IP with an established, legitimate sending relationship to that domain. Adding IPs concentrated in that category can raise your overall false-accept rate rather than lower it.
How can I tell if a mail server is returning a false 250 response?
Send an RCPT TO for a username that couldn't plausibly exist at that domain before trusting any real result. If the server returns 250 for an address that can't possibly be real, it's returning false accepts for that domain, and every other RCPT TO response from it should be treated as unreliable until you have another way to confirm deliverability.
Why are Microsoft 365 domains harder to verify than Google Workspace domains?
Google Workspace applies consistent platform-level defaults across every tenant. Microsoft 365 gives individual IT administrators a much richer policy layer — inbound connector restrictions, enhanced filtering behavior when a security gateway sits in front of Exchange, and mailbox intelligence that learns from each tenant's own mail history — so two companies on identical subscriptions can produce completely different verification behavior.