The Ticket I Could Not Answer
The number that broke everything
Support Ticket · Tuesday
"Your tool marked 1,400 addresses valid last Tuesday, and 340 of them bounced yesterday. Can you tell me what happened?"
I remember exactly where I was sitting when I read it. I remember because I had no answer.
The customer was not angry. That was the worst part. Angry customers give you something to work with — a grievance to address, an emotion to match. This one was just confused. He had done everything right. Uploaded a clean list. Waited for verification to complete. He had trusted the output the way you trust a thermometer as a factual reading of a real state.
What I discovered over the following week was that on the Tuesday his list ran, two of our proxy IPs had been in an advanced soft-limiting state with Microsoft's servers for approximately eighteen hours before his job started. The IPs were not blocked. They were not throwing errors. They were receiving responses from Microsoft's mail servers that looked structurally identical to honest responses and were not.
Addresses that did not exist were returning 250 acceptance codes. Our logic classified those 250s as valid because that is what the protocol says a 250 means. The logic was correct. The inputs to the logic were not.
He lost a campaign. We lost the customer six weeks later — not to a complaint, just to silence. That silence is what this piece is actually about. Not the dramatic failure you can see. The quiet one you cannot, until someone sends you a ticket you have no answer for.
The Core Misunderstanding
Three States That Get Called the Same Name
The phrase "IP ban" describes three distinct infrastructure states. Each one has a different cause, a different duration, and a critically different correct response. Treating them as the same problem is how teams apply the right fix to the wrong state and wonder why nothing improves.
Soft Rate Limiting
Earliest · Most Missed
The mail server has observed connection behavior deviating from baseline. It begins introducing friction — elevated response latency, intermittent timeouts, and occasional 421 temporary deferral codes. You are not blocked. Results still return. The degradation is subtle enough that most pipelines absorb it as normal variance.
Teams operating in soft limiting for weeks without knowing it is the most common precondition for eventually reaching a hard block.
Greylisting
Not a Ban · RFC 6647
Not an escalation response to suspicious behavior — a standard inbound filtering mechanism. When a server receives a connection from an unrecognized IP, it returns a temporary 4xx deferral and waits to see whether the sender retries. Spam infrastructure typically does not retry. Legitimate infrastructure does. The retry window is typically 1–15 minutes, set individually by each server.
For verification pipelines: if your rotation logic sends the retry from a different IP that does not share a /24 subnet, the server never sees the expected retry. The address sits unresolved — this looks like an IP reputation failure but is a rotation logic failure. The fix is different.
Hard Blocking
The Actual "Ban"
The server refuses connections at the TCP level or returns permanent 5xx rejection codes before the SMTP handshake completes. This state does not arrive without prior warning. It is preceded by extended soft limiting and frequently by sustained greylisting failures.
A team that reaches a hard block was almost always in the soft limiting state for a significant period without the instrumentation to detect it.
The Evaluation Model
What Mail Servers Are Actually Evaluating
Mail servers escalate against IPs based on how current traffic behavior compares to the established pattern for that origin. Volume is a contributing factor. It is not the primary one. The primary one is deviation from baseline — specific to your IP, built from every interaction that IP has had with that server over time.
This explains why two pipelines running identical logic at identical volume produce different results on different infrastructure. The server is not evaluating the logic. It is evaluating the behavior of a specific origin against what it expects from that origin.
🔗
Connection-to-delivery ratio
Verification traffic produces structurally different connection patterns from legitimate mail. Pipelines opening hundreds of connections per hour with zero message deliveries escalate faster than those that don't, independent of volume.
Monitor connection patterns relative to delivery events
🏷️
EHLO hostname & PTR record
The signal is not whether your EHLO hostname is consistent — it's whether it resolves correctly and has a matching PTR record. A mismatched or non-resolving EHLO is a signal for automated traffic. Randomizing hostnames doesn't help. Valid PTR resolution does.
Ensure EHLO hostname resolves with valid reverse DNS
📦
Address query clustering
Processing all addresses at one company consecutively creates a per-domain query pattern statistically different from legitimate inbound mail. Interleaving domain queries distributes per-domain rate over time rather than concentrating it.
Interleave domain queries across runs
📊
Deviation from your baseline
The threshold at which soft limiting triggers is not published and varies by server, IP history, and current load. Dramatically exceeding your IP's historical connection rate during large batch runs produces the deviation that triggers escalation.
Monitor per-IP 4xx rates in 30-minute windows
Separating Fact from Intuition
Pacing — The Argument That Holds and the One That Does Not
Effective pacing is widely recommended. Most of what gets written about it conflates two things: pacing that actually reduces escalation risk, and pacing advice that sounds intuitive but does not hold up technically.
✕
Does not hold
Time-of-day routing. The idea that running verification during business hours for your target domain's timezone makes traffic look more legitimate is not technically sound. Mail servers hosting business email receive legitimate inbound traffic from every timezone continuously. The server evaluates the behavior of your specific IP against its baseline — not the time of day the connection arrives.
✓
What pacing actually addresses
Per-server connection rate relative to your IP's baseline. Staying within the range of connection rates your IP has historically produced — rather than dramatically exceeding it during large batch runs — reduces deviation from baseline and therefore reduces escalation risk. Monitor per-IP 4xx rates in short windows and treat sustained elevation as a signal to reduce connection rate.
✓
What pacing actually addresses
Per-destination query distribution. Concentrating a large volume of verification queries against a single enterprise domain in a short window triggers destination-level rate limiting that operates independently of your IP reputation. Distribute queries to any single enterprise domain across time rather than processing all addresses consecutively.
✓
What pacing actually addresses
Greylisting retry discipline. When your system receives a 4xx temporary deferral, the retry must originate from the same IP — or within the same /24 subnet where the server permits it. It must wait for the minimum delay specified. A retry that arrives too early fails the trust test as definitively as one that never arrives.
When It Happens Anyway
Recovery — Separated by State
Temporary block recovery requires a complete stop — not reduced volume, but zero connections from the blocked IP. Many servers reset the block timer on each connection attempt received during the block window. A team probing at reduced volume during a temporary block is actively extending its duration.
!
Do not immediately rotate to a fresh IP at full volume. The behavioral pattern that triggered the block is in your pipeline, not in your IP. A fresh IP running the same behavior reaches the same state faster than the original IP did, because the server is already sensitized to that pattern from an associated source.
For hard blacklist recovery, the list type determines the process and timeline. These have different response times because they have different listing criteria:
Spamhaus SBL
Associated with spam sources, maintained manually. Removal requires the ISP responsible for the IP to submit a request after the underlying spam issue has been fully resolved. Spamhaus will not process requests while the problem is still active.
Weeks–Months
Spamhaus CSS
Automatically generated list targeting low-reputation email. CSS listings typically expire on their own — usually within 3 days of the last spam detection. Handled via Spamhaus's self-service IP and Domain Reputation Checker. One request covers both XBL and CSS.
~3 Days
Spamhaus XBL
Lists IPs associated with compromised systems. Removal now handled together with CSS through a single request via the Reputation Checker tool.
~3 Days
Barracuda BRBL
Focuses on IPs associated with spam and abusive mail. Removal requests processed through their lookup tool with a period of observation after the request before de-listing. Timeline varies based on severity and prior listing history.
2–8 Weeks
The honest range for recovery from a meaningful shared blocklist entry is two weeks to several months. That range is not imprecision — it reflects genuine variance in listing type, prior history, and how completely the behavior that triggered the listing has been addressed. There is no shortcut through this process.
Build This Before You Need It
The Signals Your Pipeline Is Not Producing
The week after that support ticket arrived, I spent three days adding logging we should have had from the beginning. Not because the logging was technically difficult. Because we had built the pipeline to report outputs and had never instrumented it to report the signals that precede output degradation.
1
Per-IP 4xx rate in 30-minute windows
Temporary deferral codes are the server's primary communication in the soft limiting state. Track these at the per-IP level — not aggregated across your pool — in short windows. A single IP's 4xx rate climbing relative to its own baseline, even while pool-level rates look normal, is an early escalation signal. Pool-level aggregation hides it entirely.
Leading indicator — gives you hours, not days, to respond
2
Per-domain unknown rate over time
If your unknown rate on Microsoft 365 addresses is 4% on Monday and 13% on Thursday with no change in list composition, the relationship between your infrastructure and Microsoft's servers has changed. Track unknown rate per major provider — Microsoft, Google, Yahoo — rather than as a single aggregate. This isolates the problem to a specific server relationship rather than obscuring it in an overall number that might still look acceptable.
Identifies which server relationship degraded and when
3
Greylisting retry resolution rate
For every address that returned a 4xx temporary deferral and was retried, what percentage resolved on retry? A rate that drops significantly over time indicates either that retries are not originating from a recognized subnet (a rotation logic problem) or that the server is continuing to defer despite correct retry behavior (an escalation problem). These two causes have different fixes. Tracking this metric is what tells you which one you have.
Distinguishes rotation logic failures from reputation failures
These three signals require logging decisions that most pipelines do not make by default. Adding them takes hours. Not having them means the first sign of a problem is a support ticket you have no answer for.
The Argument Nobody Has Made
The Closing Argument Nobody in This Space Has Made
Every piece written about avoiding IP bans eventually arrives at the same destination: better infrastructure, aged IPs, and purpose-built proxy networks. That argument is true. It is also one you have heard.
What does not get said is this: the teams that avoid IP bans are not primarily winning on infrastructure quality. They are winning on reaction time.
The difference between a temporary soft-limiting event and a hard blacklist entry is almost always the time between when the escalation started and when the team noticed it. A pipeline that catches soft limiting within hours and responds — stays in the soft limiting state temporarily and exits cleanly. A pipeline with no instrumentation to detect soft limiting stays in it for days or weeks, crosses into hard blocking, and then faces recovery measured in months.
Infrastructure quality determines where the thresholds are. Instrumentation determines whether you know you are approaching them.
The teams that suffer the most are not on the worst infrastructure. They are on adequate infrastructure with no visibility into what it is doing. They find out at the worst possible moment — when a customer sends a ticket asking a question they cannot answer.
Know before Monday what your pipeline did on Friday
Proxy25 is built for teams that cannot afford to find out mid-campaign. Residential IPs with clean SMTP history, purpose-built for verification at scale.
IP ban prevention
email verification infrastructure
SMTP rate limiting
greylisting retry logic
proxy rotation strategy
B2B email verification 2026
