DNSBL Reference — Response Codes, Severity Tiers, and the Right Order to Fix Listings

A DNSBL listing is one of the highest-impact email infrastructure events. The error message you see — bounce code, reduced delivery rate, sudden drop in inbox placement — is the symptom. The DNSBL response code is the diagnosis. This reference maps every response code from the 12 DNSBLs that matter in 2026, ranks them by real-world impact on Outlook/Microsoft 365, Gmail, Yahoo, Apple iCloud, and enterprise filters; gives you the exact remediation sequence per listing type; and walks through the SCBL scoring math and SNDS color decoding that most guides skip.

Severity tiers — which DNSBLs actually matter

Not every DNSBL listing matters equally. Understanding which DNSBLs are queried by which receivers is the foundation of any remediation prioritization.

Spamhaus is the central datapoint of email reputation infrastructure. Spamhaus data protects approximately 3 billion mailboxes globally. Apple iCloud, Microsoft (Outlook.com, Hotmail, Live, MSN), Yahoo, Proofpoint, Rackspace, and Cloudmark all directly query Spamhaus zones to decide what gets through and what gets rejected. The SBL alone maintains 30,000-40,000 active listings at any given time, manually curated by an OSINT research team.

Gmail is the consequential exception. Gmail does not directly query Spamhaus, Barracuda, or any external DNSBL. Gmail runs its own internal reputation systems built on engagement signals (open rates, marks-as-spam, marks-as-not-spam), authentication signals (SPF/DKIM/DMARC alignment), and behavioral patterns (sending velocity, recipient patterns). However — and this is the critical operational implication — the behavior that gets you listed on Spamhaus also damages your Gmail reputation independently, because both detect the same underlying signals. A Spamhaus listing is a leading indicator of a Gmail reputation collapse that's already in progress.

Response codes — what 127.0.0.x actually means

When a DNSBL query returns a response code, the IPv4 last octet identifies the listing reason. The same code 127.0.0.2 means different things on different DNSBLs. This is the most common source of operational mistakes — admins assume the code is universal. It isn't.

The cross-reference below maps every commonly-seen response code to its meaning per major DNSBL. Use it when interpreting parallel multi-DNSBL queries — you'll often see different codes back from different lists for the same listed IP, and each one tells a different operational story.

Real-world ISP impact by listing type

Not every Spamhaus listing causes the same delivery failure. The receiver determines severity. Below is the measured impact of each listing type across the major receivers that consume DNSBL data, based on aggregated 2026 deliverability research and our own client infrastructure observations.

SNDS color decoding — what Microsoft's reputation actually says

Microsoft's Smart Network Data Services (SNDS) is the most-misunderstood data point in deliverability. It is not a DNSBL — Microsoft does not publish a queryable blocklist. SNDS is Microsoft's internal reputation portal showing how their consumer mail filters (Outlook.com, Hotmail, Live.com, MSN) treat your sending IP. Important caveat: SNDS does not cover Office 365, Microsoft 365 Business, or Exchange Online — only Microsoft's consumer domains, which represent roughly 15-20% of recipients overall, but a higher percentage for transactional and consumer-marketing senders.

SNDS reports a Filter Result color status that summarizes how Microsoft's filters are treating your traffic over a 24-hour aggregation window. The thresholds and operational meanings:

Key SNDS thresholds beyond color status:

• Complaint rate: Microsoft considers above 0.3% problematic. Below 0.1% is healthy. Above 0.5% triggers immediate filtering escalation.
• Spam trap hits: any non-zero count is concerning. Microsoft uses both pristine traps (never-real addresses) and recycled traps (formerly real, abandoned). Pristine trap hits indicate list scraping or purchase. Recycled trap hits indicate inadequate engagement-based list hygiene.
• Volume threshold: SNDS only displays data for IPs that send at least 100 messages per day to Microsoft consumer domains.
• Data delay: 24-48h after sending. Acting on yesterday's SNDS data tomorrow morning is the appropriate cadence.
• URL change in May 2026: SNDS migrates to a new URL as part of a service update. The current site at sendersupport.olc.protection.outlook.com will be deprecated.

