The server IP is on a blocklist

When to use: a dnsbl alert appears on the dashboard — its key is dnsbl:<zone> for PUBLIC_IP, dnsbl6:<zone> for the IPv6 address (raised only while outbound mail leaves over IPv6; the steps are the same, and Spamhaus’s lookup takes the IPv6 address) — a receiver bounces with blocked using zen.spamhaus.org (or similar), or Server reputation shows a zone as listed. Preconditions: admin access; the ability to log in to the blocklist’s removal form from a browser.

Steps

1. Find the cause before delisting — listings recur if the cause remains. Check, in order:
   • Audit log for recently created mailboxes or password resets you did not expect;
   • an outbound_abuse alert, which names the compromised mailbox for you — containment watches whether a mailbox’s outbound mail is being refused (Compromised-mailbox containment). By default it only alerts, so the mailbox is probably still sending. Stop it immediately by suspending the mailbox. Settings → Reputation protection → Block automatically is not a per-mailbox button: it is a server-wide setting, off by default, that lets the sweep (every 10 minutes, OUTBOUND_ABUSE_INTERVAL_MINUTES) block any mailbox that meets the thresholds — arming it blocks this one on the next sweep at the earliest. Once you have reset its password, restore sending from Domains → the domain → the mailbox → Restore sending — restoring without a password reset just gets it blocked again on the next sweep;
   • the Delivery log (filter Reputation block / Hard bounce, last day) and the Postfix queue (docker exec mailserver-postfix-1 postqueue -p | tail) for hundreds of messages from one sender that containment has not caught — the sweep needs 20 finished attempts in the window, so a slow trickle stays under it. Flush queued mail with postsuper -d ALL inside the postfix container only if you are sure;
   • open forwarders to free-mail providers (forwarded spam counts against you — mail we forward is SRS-rewritten and ARC-sealed, ARC sealing (forwarded mail), but forwarded spam still counts against us);
   • the rDNS row on the dashboard: a missing/mismatched PTR is itself a listing reason on some lists.
2. Open the request delisting link on the alert (or the delistUrl from GET /api/v1/server/reputation) and follow the list’s procedure. Spamhaus and Barracuda delist within minutes to hours once the cause is described; SpamCop listings expire on their own after ~24 h without new reports.
3. Wait for the next hourly check. Restarting the worker does not bring it forward — the schedule is kept in Redis. To check sooner, lower REPUTATION_CHECK_INTERVAL_MINUTES in .env and recreate the worker (docker compose … up -d worker): a changed interval resets the schedule and runs the check straight away. Put it back the same way afterwards. The alert auto-resolves once the zone answers clean.

Verification

Dashboard Server reputation shows every zone ok; the dnsbl:* alert is resolved; a test message to a Gmail address lands in the inbox with Authentication-Results: … spf=pass dkim=pass.

Rollback

Not applicable — nothing on the server changes. If you suspended a mailbox in step 1, unsuspend it after its password was reset.