IP Warm-Up and Reputation Repair After a Blocklisting

A domain sitting at Bad in Google Postmaster Tools comes back in six to ten weeks, and it comes back by sending to fewer people rather than by sending better mail. Every recovery we have run began by cutting the sending list to addresses that clicked something in the last thirty days — usually between 8 and 20 percent of the file — and holding it there until the reputation graph moves. There is no version of this that keeps your volume. First, what is actually broken: IP reputation and domain reputation fail differently and are repaired differently. We check whether the sending IP sits on Spamhaus SBL or CSS, whether the domain is on the DBL, what Microsoft SNDS reports for the surrounding /24, and what the rejections literally say. A Gmail 421 4.7.28 rate limit is a different condition from a 550 5.7.1 block, and Yahoo's deferral behaviour is a third thing again. Roughly half the engagements we take turn out to trace to one compromised signup form or one purchased segment somebody uploaded without telling anyone, and finding that is most of the repair. Delisting: Spamhaus does not respond to persuasion. A CSS listing lifts when the sending pattern that caused it has stopped for long enough to be credible, and asking for removal before that restarts the clock. We tell you when a request is worth filing and what it needs to contain. We ignore UCEProtect and suggest you do the same; paying it is a tax on panic. The warm-up: On a dedicated IP, a curve from a few hundred messages a day to your target volume across four to six weeks, sending only to the most recently engaged cohort, with the ramp held or reversed the moment complaint or deferral rate moves. For many senders we recommend against a dedicated IP entirely: below roughly one hundred thousand messages a month you cannot hold volume steady enough to build a reputation, and a shared pool at a well-run provider will treat you better than your own cold address ever will. We would rather tell you that than sell the warm-up. Migrations: Moving between Iterable, Braze, Customer.io, Klaviyo or SES is the most common way a healthy program stops arriving, because the new platform sends from addresses carrying none of your history. We run migrations as warm-ups from day one instead of cutovers, splitting volume between old and new platform by engagement tier while the new one earns its record. What we will not do: We will not warm an address for a list you have not let us cut. That is the whole method; without it we are lending our name to a repeat of the same failure. We will not run a marketing warm-up on the domain your transactional mail depends on. And once reputation is repaired we will not run the reactivation campaign to the dormant tail — that campaign is what caused the listing, and we will forgo the follow-on work rather than execute it. Who this is wrong for: Anyone with genuinely low volume whose problem is one receiver blocking one message type; that is a support ticket, not a program. Anyone who needs sends restored by next Tuesday, because the timeline is set by receiver behaviour and budget does not compress it. Anyone whose file was bought — recovery on a bought file is a treadmill and we will decline. While it runs: A weekly reading of the graphs that matter — Postmaster domain reputation, complaint rate per receiver, deferral and bounce rate by engagement tier — and a written decision on whether the ramp continues, holds or steps back. Not a dashboard. One decision each week, made by the person who set the curve and signed for it.