The Penalty Box: Pulling A Burned IP From Rotation

Pulling a burned IP from rotation means routing new mail away from it the moment you confirm it is throttled or blocklisted, fixing the root cause, requesting delisting where needed, and then re-warming it slowly instead of dumping volume back onto it. The mistake that re-burns an IP is treating a throttle as a transient error and retrying harder. A throttled IP that keeps getting hammered moves from throttled to blocked.

The first job is detection: knowing the difference between a temporary throttle and a real block, and reading the signal correctly before you touch rotation. Get that wrong and every recovery step you take afterward makes it worse.

Detecting A Burned IP

Two signals tell you an IP is in trouble, and they mean different things.

A throttle looks like a temporary 4xx response at the SMTP layer:

host gmail-smtp-in.l.google.com[142.250.150.27] said:
  421-4.7.0 [203.0.113.9] Our system has detected an unusual rate of
  421-4.7.0 unsolicited mail originating from your IP address. To protect
  421 4.7.0 our users from spam, mail sent from your IP address has been
  temporarily rate limited.

421 4.7.0 is a throttle, not a block. The basic code 421 is a temporary policy refusal and the enhanced code 4.7.0 is a temporary security or policy condition. The receiver is unwilling to take more mail from this IP right now. Retrying aggressively against a 421 4.7.0 is exactly how a throttle becomes a block, because the provider reads the renewed flood as confirmation of abuse.

A block is harder. It shows up as 5xx rejections that name a blocklist, or as a hit when you query the public lists directly:

host mx.example.net said: 550 5.7.1 Service unavailable;
  Client host [203.0.113.9] blocked using Spamhaus;
  https://check.spamhaus.org/...

Confirm with the postmaster tooling and the public blocklists. Google's Postmaster Tools is the place to watch a Gmail-bound IP, though its v2 release retired the standalone IP and Domain Reputation dashboards, so track Compliance Status and Spam Rate there, and check Spamhaus, Sender Score, and an MX-lookup blocklist scan separately.

Pulling It From Rotation

Once you confirm the IP is throttled or listed, stop sending fresh mail from it. The point is to stop generating new negative signal while you fix the cause and let the existing reputation damage decay.

• Remove the IP from the active sending pool so new messages route to your healthy IPs.
• Let the in-flight queue for that IP drain or pause it; do not retry-storm a throttled IP.
• If a whole pool is affected, throttle your own outbound rate down hard rather than failing over to IPs you will only burn next.

A single quarantined IP among several healthy ones is a controlled situation. A failover that spreads the same bad mail across your entire pool is how one burned IP becomes five.

Fix The Cause Before You Ask For Anything

Delisting requests fail when the underlying problem is still live. Spamhaus is explicit that it will not process a removal while the spam issue that caused the listing is still active. So the corrective work comes first:

• Find what burned it. Pull the logs for the window before the listing and look for the volume spike, the bad list, the compromised account, or the open relay that sourced the abuse.
• Clean the list. Remove invalid recipients and addresses that bounce, and stop sending to anything that hits a spam trap.
• Close the source. If a credential was compromised or a form was being abused to send, shut that down. A listing caused by a breach will recur within hours of delisting if the breach is open.
• Verify authentication. Confirm SPF, DKIM, and DMARC align with the sending identity so the rehabilitated IP has a stable identity to rebuild against.

Requesting Delisting Honestly

For a public blocklist, follow the list's process rather than guessing.

• Spamhaus removal is always free. Any service charging to delist from Spamhaus is not legitimate.
• For SBL listings, the network owner or ISP submits the removal, not always the individual sender; you provide the SBL ticket number and a summary of the corrective actions taken, and your provider files it.
• Removals are only processed once the issue is fixed, and legitimate SBL and XBL requests are typically handled within roughly 24 to 72 hours.

Do not submit, get listed again, and resubmit. Repeated removal requests on a still-dirty IP read as bad faith and slow you down.

Re-Warming Without Re-Burning

A delisted or un-throttled IP is not a recovered IP. Its reputation is still weak, and slamming full volume back onto it re-burns it immediately. Re-warm it the way you would warm a brand new IP.

• Start low. A few hundred messages a day, then increase gradually, roughly doubling every few days only while the signals stay clean.
• Send to your best recipients first. Prioritize the most engaged, recently active subscribers so the early sends generate opens and near-zero complaints.
• Watch the signals at every step. If Spam Rate ticks up or reputation drops in Postmaster Tools, cut volume immediately rather than pushing through.
• Be patient on the timeline. After the root cause is fixed and volume is kept low, climbing back to a healthy reputation commonly takes on the order of a week or more, not a day.

The honest part of this is that there is no shortcut. Waiting without sending lets bad reputation decay, fixing the cause stops it from coming back, and slow re-warming rebuilds the score one clean send at a time. Any plan that skips a step trades a short delay now for a longer outage later.

If you are rehearsing this for an email-infrastructure interview, practice saying the recovery sequence out loud in order: confirm throttle versus block by reading the SMTP code, pull the IP from rotation, fix the root cause, request delisting only after the cause is fixed, then re-warm slowly from your most engaged recipients. Being able to walk a 421 4.7.0 from detection to full recovery without re-burning the IP is exactly the operational judgment a deliverability reviewer is listening for.