Operate Postfix verify(8) Without Filling the Mail Queue

You will finish with a checked Postfix address-verification service, a known cache location, and a safe way to change its expiry settings. You will also know what a verification result proves, and what it does not.

This guide uses Postfix 3.8.6 from Ubuntu package postfix 3.8.6-1ubuntu0.1. Allow about fifteen minutes. You need shell access and permission to read the Postfix configuration. Only the optional configuration change requires root.

1. Confirm the installed version and service

Run these read-only commands as your normal account. They show which package and Postfix service definition you are inspecting:

$ dpkg-query -W -f='${Package} ${Version}\n' postfix
postfix 3.8.6-1ubuntu0.1
$ postconf mail_version
mail_version = 3.8.6
$ postconf -M verify
verify     unix  -       -       y       -       1       verify

The exact package revision can differ after updates. The useful checks are that the package is installed, the reported mail version is the one you expect, and verify is present as a Postfix service. Do not run a bare verify command: this daemon is designed to run under master, not as an interactive utility.

2. Inspect the cache before changing anything

Address verification stores the status and explanatory text for an address in a persistent map. On this installation the effective settings are:

$ postconf -h address_verify_map address_verify_positive_expire_time \
    address_verify_positive_refresh_time address_verify_negative_cache \
    address_verify_negative_expire_time address_verify_negative_refresh_time \
    address_verify_cache_cleanup_interval
btree:$data_directory/verify_cache
31d
7d
yes
3d
3h
12h
$ postconf data_directory
data_directory = /var/lib/postfix

That expands to a btree cache under /var/lib/postfix. A successful result expires after 31 days and is refreshed after 7 days. Failed results are cached for 3 days and refreshed after 3 hours. Cleanup runs every 12 hours. These are time-to-live controls, not guarantees that every address is permanently correct.

3. Understand what causes a probe

A client service asks verify to query an address. If the cache has no current result, verify returns an in-progress status and injects a probe message into the Postfix queue. The probe follows routing and rewriting, but stops before final delivery. Postfix discards it rather than deferring or bouncing it.

This is not a complete test of the remote mailbox. The result depends on the nearest MTA's answer, so a permissive or misleading remote server can make an address look deliverable. Verification probes also create traffic and queue work. A dictionary attack or a flood of backscatter can load downstream servers; sender verification can cause some providers to denylist your site.

Use the normal Postfix logging path to investigate a request. The manpage says transactions and problems are logged to syslogd or postlogd. On a system using systemd, a read-only first check is:

$ sudo journalctl -u postfix --since '15 minutes ago' --no-pager

The sudo is for reading logs when your account lacks access. The log location and service name are host-specific. Search for the address or the verify service, but avoid pasting full recipient lists into shared terminals or tickets.

4. Change a cache policy only with a reason

The default cache policy is usually a reasonable starting point. A shorter negative expiry can be useful when remote recipient data changes quickly, but it makes Postfix repeat failed probes sooner. A longer expiry reduces probe traffic but keeps stale decisions for longer.

Changing main.cf is a persistent, service-affecting operation. Before doing it, choose one setting and write down its current value. The following example changes only the failed-result lifetime to two days:

$ postconf address_verify_negative_expire_time
address_verify_negative_expire_time = 3d
$ sudo postconf -e 'address_verify_negative_expire_time = 2d'
$ postconf address_verify_negative_expire_time
address_verify_negative_expire_time = 2d

Do not edit the cache database or delete it while Postfix is using it. The service keeps long-lived processes, so a main.cf change is not picked up automatically. Reload Postfix after checking the new value:

$ sudo postfix check
$ sudo postfix reload
$ postconf address_verify_negative_expire_time
address_verify_negative_expire_time = 2d

postfix check checks the configuration and permissions before the reload. Its successful output is normally empty; use its exit status as the check. The reload asks the master to reread configuration and does not discard the cache.

5. Undo the example if it was only a test

Restore the value you recorded in step 4, then check and reload again. This is the recovery path for the example above:

$ sudo postconf -e 'address_verify_negative_expire_time = 3d'
$ sudo postfix check
$ sudo postfix reload
$ postconf address_verify_negative_expire_time
address_verify_negative_expire_time = 3d

If you changed several settings, restore each one from its recorded value. If postfix check fails, do not reload. Read the error, correct the configuration, and run the check again. If a reload causes a service problem, inspect the Postfix logs and restore the last known-good setting before reloading once more.

6. Avoid the common traps

• Do not treat a positive result as proof of a real mailbox. It is an answer from the nearest MTA after Postfix's routing and rewriting path has been exercised.
• Do not expect a newly edited setting to work immediately. Reload is required because verify processes are long-lived.
• Do not move the map into an arbitrary directory. Postfix 2.5 and later open the cache without root privileges and expect it under the Postfix-owned data_directory; a legacy non-Postfix path may be redirected with a warning.
• Do not shorten every expiry value to solve a stale result. That increases probes and can amplify traffic. Change the smallest relevant setting, then measure logs and queue behaviour.
• Do not use root for read-only inspection. Reserve sudo for configuration changes, reloads, checks, and log access that your account cannot perform.