When DNS Breaks Email: Troubleshoot Mailu and Unbound

Technical review: 26 October 2026. Product names, licensing references and procedures reflect this review; check the linked documentation for your release.

An email rejected as “sender domain not found” can be a DNS problem inside the mail system even when public DNS looks correct. Mailu’s resolver is a separate dependency from the DNS server used by your laptop. Start with the SMTP rejection and trace the exact lookup path instead of immediately changing sender records or weakening validation.

Identify where delivery stopped

Read the SMTP log for the relevant attempt and timestamp. Distinguish a rejection before acceptance from a message accepted into the queue, filtered as spam or delivered elsewhere. Record the sender domain and response while keeping personal message content and addresses out of shared evidence.

For a sender-domain check, inspect the records the mail server actually requires. An empty A-record answer is not proof that the domain is unusable for mail when valid MX and associated target records exist. Also distinguish NXDOMAIN, an empty answer and SERVFAIL; they point toward different investigations.

Query the resolver the mail service uses

Confirm the configured resolver path from the running mail services. Docker’s embedded resolver address does not by itself tell you whether a validating Unbound service behind it is healthy. Query the relevant Unbound endpoint explicitly from an appropriate diagnostic context.

RESOLVER='192.0.2.53'  # Documentation address: replace with the actual resolver.
dig @"$RESOLVER" example.com MX +dnssec
dig @"$RESOLVER" . DNSKEY +dnssec

Use the affected domain rather than the example, and compare with an approved independent resolver. Inspect time synchronization, network reachability and the resolver logs. The presence of DNSSEC records in an answer is not by itself proof that validation succeeded; interpret flags and results in context.

Investigate trust-anchor and persistence problems

If the evidence points to DNSSEC validation, inspect the configured trust-anchor file and Unbound’s reported state. Stale or unusable anchor state, clock problems and blocked required lookups can all interfere with validation. Use the resolver/vendor-supported repair procedure and approved anchor sources for the installed release.

Do not make disabling DNSSEC the permanent fix. Before repairing files, back up the current configuration and ownership. Unbound’s automatic trust-anchor management needs a writable location and can update files using replacement/rename operations. A single-file bind mount can therefore behave differently from a normal file inside a writable directory.

Make recovery survive container recreation

Use the supported persistent-state design for the Mailu release, preserving the required directory contents and permissions rather than mounting an empty directory over a populated configuration path. A change that works inside one running container can disappear when the container is recreated.

• Verify the previously failing domain resolves correctly through the mail service’s actual path.
• Confirm a legitimate test message is accepted and delivered.
• Check that DNSSEC validation remains enabled.
• Recreate the affected test/deployment component through the approved process and verify persistence.

Record the observed cause and the scope of the successful test. Do not attribute every DNS failure to a key rollover without evidence. A short resolver dependency diagram and a tested backup are more useful for the next incident than a one-off command left only in shell history.

References

• Mailu: official troubleshooting guidance
• NLnet Labs: DNSSEC trust-anchor configuration
• NLnet Labs: unbound-anchor behavior