A blocklist entry is a symptom, not the root cause. Your sending IP appeared on Spamhaus, SpamCop, SORBS, or a provider-internal list because something in your mail stream triggered their detection. Delisting requests fail or the IP is relisted within hours until you identify and stop that activity.

The first sign is usually deferrals spiking against one provider, bounces climbing, and the deferred queue growing while injection holds steady. Two patterns dominate: sudden listing from a compromised account or spam outbreak flooding garbage through your server, and gradual erosion from chronic issues like bad recipient lists, backscatter, or weak authentication accumulating negative reputation signals over weeks until a threshold is crossed. The diagnostic path differs for each.

What this means

Receiving MTAs reject or defer your connections before mail is accepted. The mechanism is DNS-based: the receiving server reverses your IP, appends it to the blocklist domain, and if the query returns an A record, the connection is refused with a 5xx (permanent) or 4xx (deferral) SMTP code.

Spamhaus ZEN is a composite query combining SBL (spam sources), XBL (compromised systems), and PBL (policy violations) in a single lookup. Provider-internal lists at Google, Microsoft, and Yahoo are not publicly queryable. You discover them through delivery error codes, complaint feedback loops, or reputation dashboards.

The damage compounds. Deferred mail retries with exponential backoff, so the queue grows. If the root cause is still active, new spam continues flowing, generating more complaints that deepen the listing. Recovery requires stopping the root cause, requesting delisting, then letting the queue drain through normal retry cycles.

Common causes

CauseWhat it looks likeFirst thing to check
Compromised submission accountSudden volume spike from one authenticated sender, SASL connections from unexpected IPsgrep 'sasl_method' /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -rn
Backscatter from spoofed mailBounce storm to forged sender addresses, MAILER-DAEMON dominating queuepostqueue -p | grep -c MAILER-DAEMON
Bad recipient listHigh bounce rate with “user unknown” 5xx codes, concentrated on specific domainsgrep 'status=bounced' /var/log/mail.log | grep -oE 'host [^[]+' | sort | uniq -c
Content triggering destination filtersLegitimate mail rejected with policy 5xx from specific providers, FBL complaints risingCheck bounce reason codes in logs
Open relay or weak restrictionsUnauthorized relay to external destinations without authenticationpostconf -h smtpd_relay_restrictions smtpd_recipient_restrictions

Quick checks

These are safe, read-only commands for initial triage.

# Check deferred queue size and growth
find /var/spool/postfix/deferred -type f | wc -l

# Identify which destinations are deferring the most mail
grep 'status=deferred' /var/log/mail.log | awk -F'to=<|>,' '{print $2}' | cut -d@ -f2 | sort | uniq -c | sort -rn | head

# Count bounces in the last hour
grep "$(date -d '1 hour ago' '+%b %e %H')" /var/log/mail.log | grep -c 'status=bounced'

# Check for 5xx rejection codes from specific providers
grep 'status=bounced' /var/log/mail.log | grep -oE 'said: 5[0-9][0-9]' | sort | uniq -c | sort -rn

# Check for MAILER-DAEMON dominating the queue (backscatter indicator)
postqueue -p | awk '/MAILER-DAEMON/ {count++} END {print count}'

# Check SASL authentication patterns for compromise
grep 'sasl_method' /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head

# Check your receiving-side RBL configuration
postconf -h smtpd_recipient_restrictions | tr ',' '\n' | grep rbl

# Test outbound connectivity to a major provider
timeout 10 bash -c 'echo QUIT | nc -w5 gmail-smtp-in.l.google.com 25'

To check whether your IP is listed on public DNSBLs, query the blocklist DNS directly. Spamhaus now requires registered access (DQS) for production use; direct queries via public resolvers may return empty or inaccurate results.

# Check Spamhaus ZEN listing (replace 192.0.2.1 with your IP)
# Reverse octets and append .zen.spamhaus.org
dig 2.0.192.1.zen.spamhaus.org A +short

<!-- TODO: verify whether Spamhaus still accepts unauthenticated public DNS queries or requires DQS key for all production checks -->

# Multi-RBL check via dig against common lists
for rbl in zen.spamhaus.org bl.spamcop.net dnsbl.sorbs.net; do
  echo -n "$rbl: "
  dig 2.0.192.1.$rbl A +short
done

How to diagnose it

Answer three questions in order: Is the IP actually listed? Which provider(s) are affected? What caused the listing?

flowchart TD
    A["Deferrals/bounces spike"] --> B{"One provider or all?"}
    B -->|One provider| C["Check provider blocklist / FBL"]
    B -->|All destinations| D["Check public DNSBL + DNS health"]
    C --> E{"Listed or throttled?"}
    D --> E
    E -->|Listed| F["Identify root cause"]
    E -->|Throttled| G["Check rate limits / greylisting"]
    F --> H["Compromised account?"]
    F --> I["Backscatter?"]
    F --> J["Bad recipient list?"]
    H --> K["Lock account, rotate credentials"]
    I --> L["Reject unknown recipients, publish SPF/DMARC"]
    J --> M["Clean list, validate before send"]
    K --> N["Request delisting"]
    L --> N
    M --> N

  1. Confirm the listing. Query the major public DNSBLs (Spamhaus ZEN, SpamCop, SORBS). If results are clean but one provider is still blocking, the issue is a provider-internal list. Check Google Postmaster Tools and Microsoft SNDS for reputation data.

  2. Scope the blast radius. Determine whether all destinations are affected (public DNSBL listing) or just one provider (internal list). Parse deferred and bounced messages by destination domain. If 90% of deferrals concentrate on one provider, that provider is throttling or blocking you specifically.

  3. Find the root cause. This is the critical step. A delisting request without fixing the cause will fail or result in immediate relisting. Check for:

    • Compromised SASL accounts sending spam through your submission port
    • Backscatter: your server accepting mail for unknown recipients and generating bounce messages to forged sender addresses
    • Bad recipient lists generating high bounce rates
    • Content patterns triggering destination spam filters

  4. Stop the bleeding. Ensure the root cause activity has stopped before requesting delisting. Spamhaus will not process delisting until the underlying activity ceases. SBL listings require manual review (typically 24-72 hours). XBL delisting is automated once the compromise is resolved. PBL delisting is self-service for legitimate mail servers.

  5. Request delisting. Submit through the appropriate portal. Document what you fixed and when. Keep log excerpts and configuration changes for the submission.

  6. Drain the queue carefully. Do not flush the entire deferred queue at once. Mass retries to a provider that just unblocked you can trigger rate limiting and re-blocking. Let the normal retry schedule drain the queue, or release messages in small batches using postsuper -r on filtered subsets.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
