Postfix Host or domain name not found: DNS name service errors deferring mail

Mail is piling up in the deferred queue. Postfix logs the same deferral repeatedly:

status=deferred (Host or domain name not found. Name service error for name=example.com type=MX: Host not found, try again)

The enhanced status code is 4.4.3 (directory server failure). Postfix will retry, but retries keep producing the same error because the resolver is broken, not the destination.

The key tell: all destinations are affected equally. If Gmail, Outlook, and a corporate partner all fail with “Host not found” at the same time, your resolver is the problem. If only one domain fails, that is a real DNS issue at the destination.

The critical trap: Postfix often uses a different resolver path than your interactive tools. dig and host may work from your shell while Postfix defers everything, because the smtp delivery process reads a different resolv.conf or runs in a chroot jail your shell does not share.

What the error means

Postfix relies on DNS for MX record lookups, reverse PTR verification, and DNSBL queries. When the resolver cannot return an answer, Postfix defers the message with a 4.4.3 DSN. Temporary DNS failures should defer, not bounce. The problem is that the resolver never recovers on its own.

The deferral string breaks down as follows:

• “Host or domain name not found” is the human-readable summary.
• “Name service error for name=<domain> type=<RR>” shows which query failed. For outbound delivery, type=MX is the most common.
• “Host not found, try again” indicates a temporary failure (SERVFAIL or timeout). This differs from “Host not found” without “try again”, which is NXDOMAIN (permanent). The “try again” suffix is what makes Postfix defer rather than bounce.

The root cause is almost always one of: the resolver process is down, Postfix’s chroot jail has a stale copy of resolv.conf, SELinux is silently blocking the read, the resolver returns SERVFAIL on DNSSEC validation, or inet_protocols triggers IPv6 connection attempts that fail on hosts without IPv6 connectivity. A failed AAAA lookup is not the issue here: with inet_protocols=all and no usable IPv6 route, the AAAA lookup succeeds but the IPv6 connect attempt fails, so the deferral shows connect to <host>[<ipv6-address>]:25: Network is unreachable at connection time, not a name service error.

