DNS Blacklist (RBL)

The DNS Blacklist (RBL) check asks a set of DNS-based blocklists whether the IPv4 addresses you give it are listed. It is a mail-reputation check: receiving mail servers query the same lists during the SMTP handshake, so an address that is listed is usually having its mail rejected or deferred right now. The check runs on Windows, Linux, and macOS every 60 minutes on the agent; the interval is not user-configurable.

The check finds the problem. The fix always happens at the blocklist operator, never in octoja — see Getting an address delisted below.

Prerequisites

• The Monitoring Check Management permission (monitoring-checks.manage) to add or edit the check on a device or in a config package.
• A device running an octoja agent that resolves DNS through a resolver you control. This is the most common reason the check comes back with nothing useful — see the next section.
• Nothing to install anywhere. The check only issues outbound DNS queries; it needs no credentials and never touches the mail server itself.

Get these two things right first

Almost every unhelpful result from this check traces back to one of the following two inputs. Settle both before you look at any threshold.

1. Enter the public address the mail leaves from

IP addresses accepts IPv4 addresses only — no hostnames, no IPv6, no ranges. Anything that is not a valid IPv4 address is reported for that entry as Error with Invalid IPv4 address.

The address to enter is the one a receiving mail server sees on the connection: your outbound mail gateway's public address, or the firewall's NAT address if mail leaves the site directly. A mail server's internal LAN address is on no blocklist and will always come back clean — a green check that means nothing. If you are unsure which addresses belong in the list, the ip4: entries in your SPF record are usually the right set.

If outbound mail goes through a hosted service (Microsoft 365, Google Workspace, a provider's smart host), the sending addresses belong to that provider. Monitoring them tells you nothing you can act on — monitor the addresses you control.

2. Use a resolver the blocklists will answer

The lookups leave from the device the check is assigned to, using that device's DNS settings. Assign the check to a device running an octoja agent — that device's resolver is the one the blocklists see.

Blocklist operators do not answer everyone. Queries arriving through the large public resolvers — Google, Cloudflare, Quad9, OpenDNS and similar — are refused as a matter of policy, as are queries from resolvers that exceed an operator's free-use limits. That refusal is not an answer of "not listed": it comes back as a reserved answer in the 127.255.255.x range. octoja recognises those answers and reports Warning with Resolver blocked by the blocklist (use a private DNS resolver) instead of presenting the address as clean.

Assign the check to a device that resolves through a recursive resolver of your own — a domain controller or a local resolver that queries the authoritative servers itself — rather than one pointed at a public DNS service.

Settings

Blank entries in either list are ignored, and leading or trailing spaces and a trailing dot on a zone name are removed before the query is sent.

Up to eight addresses are queried at the same time. The zones for a single address are queried one after another, so one unresponsive address takes up to the number of zones multiplied by the timeout — 15 seconds with the three default zones at the default 5000 ms.

Which blocklists the check queries

Blocklist zones (RBL) comes pre-filled with three widely used zones. Every address is queried against every zone in the list.

You can add or remove zones freely — the field is a plain list of zone names. Two things are worth knowing before you rely on the defaults:

• Operators publish free-use limits and expect commercial or higher-volume users to move to a paid feed. Spamhaus's paid query service, for example, issues you a personal zone name, which you enter here in place of zen.spamhaus.org.
• Barracuda requires the querying resolver's public address to be registered with it. Until that is done, that zone contributes nothing to the result — and because octoja only reports a failed lookup when every zone for an address fails, one silent zone never shows up anywhere.

Results

Within one address, a listing outranks everything else: if any zone reports the address as listed, that address is Critical even when another zone refused the query or timed out. The overall check result is the worst single per-address result, ranked OK, then Warning, then Critical, then Error — so one invalid entry reports the whole check as Error even while another address is listed.

A single failing zone does not change the result. The check reports a failed lookup only when every zone for that address failed.

Per address, the check reports:

• The address, and whether it is listed
• The names of the zones that list it
• How many zones were queried for it
• The per-address result — OK, Warning, Critical or Error — and, where one applies, the reason: invalid address, resolver blocked, or lookup failed

The detail panel shows one card per address. The history view shows one row per run with the addresses that were not OK and the zones that listed them.

octoja records which zone listed an address, not the answer that zone returned. A policy listing covering a whole address range therefore looks exactly like a listing for sending spam — both are Critical. Look the address up at the operator to tell them apart.

Getting an address delisted

Delisting happens entirely at the blocklist operator. octoja has no influence over it and no way to request removal on your behalf.

1. Fix the cause before you ask for removal. Operators re-list within hours if the behaviour continues, and repeat self-removals are usually refused. The usual causes are a compromised mailbox relaying through your server, an unauthenticated submission path reachable from the internet, an infected client sharing the same public address, or an address that was never meant to deliver mail directly.
2. Look the address up at the operator that listed it. octoja records the zone name, not the answer the zone gave — it tells you where the address is listed, not why. Each operator's own lookup page names the specific list, the reason, and usually the supporting evidence.
3. Follow that operator's removal procedure. All three default zones offer self-service removal for at least some listing types. Expect one or more of: confirming from an address at the affected domain, a waiting period, or a requirement that the underlying problem is visibly resolved first.
4. Repair the surrounding hygiene while you are there. A valid PTR record for the sending address, a HELO/EHLO name that matches it, and working SPF, DKIM and DMARC records all feed into reputation — and some listings are statements about the address space rather than about any single message.
5. Confirm the removal on a fresh run. The check runs every 60 minutes on its own, and you can start a run straight away with the play button beside the check on the device's Checks tab — that button needs the Run Maintenance device action and is not offered for a check you have disabled. A device in a maintenance window that pauses checks refuses the run and says so. DNS caching can still hold the old answer for a while after the operator has already removed the entry.

Notes

Assigning this check widely multiplies your query volume against the operators and can push you past their free-use limits. One assignment per site, on a device with a suitable resolver, is normally enough — roll it out that way with a config package rather than adding it to every device.

See also: Checks · Assign checks with config packages