Blacklist monitoring

What blacklist monitoring does

Email blocklists (DNSBLs / RBLs) are DNS-based lists that mailbox providers and filters consult when deciding whether to accept mail. A single listing can cause widespread deferrals or spam-folder placement. SenderSignal queries the same public DNS zones those filters use from outside your network, so you see listing status before your bounce rate spikes.

When checks run

• Immediately when you add an asset (manual or bulk import)
• On the schedule defined in Monitor rules (org default or per-asset override)
• On demand when you click Rescan on an asset

What we query

Each vendor publishes a DNS zone or API feed. To test whether 203.0.113.5 is listed, SenderSignal performs a DNS lookup against that vendor's zone using the vendor's documented query format (typically reversed-octet IP or domain-prefixed hostname).

• Listed: the DNS query returns an A record (or TXT) indicating listing
• Clean: the query returns NXDOMAIN or a documented “not listed” response
• Timeout / error / blocked query: shown separately. These do not count as listings. Inconclusive zones add a small uncertainty penalty (see scoring below).

Vendor tiers and your plan

Not every plan includes every vendor. Starter tiers focus on high-impact global DNS lists; higher tiers add Spamhaus DQS, Abusix, IPQualityScore, Talos, and other API feeds. Your asset Blacklists tab only shows vendors included in your subscription.

Listed vs delisted alerts

SenderSignal compares each scan to the previous scan for the same asset:

• Newly listed: vendor was clean, now listed → alert (if enabled)
• Delisted: vendor was listed, now clean → alert (if enabled)
• Still listed: no new alert (avoids noise)

See Alerts overview for notification setup.

Domains vs IPs

Blacklist reputation score (0–100)

The Blacklists tab and asset overview show a reputation score starting at 100. Only confirmed listings deduct points. Delisting on the next clean scan restores those points.

Formula

per_listing_deduction = weight × severity_multiplier × confidence_multiplier × confidence_weight

total_deduction   = sum of all listed zones (rounded)
inconclusive_penalty = min(0.5 × inconclusive_zones, 5)

reputation_score  = 100 − total_deduction − ceil(inconclusive_penalty)

Scoring factors

Additional API signal penalties

Signal severity in the UI

After rounding, each listing is classified for display:

Worked example

IP listed on Spamhaus ZEN (weight 25) and SpamCop (weight 18)
Both at high confidence (×0.9):

  ZEN:     25 × 1.0 × 1.0 × 0.9 = 22.5 → 23 points
  SpamCop: 18 × 1.0 × 1.0 × 0.9 = 16.2 → 16 points
  Total deduction: 39
  Reputation score: 100 − 39 = 61

Same IP also on Spamhaus PBL (weight 10, severity ×0.2):
  PBL: 10 × 0.2 × 1.0 × 0.9 = 1.8 → 2 points (informational)

The Typical deduction column in the tables below assumes high confidence (×0.9) and default severity. Your actual score uses live resolver confidence and may differ slightly.

IP blacklist vendors (39)

Query pattern: {reversed-ip}.{zone}

Domain & URI blacklist vendors (10)

Query pattern: {domain}.{zone}

Multi-asset & API feeds (6)

These vendors check via API (not DNS A-record). Weights apply when the feed reports a threat; GSB and high-fraud IPQS also use the fixed penalties in the table above.

Both IP and domain capable

Vendors marked both in the catalog are queried according to asset type:

Relationship to deliverability score

The blacklist reputation score above is separate from the deliverability health score. Blacklist listings also feed IP composite reputation dimensions and can trigger score-drop alerts on the Monitor overview. A clean blacklist score does not guarantee inbox placement if SPF/DMARC/DKIM policy is weak.

What to do when listed

1. Open the vendor row in the Blacklists tab: note the list name and response code.
2. Follow the vendor's delisting URL (linked when available).
3. Fix the root cause (compromised account, open relay, spam trap hit) before requesting removal.
4. Rescan after DNS/list propagation: History should show delisted.

Accuracy & limitations

• We query live DNS (the same mechanism receivers use), not cached third-party APIs alone.
• A timeout or blocked query is not a false “clean”; we surface it explicitly.
• URIBL and SURBL require an authorized resolver. Public DNS may return blocked-query codes that we mark inconclusive, not listed.
• Some vendors rate-limit aggressive polling; your plan interval balances speed vs vendor policy.
• DNSBL listing does not guarantee Gmail or Microsoft will block you, but it is a leading indicator.

Deliverability scoring model →