Bounce rate (% of injection)High bounce rate triggers blocklist listings and erodes sender reputation>1% sustained for transactional mail, >5% acute
Deferred rate by destinationConcentrated deferrals on one provider signal throttling or blocking>20% to a single domain over 1 hour
Deferred queue growth rateVelocity of queue growth indicates severity and whether the problem is activeSustained positive growth over 4 hours
SASL auth failuresBrute force attempts may precede account compromise>10x baseline failures from single IP
Complaint rate (FBL)Direct signal from providers about user-marked spamAbove 0.1% for bulk senders
Injection vs delivery ratioDivergence indicates mail is entering but not leavingDelivery rate <50% of injection for 10+ minutes

Fixes

Compromised submission account

Lock the account immediately and rotate its SASL credentials. Review submission logs to identify all messages sent through the account during the compromise window. Remove spam from the active and deferred queues before it reaches destinations:

# Identify messages from the compromised sender in the queue
postqueue -p | grep 'compromised@yourdomain.com'

# Hold those messages (safer than deleting; review first)
# awk tracks queue IDs from lines starting with hex, prints when sender matches
postqueue -p | awk '/^[A-F0-9]/ {id=$1} /compromised@yourdomain\.com/ {print id}' | sort -u | tr -d '!*' | postsuper -h -

Verify that submission traffic on port 587 requires authentication (permit_sasl_authenticated). Add per-sender rate limits on the submission port to catch future outbreaks early.

Backscatter

Backscatter happens when your server accepts mail for invalid recipients, then generates bounce messages to forged sender addresses. The fix is recipient validation before queue acceptance.

# Check if recipient validation is configured
postconf -h relay_recipient_maps local_recipient_maps

If you operate a relay or gateway, maintain a current relay_recipient_maps table so Postfix rejects unknown recipients at SMTP time with a 5xx code instead of accepting and bouncing later. Publish SPF and DMARC records for your domain to prevent spoofing of your sender addresses. A DMARC policy of at least p=none with aggregate reporting helps you detect spoofing volume.

Bad recipient lists

High bounce rates from invalid addresses are one of the fastest paths to a blocklist. If a mail stream is generating bounces above 1%, stop sending to that list. Verify addresses exist before adding them to lists, and suppress addresses that have bounced.

# Count bounces to a specific domain
grep 'status=bounced.*example.com' /var/log/mail.log | wc -l

Clean your lists before resuming sends. Segment by engagement and suppress inactive recipients.

Provider-internal blocks (Google, Microsoft)

Provider-internal blocks do not show up in public DNSBL queries. You discover them through delivery error codes (typically 4xx or 5xx with provider-specific messages) and reputation dashboards.

For Google, check Postmaster Tools. For Microsoft, check SNDS and submit delisting requests through the provider’s portal. Microsoft maintains separate blocklists for consumer (Outlook.com) and business (Microsoft 365) destinations; an IP can be blocked for one but not the other.

Prevention

Monitor reputation weekly. Check Spamhaus, SpamCop, and provider dashboards on a schedule. Do not wait for a customer complaint to discover a listing.

Alert on bounce rate. Sustained bounce rate above 1% should trigger investigation; above 5% is an active problem. Bounce rate monitoring is distinct from delivery failure monitoring because bounces count as “successful” in simple delivery metrics.

Validate recipients before acceptance. Reject unknown recipients at SMTP time to prevent backscatter and keep the queue clean.

Publish and enforce authentication. SPF, DKIM, and DMARC are baseline requirements for bulk senders. Gmail and Yahoo require authentication for senders delivering 5,000+ messages per day. Microsoft applied similar requirements starting May 2025. A DMARC policy of p=reject with proper alignment prevents spoofing of your domain.

Rate-limit per sender. A compromised account can send thousands of messages in minutes. Per-sender rate limits on the submission port contain the blast radius.

Implement complaint feedback loops. Subscribe to FBL programs from major providers. Complaint rate above 0.1% damages deliverability. FBL data gives you the earliest warning that your mail is being marked as spam.

How Netdata helps

  • Per-second queue metrics let you see deferred queue growth within seconds of when it starts, not minutes later when a cron-based check catches it.
  • Bounce rate as a derived signal surfaces the percentage of messages bouncing, not just raw counts. Correlating bounce spikes with deferred queue growth confirms whether a reputation problem is developing.
  • Per-destination deferral breakdowns show when one provider starts deferring disproportionately, often the first sign of a provider-internal block before any public DNSBL listing appears.
  • SASL authentication monitoring tracks failed and successful auth patterns. A spike in successful auth from unexpected IPs, combined with a volume anomaly, points to account compromise before spam reaches destinations.
  • Mail flow velocity correlation (injection vs delivery rate) makes it immediately visible when delivery is collapsing while injection continues, which is the signature of a blocklist event in progress.