Weekly DNSBL Checks on Your Mail Server IP Before Bounces Start Piling Up

When a server IP lands on a blocklist, the first sign is rarely an alert. It is usually a handful of customers saying their emails to one or two big providers bounce, followed by more of the same over the next day. By then, a lot of mail has failed or is stuck in the queue. A short DNSBL check each week, against the IP that actually sends your mail, usually catches a listing before that happens. A DNSBL (DNS-based blocklist) is a list of IP addresses that a list operator considers a spam source, published through DNS so any mail server can query it quickly. Spamhaus, Barracuda, and SpamCop are common examples. Receiving servers check the connecting IP against one or more of these lists and reject or defer the message if it matches. The rest of this article follows the order a support engineer would use: start from the bounce, confirm it is a listing, find the real cause, then make the check routine.

What the bounce is actually telling you

Start with the bounce message, either from the customer's NDR (the non-delivery report they received) or from your own logs. Blocklist rejections usually come back as a permanent 5xx code, often 550 or 554, with an enhanced status such as 5.7.1. The text after the code matters more than the code itself, because 5.7.1 can also mean policy or authentication failures. On the sending server, search the log for blocklist wording instead of reading it line by line:

BASH

# Exim: cPanel path shown. Debian/Ubuntu Exim uses /var/log/exim4/mainlog
grep -Ei 'spamhaus|barracuda|spamcop|blocklist|blacklist|blocked using|listed' /var/log/exim_mainlog | tail -n 20

# Postfix: /var/log/mail.log on Debian/Ubuntu, /var/log/maillog on RHEL-family
grep -E 'status=(bounced|deferred)' /var/log/mail.log | grep -Ei 'spamhaus|barracuda|spamcop|listed|block' | tail -n 20

If your system only logs to journald, journalctl -u postfix or the Exim unit gives the same lines for you to filter. A blocklist rejection in Postfix typically looks like this:

TEXT

Illustrative output format:
postfix/smtp[12345]: 1A2B3C4D5E: to=<[email protected]>, relay=mx.example.net[198.51.100.10]:25, status=bounced (host mx.example.net[198.51.100.10] said: 550 5.7.1 Service unavailable; client [203.0.113.25] blocked using zen.spamhaus.org (in reply to RCPT TO command))

Two details in that line are worth noting. The list name (zen.spamhaus.org) tells you which operator to deal with. The client IP in brackets tells you which of your addresses the remote side saw. That second detail leads to the most common mistake.

Find the IP that really sends your mail

Many people check the server's main IP, find it clean, and stop. But the address that sends mail is not always the main one. A server can have several IPs, and the mail server may be told to use a specific one. On cPanel, outbound IPs can be mapped per domain through /etc/mailips when that option is enabled in WHM. In Postfix, smtp_bind_address decides it. Behind NAT, the public IP the internet sees may not be on any local interface at all. IPv6 also matters: if the server has IPv6 and the receiver accepts it, mail may go out over v6, and that address has its own reputation. The most reliable check is to trust the evidence. Use the client IP shown in the bounce, or send a test message to an external mailbox and read the topmost Received: header added by the receiving side. Whatever IP appears there is the one to check.

Query the blocklists the right way

A DNSBL query is a regular DNS lookup. You reverse the octets of the IPv4 address and append the list's zone. For 203.0.113.25 against Spamhaus, you look up 25.113.0.203.zen.spamhaus.org. If you get no answer (NXDOMAIN), the IP is not listed. If you get an address in 127.0.0.x, it is listed, and the last octet usually tells you which sub-list matched.

BASH

# Replace with the outbound IP you confirmed above
IP='203.0.113.25'
IFS=. read -r a b c d <<< "$IP"
for zone in zen.spamhaus.org b.barracudacentral.org bl.spamcop.net; do
  # A record = listed; TXT often explains why
  echo "== $zone"
  dig +short {d}.{c}.{b}.{a}.${zone} A
  dig +short {d}.{c}.{b}.{a}.${zone} TXT
done

Run this from a resolver you control, not a large public resolver. Spamhaus, for example, deliberately returns an error code in the 127.255.255.x range for queries that come through public or open resolvers, and that can look like a listing when it is not. Barracuda may also require the querying DNS server to be registered before it gives real answers. If you get a strange result, check whether it is a resolver problem before you open a delisting request. For Spamhaus Zen, the last octet helps you focus. Results in the SBL and CSS ranges point to spam actually seen from your IP. XBL usually means the IP showed signs of compromise or malware. PBL is different: it marks address space that the network owner says should not send mail directly, often dynamic or end-user ranges. A PBL hit on a server is a policy issue for the IP owner, not proof that you sent spam.

Ruling out the look-alikes

Not every 5.7.1 is a blocklist. Before you start the delisting process, confirm the bounce really names a list. A few patterns look similar but need a different fix. Authentication failures mention SPF, DKIM, or DMARC, or say the message is unauthenticated. The IP may be clean while the domain's records are broken. Reputation blocks from large mailbox providers often say the IP or domain has low reputation or that unsolicited mail was seen, without naming any public DNSBL. Those are internal to the provider, and a DNSBL lookup will come back clean. Temporary 4xx responses such as greylisting or rate limiting usually clear on retry and only become an issue if the queue keeps them for days. Local sending limits, like a per-domain hourly cap, show up in your own log as a local rejection and never reach the remote server. Also check the direction. A log line where your server rejected an incoming connection because the sender was listed is your own inbound filtering working as intended. It has nothing to do with your outbound reputation.

Delisting and confirming it worked

Once a listing is confirmed, fix the cause before you request removal. Most operators will relist an IP that keeps sending the same traffic, and repeat listings tend to be harder to clear. The usual causes on shared and VPS hosting are a compromised mailbox sending through authenticated SMTP, a vulnerable script sending through PHP mail, or a forwarder relaying spam it received. Look for a sudden jump in outbound volume from one account or one script path, stop it, change the credentials, and clear the junk from the queue. After that, use each operator's own lookup and removal page. Spamhaus and Barracuda both handle removal through their websites. SpamCop listings typically expire on their own once reports stop. PBL entries are handled by the IP owner, so on a VPS you may need your upstream provider to correct the range, or you can route mail through a relay with a clean reputation. Verification has two parts. Rerun the DNS query and confirm NXDOMAIN, keeping in mind that resolvers and receiving servers may cache the old answer for a while. Then watch the queue drain: exim -bpc shows the count on Exim, and postqueue -p lists deferred mail on Postfix. When the deferred messages to the affected providers start delivering and new bounces with the list name stop appearing in the log, you are done.

Making it a weekly habit

The query script above is enough for a routine check. Loop it over every outbound IP the server can use, including IPv6 if mail leaves over v6, and run it from cron once a week. Have it alert only when any query returns an answer, so a clean week stays quiet. Weekly is a reasonable baseline for a typical shared or VPS mail server. Servers that send a lot of mail, or host many unrelated customers, may be better off with a daily check, because one compromised account can get an IP listed within hours. If you have wondered why a check that was clean at setup is not enough, the reasons IP reputation changes over time are covered in Mengira Cek Blacklist IP Cukup Sekali Saat Setup Mail Server. The practical takeaway: check the IP that the bounces name, not the one you assume, and query through a resolver that blocklists will answer honestly. Read the list name and return code before you act, fix the sending cause before you request removal, and confirm with both a clean DNS result and a draining queue. A five-minute weekly job is much cheaper than a day of bounce tickets.