Configure Postfix DNSBL Logging with dnsblog

You will configure Postfix to ask a DNS allow or denylist service about connecting IP addresses, then verify that matches are logged by dnsblog. The examples use Postfix 3.8.6 from the installed postfix package and its local dnsblog(8postfix) manual page. Allow about twenty minutes, plus the time needed to choose a DNSBL whose terms and operational impact you understand.

This guide assumes a Postfix host with postscreen in use and permission to edit /etc/postfix/main.cf. Reading configuration and logs is normally unprivileged where the host permits it. Editing Postfix configuration and reloading the service require elevated privileges. The examples do not send test mail or change access restrictions beyond the setting you choose.

1. Confirm the installed service and defaults

Check the binary and package version first. These are ordinary, read-only commands:

$ command -v postconf
/usr/sbin/postconf
$ dpkg-query -W -f='${Package} ${Version}\n' postfix
postfix 3.8.6-1ubuntu0.1
$ postconf mail_version
mail_version = 3.8.6

The installed manual describes dnsblog as a short-lived Postfix server that receives a DNS allow or denylist domain, an IP address and an ID over an internal connection. It logs a match and returns the matching address list and TTL to its caller. It is not a general-purpose command-line DNS lookup tool, so do not expect dnsblog example.org 192.0.2.10 to be a supported test.

Checkpoint: inspect the current DNSBL setting before changing it:

$ postconf postscreen_dnsbl_sites
postscreen_dnsbl_sites =

An empty value means this host currently has no configured DNS allow or denylist sites. Your output may contain one or more entries. Keep a copy of it if you need an exact rollback.

2. Choose a DNSBL entry deliberately

The setting is postscreen_dnsbl_sites. The local dnsblog manual identifies it as the list of optional DNS allow or denylist domains, filters and weight factors; the detailed entry syntax belongs to postconf(5) and the postscreen documentation. A simple site name is the least surprising starting point:

$ postconf -h postscreen_dnsbl_sites
$ man 5 postconf
$ man 8 postscreen

Do not paste the placeholder DNSBL_DOMAIN.example into production. Replace it with a service that explicitly permits your intended queries. Check its query limits, response policy, privacy terms and removal process first. A DNSBL outage or an unsuitable list can make legitimate SMTP clients slower or cause the wrong mail-handling decision.

At this point, record the previous value and the exact entry you plan to use:

$ OLD_DNSBL_SITES=$(postconf -h postscreen_dnsbl_sites)
$ printf 'old setting: %s\n' "$OLD_DNSBL_SITES"
old setting:
$ NEW_DNSBL_SITE='DNSBL_DOMAIN.example'
$ printf 'planned site: %s\n' "$NEW_DNSBL_SITE"
planned site: DNSBL_DOMAIN.example

The variable is only a shell convenience. It does not alter Postfix. If you use more than one site or a weighted/filter expression, copy the syntax from the installed postconf(5) and postscreen(8) documentation rather than guessing separators or weights.

3. Apply the setting with a recoverable edit

Back up the configuration file before editing. This is an elevated command and creates a local copy; choose a protected backup location suitable for your host:

# cp --preserve=mode,ownership,timestamps /etc/postfix/main.cf /etc/postfix/main.cf.before-dnsblog

Now set the complete value with postconf. The command updates main.cf; it does not contact the DNSBL and it does not reload Postfix:

# postconf -e 'postscreen_dnsbl_sites = DNSBL_DOMAIN.example'
# postconf postscreen_dnsbl_sites
postscreen_dnsbl_sites = DNSBL_DOMAIN.example

Replace the example domain before running the command. If you already have useful entries, do not overwrite them blindly. Use the value captured in step 2 as the starting point and edit it to the intended complete list. The setting is configuration state, so there is no safe reason to rely on shell history as your only backup.

4. Validate and reload Postfix

Check the configuration syntax before asking the running service to pick it up:

# postfix check
# postconf -h postscreen_dnsbl_sites
DNSBL_DOMAIN.example

postfix check reports configuration or permission problems when it finds them. A successful check does not prove that the selected DNSBL is reachable or that it gives useful answers.

The manual says changes to main.cf are picked up automatically because dnsblog processes run for a limited time, and that postfix reload speeds up a change. Reloading is service-affecting, although it is normally brief:

# postfix reload
postfix/postfix-script: refreshing the Postfix mail system

Do not restart Postfix merely to apply this setting. If the reload fails, keep the backup and inspect the reported error before attempting another change.

Checkpoint: read back the live configuration after the reload:

$ postconf -h postscreen_dnsbl_sites
DNSBL_DOMAIN.example

5. Find dnsblog evidence in the logs

dnsblog sends problems and transactions to the system logger, either syslogd or postlogd. The precise file depends on the host's logging configuration. Search the journal first on a system using systemd:

$ sudo journalctl -u postfix --since '10 minutes ago' --no-pager | grep -i dnsblog
$ sudo journalctl -u postfix --since '10 minutes ago' --no-pager | grep -Ei 'dnsbl|postscreen'

Use elevated access only if the journal requires it. On a traditional syslog setup, inspect the mail log configured by the host, commonly with a command such as:

$ sudo grep -Ei 'dnsblog|dnsbl|postscreen' /var/log/mail.log

An empty search is not proof that the configuration failed. dnsblog is used when a postscreen DNS allow or denylist lookup occurs, and the local manual says a match is logged. If there has been no relevant postscreen traffic, there may be no transaction to find. Avoid generating unsolicited SMTP traffic merely to force a log line; use a controlled test client and a maintenance window if your service policy permits one.

Log wording, timestamps and the selected address list are host- and list-dependent. Treat an observed DNSBL match as evidence about that lookup, not as proof that every message from the address is abusive.

6. Roll back or disable the lookup

Before changing a live mail service, warn anyone responsible for mail flow. To restore the exact previous setting without replacing the whole file, use the value recorded in step 2. For the original empty setting, the explicit rollback is:

# postconf -e 'postscreen_dnsbl_sites ='
# postfix check
# postfix reload
# postconf -h postscreen_dnsbl_sites

The final command should print an empty line. If you need to recover other edits as well, stop and compare /etc/postfix/main.cf with /etc/postfix/main.cf.before-dnsblog before restoring anything. Do not copy an old full configuration over a live file without reviewing changes made since the backup.

Once the new setting has been checked and the rollback window has passed, remove the backup only if your normal retention policy allows it. Deleting the only recovery copy is irreversible, so it is intentionally not part of the command sequence.

Common traps

• Testing the wrong interface: dnsblog is an internal Postfix service, not a standalone DNS query utility. Test the configured workflow through postscreen and its logs.
• Confusing configuration with activation: postconf -e writes main.cf; postfix reload asks running Postfix processes to notice it.
• Assuming an empty log means a bad setup: no matching postscreen lookup means there may be no dnsblog transaction to report.
• Using a DNSBL without checking its policy: query permission, rate limits and response semantics are part of the service you are choosing, not defaults supplied by Postfix.
• Overwriting existing entries: postconf -e sets the complete parameter value. Preserve and review existing entries before replacing them.