The relationship between SNDS color and Spamhaus listings is sequential, not causal. Microsoft does not query Spamhaus directly to set SNDS color. But the underlying signals that trigger a Spamhaus SBL listing (high complaint rates, spam trap hits, sudden volume spikes from a new IP, content patterns matching known spam) are the same signals Microsoft's filters use independently. In practice, an SBL listing typically pushes SNDS color from Green to Yellow within hours and to Red within 24-48 hours — not because SNDS reads Spamhaus, but because Microsoft's filters are detecting the same underlying behavior.

SpamCop scoring math — exactly how SCBL decides to list you

SpamCop is the most transparent of the major DNSBLs in how it weights reports — and the math is unambiguous. Understanding the formula explains why SCBL listings are sometimes brief (12 hours) and sometimes seemingly endless (weeks for chronic offenders).

The SCBL scoring rules (per the official SpamCop and Cisco Mailgun documentation):

• Reports are weighted by recency. Reports for mail received within the last few hours count 4:1 compared to reports for mail received 48 hours ago. Beyond 48 hours, weighting decreases linearly to 1:1.
• Reports for mail received more than one week ago are completely ignored.
• Spamtrap reports are weighted heavily. For up to 5 spamtrap reports, the weighted score is 5 × spamtrap_count + user_reports. Above 5 spamtrap reports, the weighting squares the spamtrap count: spamtrap_count² + user_reports.
• Reputation points (the inverse — positive sending behavior over time) offset the report score. SpamCop maintains an internal balance between threshold and reputation that's manually tuned to minimize false positives.

Concrete examples from SCBL documentation:

• 2 spamtrap reports + 3 user reports → weighted score = (2 × 5) + 3 = 13
• 10 spamtrap reports + 0 user reports → weighted score = 10² = 100 (spamtrap squaring kicks in)
• 0 spamtrap reports + 50 user reports → weighted score = 0 + 50 = 50 (high but recoverable)

Operational implication: a single spamtrap hit costs you 5x more than a user complaint, and the cost grows quadratically once you exceed 5 spamtrap hits. This is why list hygiene — specifically, sunsetting non-engaged subscribers before they become recycled spamtraps — is the single most impactful prevention practice. The SpamCop SCBL also explicitly states that bounces sent to SpamCop spamtraps trigger listings — even for servers that accept-then-bounce rather than rejecting at SMTP. Postfix and qmail configurations doing post-acceptance bouncing are particularly exposed.

Remediation workflows — by DNSBL

The right order matters. Each DNSBL has a different listing-removal process, and some (Barracuda, Spamhaus) penalize premature delisting requests by extending the listing duration.

Post-delisting reputation recovery — the curve nobody shows you

Removal from a DNSBL is not the end of the operational impact. Major receivers track listing events as part of their internal reputation scoring — sometimes for weeks. This is the recovery curve that most playbooks skip and that determines whether your delisting investment actually translates to recovered inbox placement.

How to check a DNSBL listing manually

Every DNSBL is queryable via simple DNS lookup. The IP being checked is reversed (octets in opposite order) and prepended to the DNSBL hostname. Below is the exact command for each major DNSBL using dig:

For IPv6 addresses, the format is more verbose. The IPv6 address is expanded to its full 32-character hexadecimal form, each character is reversed (in nibble order), and dots are inserted between every character. Example for IPv6 2001:db8::1:

For rapid multi-DNSBL checks across all 12+ major lists in parallel, use our IP Blacklist Checker tool. For domain-based blocklist queries (DBL, SURBL, URIBL), use our Domain Blacklist Checker. For Spamhaus-specific deep diagnostics, the official check.spamhaus.org Reputation Checker breaks down ZEN composite hits into the underlying sub-list and provides the recommended removal order.

IP-based vs domain-based vs URL-based DNSBLs

An often-overlooked distinction: most DNSBLs check IP addresses, but Spamhaus DBL, SURBL, and URIBL check domains found in message body. A clean IP can still trigger spam folder placement if the URLs in your email body are listed. Worse, a single compromised redirector domain on your sending infrastructure can affect all sends, regardless of IP reputation.

Prevention — operational practices that keep you off DNSBLs

The single most effective DNSBL prevention is operational hygiene. The following practices, drawn from incident analysis across multiple client environments, reduce the probability of any listing event by an order of magnitude:

Authentication baseline (non-negotiable)

