Four days to deliver what should have taken four hours
Proxy25 is a verification infrastructure company. We build the IP layer that verification tools run on — addresses with years of SMTP interaction history with major mail servers, so that verification queries get honest responses rather than defensive ones. That is the problem this business was built to solve.
Which is why when Omar called in March, my first instinct was that he had reached the wrong place.
Omar ran email operations at a mid-sized SaaS company. He managed sending infrastructure the way someone manages plumbing — you maintain it, you do not think about it much, and you notice it fast when something goes wrong. He had been doing this long enough that most deliverability problems had a shape he recognized. The March problem did not have a shape he recognized.
He had kicked off a batch of forty thousand contacts on a Tuesday afternoon. New sending domain, six weeks into a warmup, a sequence he had run successfully on smaller cohorts. By Wednesday morning, forty percent of the sends were sitting undelivered — not bounced, not rejected, sitting. The queue was processing. SMTP connections were completing. The server logs were full of 4xx response codes, and the system was retrying them on schedule. Each retry produced the same 4xx. The batch was not moving.
When I pulled his SMTP logs, the problem was in the response codes — specifically in the extended status codes appended to every 4xx response. Two ISPs had been returning a specific class of throttling response since early Tuesday. His system had been treating those responses as generic temporary deferrals and retrying them on a fixed five-minute interval.
The five-minute interval is correct behavior for one kind of 4xx event. It was the wrong behavior for the kind his system had actually encountered. That mismatch — between the retry behavior the system was running and the retry behavior the throttle type required — is why four days happened instead of four hours.
The two systems that both say "try again later" — and mean different things
Omar's retry logic treated every 4xx as the same signal. It is not. When an SMTP connection returns a 4xx response code, it is communicating one thing: this delivery attempt cannot complete right now, try again. What it is not communicating is which of two fundamentally different systems produced that response.
Why the threshold moves — and why Omar's hit it when it did
ISPs run receiving mail infrastructure for large user populations. That infrastructure has finite processing capacity. When one sending source generates connection volume that consumes a disproportionate share of that capacity, the ISP throttles that source to protect capacity for all other senders.
The throttle ceiling is not fixed. It is a dynamic limit that reflects the ISP's current load, the connection history of the specific sending IP, and how much capacity the ISP is willing to allocate to that source relative to competing demand at that exact moment. An IP with two years of consistent sending to a specific ISP has established an allocation expectation the ISP's system has calibrated against. The same IP sending at three times its historical rate hits the ceiling at a lower absolute volume than it would during low-traffic hours.
Omar had sent to that regional ISP at volumes up to ten thousand messages per day during warmup. The March batch sent twenty-two thousand messages to that ISP's address space in a six-hour window on a Tuesday afternoon. His daily ceiling with that ISP was roughly eight to ten thousand messages. He had sent more than twice that in six hours.
He did not know his ceiling existed. His sending platform showed him overall delivery metrics. It did not show him per-ISP volume breakdown — the number that would have told him, before the send, that the March batch required either a longer delivery window or a split approach pacing volume to each ISP's share of the address list.
Reading extended SMTP status codes
SMTP response codes communicate in two layers. The three-digit code — 421, 450, 452 — indicates the class of failure. The extended status code appended to many responses narrows the failure category enough to distinguish throttle type. Most retry logic evaluates the three-digit code class and applies a uniform retry behavior. The extended code is logged, not acted on.
In Omar's logs, the extended codes were unambiguous:
421 4.7.1
Adding differentiated retry behavior based on the extended status code class requires parsing the extended code from each response and mapping code classes to different behavioral responses. It is a few hours of development work. The extended codes are already in the logs. The logic just needs to read them.
ISP feedback loops — and why warmup metrics can mislead
Omar's domain throttled at a lower ceiling than he expected given his warmup volume. The engagement signal component of ISP feedback loop architecture is part of why.
Most senders understand ISP feedback loops as complaint reporting systems. That is one component. What most senders do not know: major ISPs also aggregate and share engagement signal through FBL infrastructure — open rates, delete-without-open rates, move-to-inbox rates from recipients actively choosing to route mail to inbox — tracked at the IP and domain level and factoring into the ceiling calculations that determine where ISP-level throttles engage.
A sender whose mail is consistently deleted without being opened — not marked as spam, simply ignored at high rates — accumulates negative engagement signal over time. The ISP's capacity allocation for that sender's IP adjusts downward. The sender encounters throttling at volumes that previously processed without friction, without any increase in actual complaint rate, without any change in sending behavior.
Omar's sending domain was six weeks old. Warmup had generated engagement signal from seeded addresses — controlled mailboxes that open and engage with warming mail to establish positive sending history. Real recipients, receiving mail from an unfamiliar domain, engage differently. Delete-without-open rates from real recipients on a new domain run higher than warmup metrics suggest, because warmup metrics measure delivery acceptance and seeded engagement, not the organic engagement quality that FBL systems track.
The regional ISP he hit hardest had six weeks of delivery acceptance and seeded engagement from his domain. When the March batch arrived at more than double the established daily volume, the ISP's throttle calculation reflected the full picture — including the gap between warmup metrics and the engagement signal his domain had actually generated with real recipients.
Two greylisting failure modes — both presenting identically
Omar's issue was ISP throttling. But greylisting failures are the most common thing I see misdiagnosed as IP reputation problems at Proxy25, and it is worth being specific about the two failure modes that produce persistent greylisting outcomes.
The retry architecture that handles both: a minimum retry delay of twelve minutes for any greylisting-related 4xx event, which clears the minimum delay window for the significant majority of greylisting implementations. Exponential backoff on subsequent retries, which distinguishes the retry pattern of legitimate infrastructure from spam infrastructure that retries at fixed short intervals.
How Omar and I cleared the stuck queue
The batch had been in partial-delivery state for two and a half days when Omar reached out. The immediate question was how to get the remaining undelivered messages cleared without making the throttle condition worse.
The approach that works for ISP throttling recovery is the one that feels wrong from a throughput perspective: pull back substantially on the connection rate to the throttling ISPs. Most teams' instinct when a batch is stuck is to maintain pressure — keep the retries coming, let the system work through it. For volume throttling, maintained pressure at the triggering rate is what sustains the throttle condition.
The throttle had been recoverable from the first hour. The retry behavior had prevented the recovery from happening. Four days happened because the system was applying the right fix to the wrong problem, every five minutes, for ninety-six hours.
The volume framework — built before the send, not during recovery
Before the March batch, Omar sized his sends based on total recipient count and overall daily volume targets. He did not think about how the recipient list distributed across ISP address space, and he did not have a per-ISP volume ceiling to work from.
The MX resolution step takes about twenty minutes on a list of Omar's size. It is the step that would have told him, before Tuesday afternoon, that the March batch was routing twenty-two thousand messages to a regional ISP whose ceiling with his domain was eight to ten thousand per day. That number changes the batch sizing decision before the send — not during a four-day recovery window after it.
Four questions before the next large batch
There is a version of March's problem waiting in every email operation that sizes sends on total recipient count without accounting for per-ISP distribution. The throttle announces itself as a four-day delivery window and a queue that will not clear.
Omar answered none of these before March. He answers all of them now. Four questions before the send. Four days if you skip them.
The same history depth that widens volume ceilings determines response accuracy
Proxy25 provides verification proxy infrastructure with SMTP interaction history built across major ISPs over years of consistent querying — the same history depth that determines volume ceiling width on the sending side determines response accuracy on the verification side.