How to diagnose and fix email delivery failures after DNS changes (Exim + BIND)

DNS changes can break inbound mail while local sending still appears normal. This runbook was used to recover delivery by validating each layer in order, with evidence-based checks.

1) Incident pattern#

1. internal send works
2. external inbound fails
3. bounces or missing messages
4. Exim queue accumulates defers/frozen entries

Log watch:

tail -f /var/log/exim_mainlog | egrep -i "defer|frozen|dns|host lookup|retry"

2) Validate authoritative BIND zone first#

named-checkzone domain.com.br /var/named/domain.com.br.db

Common faults:

• SOA serial not incremented
• missing trailing dot in FQDN
• MX host without valid A/AAAA
• NS mismatch against registrar delegation

Apply and verify:

rndc reload
rndc status

3) Validate local authoritative answers#

dig @127.0.0.1 MX domain.com.br +short
dig @127.0.0.1 NS domain.com.br +short
dig @127.0.0.1 A mail.domain.com.br +short

4) Trace external delegation and propagation#

dig MX domain.com.br +trace
dig NS domain.com.br +trace

Cross-check public resolvers:

dig @8.8.8.8 MX domain.com.br +short
dig @1.1.1.1 MX domain.com.br +short
dig @9.9.9.9 MX domain.com.br +short

5) Audit Exim queue during transition window#

exiqgrep -r "@domain.com.br"
exiqgrep -r "@domain.com.br" -c
exim -Mvh MESSAGE_ID
exim -Mvl MESSAGE_ID
exim -Mt MESSAGE_ID
exim -qff
exiqgrep -z -i

6) Frequent root causes in this incident class#

1. new MX configured but registrar still delegates old NS
2. MX target exists but A/AAAA missing
3. SMTP 25/tcp blocked on new host
4. retry/frozen queue items from transition timing

Port check:

nc -vz mail.domain.com.br 25

7) Recovery acceptance criteria#

1. zone check passes
2. authoritative local answers are correct
3. public resolvers converge to new MX
4. Exim queue drains without new DNS defers
5. external inbox tests succeed (at least two providers)

8) Prevention and best practices#

To prevent recurring delivery issues during infrastructure migrations, I follow these preventive measures:

1. DNS Pre-check: Always run zone validations before pushing changes to production.
2. TTL Management: Lower TTLs 48-72 hours before the scheduled change to speed up worldwide convergence.
3. Queue Monitoring: Maintain a close watch on the Exim queue for at least 60 minutes post-cutover.
4. External Validation: Always test inbound mail from at least two different major providers (e.g., Gmail and Outlook).

Technical conclusion#

Post-migration email failures are almost never "mysterious bugs." They are usually a quantifiable result of unconverged external delegation combined with an Exim queue stuck in a retry or frozen state. By following the BIND -> Trace -> Exim sequence, the root cause is identified rapidly, and the recovery process remains fully controlled and documented. This methodology ensures that the mail server's transition is transparent to end-users and technically sound for infrastructure audits.

See also

Email Anatomy of an email stuck in queue: mail server logs, domain typos, and Exim smarthost mechanics

Email Anatomy of a dangling pointer in Exim: debugging the "transport not found" error in cPanel with smarthost and SRS

Email The Exim black hole, DMARC alignment failures, and restoring IP reputation

This post is licensed under CC BY-NC.