flowchart TD
    A["All destinations deferring
Host not found, try again"] --> B{"dig works
from shell?"}
    B -- No --> C["Resolver process
down or unreachable"]
    B -- Yes --> D{"Postfix chrooted?
check master.cf"}
    D -- Yes --> E["Stale resolv.conf
in chroot jail"]
    D -- No --> F{"SELinux
enabled?"}
    F -- Yes --> G["AVC denial on
resolv.conf read"]
    F -- No --> H["Check DNSSEC
SERVFAIL"]

Common causes

Quick checks

# Count which domains are deferring and how many times
grep 'status=deferred.*Host not found' /var/log/mail.log \
  | grep -oP 'name=\K[^ ]+' | sort | uniq -c | sort -rn | head -20

# Test MX resolution from the shell
dig example.com MX

# Test against the nameserver configured in resolv.conf
dig @$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf) example.com MX

# Check whether the smtp delivery agent runs chrooted (5th field: y = chrooted)
grep '^smtp' /etc/postfix/master.cf

# If chrooted, compare system and chroot resolv.conf
diff /etc/resolv.conf /var/spool/postfix/etc/resolv.conf

# Check resolver process health
systemctl status systemd-resolved

# Check SELinux AVC denials related to resolv.conf
sudo ausearch -m AVC -ts recent 2>/dev/null | grep -i resolv

# Test DNSSEC validation path
dig +dnssec example.com MX

# Check inet_protocols setting
postconf -h inet_protocols

# Check DNS-related Postfix configuration
postconf -h smtp_host_lookup smtp_dns_support_level disable_dns_lookups

How to diagnose

1. Confirm the scope. If the deferral hits every destination domain, you have a resolver problem. If it hits one or a few, investigate those domains individually. The grep command in Quick checks counts deferrals by name= field and tells you immediately.

2. Test DNS from the shell. Run dig example.com MX for a domain you know is valid. If it fails here, the resolver process or upstream connectivity is broken. Skip to step 5.

3. Determine if Postfix runs chrooted. Check master.cf: if the smtp delivery agent’s chroot column (5th field) is y, Postfix reads /var/spool/postfix/etc/resolv.conf, not /etc/resolv.conf. This file is copied at startup and is not updated by postfix reload.

4. If chrooted, compare the two resolv.conf files. If they differ, the chroot copy is stale. This is the most common cause after a DNS server change.

5. Check the resolver process. If dig fails from the shell, verify the resolver is running and responding. For systemd-resolved: systemctl status systemd-resolved. For named: pgrep -a named. For nscd: pgrep -a nscd.

6. Check for SELinux denials. On RHEL, CentOS, Fedora, and other SELinux-enabled systems, the smtp process may be denied read access to resolv.conf if the file has the wrong security context. Run sudo ausearch -m AVC -ts recent and look for denials involving resolv.conf or net_conf_t.

7. Test DNSSEC validation. Run dig +dnssec example.com MX. If you see SERVFAIL, the resolver is failing DNSSEC validation for domains that should resolve. This is common with systemd-resolved when DNSSEC is enabled and upstream responses fail validation.

8. Check inet_protocols. If inet_protocols=all and your server has no working IPv6 connectivity, Postfix attempts IPv6 connections that fail with “Network is unreachable” or hang until timeout. These failures show up at connection time in the deferral reason, not as name service errors.

Metrics and signals to monitor

Fixes

Stale chroot resolv.conf

If Postfix runs chrooted and /var/spool/postfix/etc/resolv.conf differs from /etc/resolv.conf, the chroot copy is stale. This happens after any DNS server change: someone updates /etc/resolv.conf, runs postfix reload, and assumes Postfix picks up the new nameservers. It does not. A reload does not copy files into the chroot.

# Full restart to sync chroot files (not reload).
# WARNING: this briefly stops all mail processing.
postfix stop && postfix start

On systemd-managed systems, systemctl restart postfix performs the same full restart. Verify after restart:

diff /etc/resolv.conf /var/spool/postfix/etc/resolv.conf

If the files still differ, copy manually and reload:

cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
postfix reload

Resolver process down or unhealthy

If dig fails from the shell, the resolver itself is the problem. Restart it and check upstream connectivity:

systemctl restart systemd-resolved

# Verify the stub resolver answers
dig @127.0.0.53 example.com MX

# Check upstream reachability directly
dig @8.8.8.8 example.com MX

If you are running nscd as a caching layer, flush its DNS cache and restart:

nscd -i hosts
systemctl restart nscd

SELinux denying resolv.conf read

On SELinux-enabled systems, /etc/resolv.conf must have the net_conf_t context. If NetworkManager or another tool rewrote the file with the wrong context, the smtp process gets an AVC denial and cannot read it.

# Fix the context
sudo restorecon -v /etc/resolv.conf

# Verify
ls -Z /etc/resolv.conf

No Postfix restart is needed after restorecon; the next DNS lookup succeeds.

DNSSEC SERVFAIL

If dig +dnssec example.com MX returns SERVFAIL for domains that should resolve, the resolver’s DNSSEC validation is broken.

For systemd-resolved, check the configuration:

grep -i dnssec /etc/systemd/resolved.conf

# Compare stub resolver vs upstream
dig @127.0.0.53 example.com MX
dig @<upstream_dns> example.com MX

Workaround options:

• Set DNSSEC=no in /etc/systemd/resolved.conf and restart systemd-resolved (disables validation entirely).
• Bypass the stub resolver: set DNSStubListener=no in /etc/systemd/resolved.conf, then configure /etc/resolv.conf to point directly at upstream resolvers.
• If Postfix is using smtp_dns_support_level=dnssec for DANE, SERVFAIL on TLSA lookups will also defer mail. Verify whether DANE is required for the affected destinations.

IPv6 AAAA lookup failures

When inet_protocols=all, Postfix performs AAAA lookups alongside A lookups. If your server has no working IPv6 connectivity, the AAAA lookup itself usually succeeds but the IPv6 connection attempt fails with connect to <host>[<ipv6-address>]:25: Network is unreachable or times out.

# Restrict to IPv4 if you have no working IPv6
postconf -e 'inet_protocols=ipv4'
postfix reload

If you need IPv6, verify connectivity first:

# Test IPv6 connectivity to a DNS server
dig -6 @2001:4860:4860::8888 example.com MX

nsswitch.conf blocking DNS

If /etc/nsswitch.conf contains a hosts: line with mdns4_minimal [NOTFOUND=return] before dns, mDNS lookups that return NOTFOUND will short-circuit the resolution chain before DNS is consulted. This causes failures for any hostname not found via mDNS.

grep '^hosts' /etc/nsswitch.conf

Fix: ensure dns appears in the hosts line, and remove [NOTFOUND=return] if it prevents fallback:

hosts: files dns

Prevention

• Monitor the resolver independently from Postfix. DNS is Postfix’s single point of failure. Queue depth and delivery rate show the symptom; resolver health shows the cause.
• After any DNS server change, restart Postfix fully. A reload does not update chroot files.
• Run restorecon /etc/resolv.conf after any DNS configuration change on SELinux systems. NetworkManager and other tools can rewrite the file with the wrong context.
• Configure multiple nameserver entries in resolv.conf so a single upstream failure does not take out all resolution.
• Test DNSSEC validation paths after resolver or systemd updates. A resolver upgrade can change validation behavior and start returning SERVFAIL for previously working queries.
• Set inet_protocols=ipv4 unless you have verified IPv6 connectivity. This eliminates an entire class of AAAA-related failures.

How Netdata helps

• Per-second deferred queue metrics show the exact moment DNS failures begin causing mail to pile up.
• Correlating deferral rate spikes with DNS resolver latency or error rate changes confirms the root cause without manual log tracing.
• Active versus deferred queue comparison reveals the characteristic pattern: active queue near empty (nothing deliverable), deferred queue climbing.
• Postfix log parsing surfaces deferral reason codes, making “Host not found” dominance visible across all destinations.
• System-level DNS resolver monitoring (process health, query latency, error rates) catches degradation before total failure.

Related guides

• Postfix deferred queue growing: why mail piles up and how to drain it
• Postfix connection timed out: delivery deferrals to unreachable destinations
• Postfix flushing and clearing the deferred queue: postqueue and postsuper
• How Postfix actually works in production: a mental model for operators
• Postfix monitoring checklist: the signals every production mail server needs
• Postfix connection refused: blocked port 25 and rejected outbound delivery