The shortcut version of IP pre-flight is checking Spamhaus. It takes five seconds, costs nothing, and catches the most obvious cases of contaminated IPs. The operators who only check Spamhaus eventually discover that the obvious cases were not the dangerous ones. The IPs that fail Spamhaus are easy to identify and reject. The IPs that pass Spamhaus but fail other checks are the ones that produce six months of degraded customer deliverability and confused diagnostics.
We have been refining our IP pre-flight checklist for about three years. The current version runs 14 distinct checks against every IP before we assign it to a customer. The checks take longer than five seconds (typically 15-25 minutes per IP including waiting periods for some checks). They catch contamination patterns that a quick check would miss. They also produce a small base rate of IP rejections that surprises operators new to this kind of rigor.
This post is the 14 checks, what each one catches, the failure rate we observe on each, and the operational discipline of treating IP allocation as something more than “we have IPs, let’s use them.”
Why pre-flight matters more than warmup
Operators often assume the warmup process will surface IP reputation issues. The thinking: if the IP has problems, warmup will fail, we will detect the failure, we will rotate to a different IP. The warmup is the safety net.
The warmup is a safety net but a slow and expensive one. A warmup that fails on day 25 has consumed 25 days of customer time and produced reputation impact on whatever destinations were involved. Customer onboarding is delayed. Customer trust is damaged. The IP rotation produces additional delays.
A pre-flight that fails on day 0 takes minutes to identify a different IP from the pool. The customer experience is no different than getting a clean IP from the start. The cost is amortized across the pool rather than concentrated on the customer who got the contaminated IP.
The economics: pre-flight checks cost us minutes per IP and roughly 10-15% of IPs we acquire. Warmup failures cost us weeks of customer time and significant customer relationship damage. The pre-flight investment is unambiguously favorable.
The 14 checks in operational order
We run the checks in a specific order designed to fail fast on cheap checks and reserve expensive checks for IPs that have passed the cheap ones.
Check 1: Spamhaus SBL / XBL / PBL
The standard first check. Spamhaus operates three lists relevant to outbound sending:
SBL (Spamhaus Block List) lists IPs Spamhaus has manually identified as spam sources. Listings here are conclusive evidence of past abuse.
XBL (Exploits Block List) lists IPs that show signs of compromise (malware, botnet activity). Listings indicate either current or recent compromise.
PBL (Policy Block List) lists IP ranges that should not be sending direct-to-MX mail according to the netblock owner’s policy. Listings here are policy rather than abuse-based.
We check via DNS query: <reversed-ip>.zen.spamhaus.org. The query returns 127.0.0.x codes indicating which lists contain the IP.
Failure rate at this check: about 4-6% of newly acquired IPs. The failure rate is higher when we acquire IPs from providers with weaker reputation history.
We reject IPs failing any Spamhaus list. The remediation process to delist takes weeks at best; pre-flight rejection is cheaper than attempting to clean a contaminated IP.
Check 2: SURBL
SURBL (Spam URI Reputation List) historically focused on URIs but maintains IP-level data. Listing here indicates the IP has been associated with mail containing flagged content.
Check via DNS: <reversed-ip>.multi.surbl.org.
Failure rate: about 0.8-1.2%. Lower than Spamhaus because the criteria are different. IPs that fail SURBL but pass Spamhaus are a real category.
We reject SURBL-listed IPs.
Check 3: Composite Block List (CBL)
CBL is now part of XBL but we explicitly query the historical CBL data as it sometimes shows different patterns than XBL alone.
Check via DNS: <reversed-ip>.cbl.abuseat.org.
Failure rate: about 0.5-0.8%.
Check 4: UCEPROTECT (all levels)
UCEPROTECT operates three escalating lists. Level 1 lists individual IPs. Level 2 lists IP ranges where multiple Level 1 listings have occurred. Level 3 lists entire AS numbers where Level 2 listings have occurred.
Check via DNS:
<reversed-ip>.dnsbl-1.uceprotect.net<reversed-ip>.dnsbl-2.uceprotect.net<reversed-ip>.dnsbl-3.uceprotect.net
Failure rate: Level 1 about 1.5-2%. Level 2 about 5-8% depending on netblock origin. Level 3 about 10-15%.
UCEPROTECT Level 3 listings are particularly problematic because they affect the entire AS. We sometimes accept Level 2 or Level 3 listings if other indicators are clean and the listing is from a known overzealous range, but we document the trade-off explicitly.
Check 5: SORBS
SORBS (Spam and Open Relay Blocking System) maintains multiple lists with different criteria. We check the aggregate SORBS list which includes their most consequential sub-lists.
Check via DNS: <reversed-ip>.dnsbl.sorbs.net.
Failure rate: about 1.5-2.5%. SORBS catches some patterns that other lists miss.
Check 6: Barracuda Reputation Block List (BRBL)
BRBL is operated by Barracuda Networks and reflects reputation data from their security infrastructure. The list is used by their products and licensed by some other security vendors.
Check via DNS: <reversed-ip>.b.barracudacentral.org.
Failure rate: about 0.5-1%. BRBL has good coverage of corporate mail flow patterns.
Check 7: Microsoft SNDS history
Microsoft Smart Network Data Services (SNDS) provides reputation data for IP ranges sending to Outlook.com, Hotmail.com, and Microsoft 365. We query the SNDS API (authenticated access for IPs we own or manage) for the IP’s recent history.
Relevant SNDS indicators:
- Green/Yellow/Red status over the past 30 days
- Complaint rate from Microsoft recipients
- Filter results (mail accepted vs filtered)
- Trap address hits (IPs hitting Microsoft spam traps)
Failure rate at the Yellow/Red threshold: about 6-9%. SNDS catches IPs that have been used for sending without being formally listed by other blocklists.
Microsoft trap hits are particularly informative. Any IP showing trap hits in recent history is rejected regardless of other indicators.
Check 8: Gmail Postmaster Tools historical data
Gmail Postmaster Tools provides domain-level reputation data but we use it for IP-level inference when we have visibility into IPs that were associated with monitored domains.
The relevant question: has this IP been associated with mail going to monitored domains in Postmaster Tools, and what was the reputation pattern?
This check requires us to have either ownership of the IP’s recent sending history (if we’ve been using it) or correlation data from customer Postmaster Tools accounts where the IP appeared.
Failure rate: about 2-3%, only applies to IPs with prior history we can analyze.
Check 9: Forward-confirmed reverse DNS (FCrDNS)
Reverse DNS configuration matters operationally. The IP must have a PTR record. The PTR record must resolve to a hostname. The hostname must resolve back to the IP (forward-confirmed).
The check verifies all three:
- PTR record exists for the IP
- PTR target hostname resolves
- Forward-resolved IP matches the original IP
Failure rate: about 5-8%. New IPs from providers sometimes lack PTR records, have generic PTR records (like vps-12345.provider.tld), or have PTR records that point to hostnames that no longer resolve.
We reject IPs failing FCrDNS or with generic PTR records. We require the PTR to be customizable to the customer’s HELO domain before use.
Check 10: Open relay test
The IP must not be running an open relay (accepting SMTP from any sender to any recipient). Open relays produce immediate abuse patterns when discovered.
We test by attempting to relay through the IP from outside its trusted network. The expected response is rejection (5xx error). Acceptance indicates open relay.
Failure rate: about 0.1-0.3%. Very rare in modern infrastructure but a critical fail when it happens.
Check 11: TLS certificate validity
The IP must support TLS for SMTP submission with a valid certificate. The certificate should match the PTR-derived hostname for proper validation.
The check connects to port 25 with STARTTLS, then port 587, then port 465 (SMTPS). For each, we verify the certificate validity, expiration date, chain trust, and hostname alignment.
Failure rate: about 3-5%. Many failures are self-signed certificates or expired certificates that need replacement before customer use.
Check 12: Sending domain history correlation
For IPs we have visibility into, we check what sending domains have been associated with the IP in the recent past. This catches situations where the IP was used for a specific sender’s mail and may carry their reputation forward.
The check uses our internal IP-to-domain correlation database, accumulated from observation over time.
Failure rate: variable. Most IPs have no specific concerning history. IPs that do show patterns (e.g., association with a domain we know to be problematic) are rejected.
Check 13: rDNS pattern analysis
Beyond FCrDNS configuration, the pattern of the PTR record matters. PTRs that look like residential broadband, generic VPS, or other patterns that receivers correlate with spam sources will get filtered regardless of other indicators.
Patterns we reject:
pool-xxx-xxx-xxx-xxx.broadband-provider.tldvps-12345.generic-provider.tldxx.xx.xx.xx.unassigned.provider.tld- Patterns matching known compromise victim signatures
Failure rate: about 8-12%. Many providers default to generic PTR records that need customization.
We do not reject IPs with generic PTRs; we require the customer to specify a custom PTR before the IP enters service. The check produces a flag rather than a rejection.
Check 14: Netblock and ASN reputation analysis
The final check looks at the broader context. The IP’s specific reputation may be clean, but the netblock or AS containing the IP may have reputation issues.
The check examines:
- ASN-level abuse history (using AbuseIX, AbuseIPDB, or similar)
- /24 netblock reputation (correlated reputation of all IPs in the /24)
- Hosting provider known issues
- Geographic clustering of abuse from this network
Failure rate at the threshold we set: about 5-7%.
This check is the most subjective. ASNs with mixed reputation can produce false rejections. We use this check as a strong signal but combine with other indicators rather than treating it as automatic rejection.
The cumulative failure rate
Running all 14 checks against newly acquired IPs, the cumulative failure rate is approximately 15-22%. About one in five IPs from typical acquisition sources fails at least one check.
The failure distribution:
About 5-7% fail at the basic blocklist checks (Spamhaus, SURBL, CBL, UCEPROTECT). These are the obvious contamination cases.
About 6-9% fail at the historical reputation checks (SNDS, postmaster history). These are less obvious but operationally meaningful.
About 4-7% fail at the configuration checks (PTR, TLS, rDNS pattern). These are remediation candidates rather than outright failures; some can be fixed before use.
About 2-4% fail at the netblock/ASN context check. These are judgment calls more than automatic rejections.
Most IPs that fail one check also fail others. About 6-8% of IPs fail multiple categories of checks; these are the deeply contaminated ones that we reject without negotiation.
The economics of pre-flight
The 14-check process takes 15-25 minutes per IP. Most checks are automated. Some checks (PTR pattern analysis, netblock context) require human judgment.
The cost per IP: roughly 15-30 minutes of automated process time plus 5-10 minutes of human review time. At engineering rates, this is roughly €15-25 per IP in operational cost.
The benefit per IP: avoiding a problematic IP entering customer service. The cost of a problematic IP in customer service includes deliverability remediation work (typically 10-20 hours), customer relationship impact, opportunity cost of customer attention diverted from their core operation, and IP replacement work later.
The avoided cost per problematic IP: €1,500-€5,000 depending on customer scale and how quickly the problem surfaces.
The ratio: pre-flight cost is 1-3% of the avoided remediation cost. The economic case is overwhelming. The reason most operators do not do this rigorously is that the pre-flight cost is concentrated and visible while the avoided cost is distributed and invisible.
What happens to rejected IPs
IPs that fail pre-flight do not go into customer service. What we do with them varies.
Hard rejections
IPs failing blocklist checks (Spamhaus, etc.) are returned to the provider for replacement. The provider may dispute (claiming the listing is incorrect) but we do not accept replacements until the listing is resolved.
Soft rejections
IPs failing configuration checks (PTR, TLS) are flagged for remediation. If the issues can be fixed (custom PTR added, TLS certificate installed, etc.), the IP re-runs through pre-flight after remediation.
Quarantine
IPs with mixed indicators (some clean, some concerning) go into quarantine for additional analysis. We send test mail through them at low volume to specific seed addresses for 7-14 days. The seed results inform whether the IP can enter customer service.
About 70% of quarantined IPs eventually clear and enter service. About 30% are returned or repurposed for non-customer-facing use (internal testing, etc.).
The provider relationships
Pre-flight reveals provider quality differences. Across the providers we use:
Some providers consistently deliver IPs with low failure rates (under 5%). These providers maintain better internal IP pool hygiene and rotation practices.
Some providers have high failure rates (20-30%). The IPs they assign are essentially recycled without proper quarantine. Working with these providers requires extensive pre-flight discipline.
Some providers have failure rate variance correlated with specific IP ranges. They may have multiple /24 netblocks with different histories. Working with these providers requires netblock-aware acquisition.
We rank our providers by pre-flight quality and route acquisition accordingly. Customer assignments preferentially come from high-quality providers. Lower-quality providers serve niche needs where their IP characteristics match specific requirements.
What pre-flight does not catch
Pre-flight checks are not perfect. Several issue categories slip through.
Recent contamination
If an IP became contaminated very recently (last 24-48 hours), the blocklists may not yet reflect the contamination. The IP passes pre-flight but emerges as problematic in early customer use.
The remediation: continued monitoring during the first 30 days of customer use. Catching the late-surfacing contamination quickly limits the impact.
Reputation by association
If the IP is in a netblock where most IPs have problems, but this specific IP is clean, the broader reputation can still affect deliverability. Receivers sometimes apply netblock-level penalties even when specific IPs are clean.
The remediation: warmup with engagement-focused targeting. Building reputation despite the netblock disadvantage takes longer but is achievable.
Future contamination from customer behavior
The IP is clean when assigned but the customer’s sending behavior contaminates it. Sending to high-complaint lists, content patterns that trigger filters, or volume patterns that look like abuse all damage the IP’s reputation.
The remediation: customer education, content review, list hygiene assessment. The pre-flight clean state was not the issue; the post-assignment behavior was.
Provider-side changes after assignment
The provider changes routing, peering, or other infrastructure that affects how the IP appears to receivers. This is rare but happens.
The remediation: continued monitoring, alerting on reputation changes that do not correlate with customer behavior, communication with the provider about changes.
The disclosure to customers
We disclose our pre-flight process to customers explicitly during onboarding. Several reasons:
Setting expectations. Customers understand that the IPs assigned to them have passed substantive review, not just basic checks.
Building trust. The disclosure demonstrates operational rigor, which customers value when their business depends on deliverability.
Managing expectations on the small portion that still has issues. When something does emerge despite pre-flight, customers understand that the process is not bulletproof and remediation is part of the operational relationship.
Differentiating from providers who do less. Customer evaluations of providers often miss the IP allocation discipline. Explicit disclosure of our process helps customers understand what they are paying for.
The disclosure document we share with customers includes the 14 checks, the failure rates we observe, what we do with rejected IPs, and what the customer can expect in terms of IP quality.
The internal documentation we maintain
Pre-flight produces data we maintain internally for operational improvement.
The IP quality database. Every IP we have evaluated, its check results, its assignment history, and any post-assignment incidents. Years of accumulated data inform our provider ranking and quarantine decisions.
The pattern database. Patterns we observe across many IPs (specific PTR signatures, specific netblock behaviors, specific provider tendencies) become rules in our automated checking. The system improves over time as patterns are catalogued.
The post-mortem database. When pre-flight misses something and an IP emerges as problematic, we document the gap. The gaps become potential additions to the pre-flight checks or refinements of existing checks.
The provider quality database. Provider-level statistics on IP quality drive our acquisition decisions. Providers with degrading quality get reduced acquisition; providers with improving quality get expanded acquisition.
The honest limitations
The pre-flight process is not a guarantee of customer deliverability. Several caveats apply.
The checks reflect what is known about the IP at the time of evaluation. New information emerging later (new blocklist entries, new patterns identified) can change the IP’s actual reputation.
The checks correlate with deliverability but do not determine it. A clean IP delivered through poor sending practice will have deliverability problems. A contaminated IP delivered through excellent sending practice will have deliverability problems regardless of practice.
The checks have judgment elements. Some checks (especially netblock and ASN analysis) require human interpretation. Different operators may apply different thresholds.
The checks do not address all reputation factors. Sender reputation, domain reputation, content reputation all matter beyond IP reputation. Pre-flight handles the IP dimension; other dimensions require other practices.
What we recommend other operators consider
For other operators handling their own IP allocations, several elements of our process generalize.
Start with the blocklist checks. They are cheap, fast, and catch the worst cases. Failing to run these is operational negligence.
Add Microsoft SNDS to the check set. The data is informative beyond what blocklists show. The API access is free and the integration is bounded.
Verify FCrDNS and TLS. These are configuration issues that produce real deliverability impact and are easy to check.
Build a quarantine process. Not every IP needs to be either accepted or rejected immediately. Some IPs benefit from observation before committing to customer use.
Document the process. The discipline of writing down what you check produces gaps that become improvements. Tribal knowledge of “check the IPs carefully” is less reliable than documented procedure.
Track outcomes. Which IPs that passed pre-flight had problems? Which IPs that were borderline rejections turned out fine? The outcomes data informs process improvement.
Build provider relationships. The providers you acquire from matter as much as the checks you run. Long-term relationships with quality-conscious providers produce better baseline IP quality than chasing the cheapest acquisition source.
The customer-facing outcome
For our customers, the pre-flight process is mostly invisible. They receive IPs that work. They warm those IPs through standard procedures. They build reputation and deliverability over time. They do not encounter the failure modes that the pre-flight prevented.
The visible part: when we tell a customer their IPs are ready in 24-48 hours after order, the 24-48 hours includes the pre-flight time. The IPs are not provisioned and immediately delivered; they are evaluated and then delivered.
The customers who understand the process appreciate it. The customers who do not understand the process appreciate the outcome (working IPs from day one) without necessarily understanding the mechanism.
The operational philosophy: customer-facing deliverability quality requires upstream operational discipline. The pre-flight checks are one element of that discipline. Other elements include monitoring, response to emerging issues, ongoing IP pool management, and customer practice support. The 14 checks are not the whole picture; they are the starting point.
For other operators considering this kind of operational rigor: the investment is real, the benefits are real, and the customers who benefit may not always thank you. The thank-you is the absence of problems that other providers’ customers experience. That absence is what good IP allocation produces, and it requires more than five seconds of Spamhaus checking to achieve.