DNS blocklist recovery

Fix the cause before requesting removal. A successful form submission without remediation is temporary at best and can make later requests harder. Start by pausing the affected traffic, preserving logs, checking for compromised accounts or applications, reviewing recent recipients and complaints, and confirming PTR, EHLO, forward DNS, SPF, DKIM, and DMARC.

Owlat quarantines an outbound IP only for a confirmed Spamhaus listing. Barracuda, SpamCop, and optional Abusix checks are warning signals: investigate them, but they do not automatically starve the pool. A resolver error is never treated as a listing or a delisting.

Spamhaus

1. Open the Spamhaus IP and Domain Reputation Checker from a network associated with the IP. Do not use a VPN for a removal request.
2. Identify the returned list/code. CSS is 127.0.0.3 through the SBL/Zen zone; 127.255.255.x answers are resolver/configuration errors, not listings.
3. For CSS, verify a meaningful PTR exists, PTR resolves forward to the same IP, the SMTP EHLO matches that host, the machine is not compromised, wildcard DNS does not expose unexpected hosts, and list acquisition/consent is sound.
4. Remove malicious queued mail, close the compromise, and correct list hygiene.
5. In the checker, explain what caused the traffic, what you fixed, when you fixed it, and what prevents recurrence. Removal is not guaranteed. CSS often expires after the last detection, but waiting without fixing the cause is not remediation.

Sources: Spamhaus CSS FAQ, DNSBL response codes, and removal-request guidance.

Barracuda

1. Confirm the IP in Barracuda Central and investigate the sending cause.
2. Correct the compromise, authentication, or recipient-quality issue first.
3. Submit one complete Barracuda Reputation System removal request with a valid contact and explanation. Multiple requests are ignored; Barracuda says complete requests are typically investigated within 12 hours.

SpamCop

1. Follow the evidence links in any SpamCop report and stop the reported mail.
2. Check for an open relay, compromised credential, infected host, or bad list source; remove queued abuse.
3. The SpamCop Blocking List is time-based and delists automatically after reports stop. Do not hunt for a manual fast-track that does not exist.

Sources: SpamCop Blocking List and SpamCop removal FAQ.

Abusix

Abusix is optional because its production DNS namespace requires a 32-character API key. When enabled, Owlat queries it as warning-only.

1. Open Abusix Lookup and Delisting and inspect the specific list/reason.
2. Fix the indicated abuse or policy/rDNS problem.
3. Sign in to request delisting. Abusix says removals are processed immediately, with DNS propagation normally completing within minutes; a recurring cause will be observed and listed again.

Sources: Abusix production zones and delisting overview.

Pre-flight IP audit

Before an operator invests hours in DNS, the MTA audits every configured sending address — at install and daily thereafter — and reduces the result to one of three plainly-worded verdicts:

The audit covers four things: outbound TCP/25 egress (probed against several independent MX hosts, because most providers block it by dropping packets rather than refusing them), the blocklists — Spamhaus ZEN decoded into SBL/CSS/XBL/PBL/DROP, Barracuda, SpamCop, SORBS, and the credential-gated Invaluement and Abusix feeds — forward-confirmed reverse DNS, and a sample of the surrounding /24. A neighbourhood where most sampled addresses are listed is treated as unusable: IP-heavy filters score the range, not just the address.

Two rules keep it honest. A resolver that does not answer produces unknown, never clean; the verdict then asks for a re-run and the report is marked low-confidence. And a feed whose credential is absent is simply skipped — it neither lowers the verdict nor raises a warning.

GET /ip-audit returns the stored audits with a delisting assistant attached to every listing found: the zone-specific removal URL, the likely cause derived from recent sending metrics, and a pre-filled removal request. POST /ip-audit/run requests a fresh sweep, serving a sweep from the last few minutes rather than re-probing (each run opens TCP/25 connections from the sending IP). The audit is advisory throughout: it never quarantines an address and never blocks a send. Only the shipped DNSBL sweep does that, and only for a confirmed Spamhaus listing.

Before you pick a VPS

GET /ip-audit/provider-note/:provider returns a short factual note per provider: whether outbound port 25 is open, needs a request after some account tenure, or is blocked outright, and whether that provider's ranges commonly arrive already listed.

In the installer

owlat-setup doctor reads GET /ip-audit and prints one SEND PATH line per sending address: the verdict headline, its next action, and the removal URL for each listing found. An unusable address fails doctor, so the installer cannot proceed silently on an address that will never deliver; action_required prints the delisting path and passes. If the MTA has not audited anything yet, or the endpoint is unreachable, doctor prints nothing — the audit is advisory and its absence is a supported configuration.