• SPF with strict alignment, including all sending sources (CRM, transactional, marketing). Verify with TXT record audit; fix flattening when nested includes exceed 10 lookups.
• DKIM signing every outbound message with key rotation every 6-12 months. RSA-2048 minimum; ED25519 dual-signing for forward compatibility.
• DMARC at minimum p=quarantine pct=100 (preferably p=reject after monitoring period). DMARC reports parsed and acted on weekly. Report aggregation via tools like Postmark DMARC Digests, dmarcian, or Valimail.
• ARC for forwarded mail through mailing lists. Increasingly important for receivers to trust forwarded authentication chains.
• BIMI with VMC for high-trust brands — not a deliverability requirement but signals trust to receivers and recipients.

List hygiene (the most impactful prevention)

• Permission-based collection only. Double opt-in for marketing, single opt-in with confirmation for transactional. No purchased lists, no scraped contacts, no "found in our database" cold lists.
• Sunset policies. Suppress addresses with no engagement (open or click) for 90 days for B2C marketing, 180 days for B2B, 365 days for transactional. Recycled addresses become spamtraps; SCBL squares spamtrap weight above 5 hits.
• Hard bounce removal within one campaign. Soft bounces escalating to hard at 4 attempts. Catch-all domains identified and segmented to lower-volume/lower-cadence sending.
• Annual re-engagement campaigns for dormant addresses to identify deliverable-but-uninterested recipients before they become spam traps.

Complaint feedback infrastructure

• All Tier 1 ISP FBLs registered. Microsoft SNDS + Junk Mail Reporting Program (JMRP). Yahoo Complaint Feedback Loop. AOL/Verizon. Comcast. Apple iCloud (limited public FBL).
• Auto-suppress on complaint within minutes. Manual review queue is for false-positive analysis only — never delay suppression to investigate.
• Complaint rate alerting at 0.1% (warning), 0.3% (action required), 0.5% (suspend campaign immediately).

Engagement segmentation

• Separate IP pools for cold/prospecting vs warm/engaged vs reactivation. New addresses on probation IPs that don't share with main sending pool.
• Volume isolation — reduces blast radius of any reputation event. A bad campaign on the prospecting IP doesn't drag down transactional delivery on the warm IP.
• Pre-send engagement filtering for marketing campaigns: send to engaged-in-last-30-days first, then 31-90 days, then dormant. Adjust frequency by tier.

Continuous monitoring

• Daily DNSBL checks across all major lists for every sending IP. Multi-DNSBL parallel checks via API or CLI tooling — manual checks every Monday at 9am won't catch a Tuesday afternoon listing.
• 5-minute alerting on any new listing. Most damage from a Spamhaus listing happens in the first 24-72 hours of unawareness.
• SNDS color tracking for Microsoft consumer domains. Yellow status investigation within 24h. Red status pause within 1h.
• Google Postmaster Tools for Gmail domain reputation tracking. Domain-level signals appear here before they translate to obvious deliverability symptoms.

Cloud Server for Email's managed infrastructure includes proactive DNSBL monitoring across 50+ lists with 5-minute alert SLAs, FBL registration with all Tier 1 ISPs, automated complaint-suppression on all sending IPs, and deliverability incident response that includes Spamhaus delisting coordination. We've operated dedicated email infrastructure since 2015 — these practices are encoded in our standard operating procedure, not optional add-ons. Talk to us if reputation engineering at scale is the constraint you're trying to solve.

Frequently asked questions

Which DNSBL listing should I fix first?

Spamhaus first. SBL, XBL, and CSS listings cause near-total delivery shutdown to Microsoft (Outlook.com, Hotmail), Apple iCloud, Yahoo, Proofpoint, Rackspace, and Cloudmark — collectively about 60-65% of consumer and B2B mailboxes outside Gmail's ecosystem. Barracuda BRBL is second priority because it backs millions of enterprise mail filters globally. SpamCop SCBL is third — auto-expires in 24-48h but reputation drag persists. SORBS, UCEPROTECT, and regional lists last.

Does Gmail use Spamhaus to filter mail?

No. Gmail runs its own internal reputation systems and does not directly query Spamhaus, Barracuda, or SpamCop. However, Gmail factors blacklist events into its own scoring through correlated signals (low engagement, complaint patterns, spam trap behavior) that mirror what those DNSBLs detect. The behavior that gets you listed on Spamhaus also damages your Gmail reputation independently — the listing is a leading indicator, not the cause.

What does response code 127.0.0.2 mean?

It depends on the DNSBL queried. On Spamhaus ZEN it means SBL (manually verified spam source). On Barracuda BRBL it means listed in their reputation database. On SpamCop SCBL it means recent user-reported spam exceeded threshold. On SORBS it depends on the specific zone. The same code 127.0.0.2 carries different operational meaning across providers — never assume universality. Always check the documentation for the specific DNSBL returning the code.

Should I request delisting before fixing the root cause?

Never. Spamhaus penalizes premature removal requests by extending the listing duration. Barracuda denies repeat removal requests for IPs that re-list within days. SpamCop ignores manual delisting requests entirely (auto-expire only). The fix is always: (1) identify root cause, (2) remediate, (3) confirm clean sending for 24-48h minimum, (4) only then submit removal request. Submitting before fixing makes future removals significantly harder.

How do I check if my IP is on a DNSBL?

From command line: dig A 1.2.0.192.zen.spamhaus.org (replacing 1.2.0.192 with your IP reversed). NXDOMAIN response means not listed. A 127.0.0.x response identifies the listing reason. For multi-DNSBL parallel checks, use our IP Blacklist Checker tool. For Spamhaus, the official check.spamhaus.org Reputation Checker shows which underlying sub-list triggered a ZEN hit and provides the required removal order.

Can a third-party service expedite Spamhaus delisting?

No. Any service charging for Spamhaus delisting is a scam — Spamhaus is explicit: removal is always free, no third party has special access. Same for Barracuda BRBL, SpamCop, and SORBS. UCEPROTECT charges for express delisting (€20-100), but most reputable mail admins refuse to use UCEPROTECT data anyway. If you're being pitched paid delisting, the seller is misrepresenting their capability.

How long does Spamhaus listing recovery take after delisting?

Delisting itself: minutes to 24h after a valid removal request with the root cause fixed. Reputation recovery: 7-30 days depending on volume and ISP. Microsoft Outlook tracks IPs for weeks after delisting through SNDS color regression. Gmail's internal scoring takes 14-30 days of clean sending to fully recover. On shared hosting where IP neighbors continue sending spam, staying delisted can take up to three months.

Is SpamCop's 24-hour auto-expiry guaranteed?

No — and this is widely misunderstood. The 12-24h figure applies to a first-offense listing where reports stop arriving immediately. Each new spam report resets the clock. SCBL applies a 4:1 weighting to recent reports versus older ones, and squares spamtrap report counts above 5. Chronic offenders can stay listed indefinitely. The scoring math is unambiguous: stop the source completely or the listing won't expire.

What does SNDS color status mean for DNSBL listings?

SNDS colors are Microsoft's internal reputation, not DNSBL data. Green = less than 10% spam verdicts, Yellow = 10-90%, Red = greater than 90%. SNDS does not query Spamhaus or external DNSBLs — it reflects Microsoft's own filtering decisions. However, a Spamhaus SBL listing typically pushes SNDS color from Green to Yellow within hours and Red within 24-48h because Microsoft's filters react to the same signals Spamhaus detected. Treat SNDS as an early-warning system that complements DNSBL monitoring.

Are SORBS listings still relevant in 2026?

Less than Spamhaus and Barracuda, but still operationally relevant. SORBS feeds SpamAssassin defaults and Proofpoint enterprise filters. The dul.sorbs.net (dynamic IP) zone catches misconfigured sending from residential ranges — a common enterprise mistake. The relays.sorbs.net zone catches open relays — near-extinct configuration but still detected occasionally. Response time on removal requests is slower (3-7 days typical), so monitor proactively rather than reactively.

What does the response code 127.255.255.x indicate?

These codes (Spamhaus only) indicate query errors, NOT reputation. 127.255.255.252 means typing error in the query, 127.255.255.254 means querying through an open public resolver (use your ISP's resolver instead, not 8.8.8.8 or 1.1.1.1), 127.255.255.255 means usage error. Software that interprets these as 'listed' is buggy and will reject legitimate mail.