Why Inbound Mail Bounces After a DNSSEC Key Rollover Even With a Healthy Server

When senders report that mail to a domain is deferring or bouncing, the mail server is almost always the first suspect. Someone restarts Exim or Postfix, checks the queue, tests port 25, and everything looks fine. If the domain's DNS operator rolled its DNSSEC keys recently, the problem is often not on the mail server at all. The sending side cannot get a trustworthy answer for the MX record, so it never connects in the first place. This piece walks through that failure as a post-mortem: what the impact looks like, where the investigation usually goes wrong, the point where the real cause shows up, how to stop the damage, and what to change so the next rollover goes quietly. It describes a common pattern, not one specific incident.

Initial impact: deferrals that never reach your logs

The first signal usually comes from outside. Senders forward delayed-delivery notices, and a bit later some of them get hard bounces once their own server gives up retrying. On the receiving side, the mail logs show nothing unusual. The Exim or Postfix log has no rejections and no errors, and for the affected senders it has no connection attempts at all. That absence is the most useful clue, and it is easy to miss. A rejection means the sender reached you. Silence means the sender stopped before reaching you, and for mail that almost always means DNS. The second clue is that the problem is selective. Mail from some senders keeps arriving normally while other senders fail every time. This pattern makes people suspect blocklists or sender reputation. In this case it comes from a different source: some sending servers use resolvers that validate DNSSEC, and others use resolvers that do not. When a validating resolver cannot verify an answer, it does not return the unverified data. It returns SERVFAIL. A sending MTA treats SERVFAIL on an MX lookup as a temporary failure. It defers the message and retries on its normal schedule. If the failure lasts longer than the sender's queue lifetime, the message bounces. On a Postfix sender, the deferral looks roughly like this:

TEXT

# Illustrative output format (Postfix on the sending side)
postfix/smtp[PID]: QUEUEID: to=<[email protected]>, relay=none, delay=120, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=example.com type=MX: Host not found, try again)

The log has no remote IP and no SMTP response from your server. The phrase try again tells you the resolver failed temporarily. It does not mean the domain is missing.

Investigation: ruling out the parts that are healthy

The investigation usually loses time in two places. The first is the mail server. Services are up, disk and inodes are fine, the queue is normal, and a test message sent from another account on the same server delivers. Every check passes because the mail server really is healthy. In support, this is where a ticket tends to bounce between the mail team and the DNS team. The customer only sees that their email does not work, and the evidence on each side points somewhere else. The second is the MX record itself. Someone runs dig example.com MX from the hosting server or an online lookup tool and gets the correct answer. That seems to clear DNS. It does not, because the result depends on which resolver answered. Many server-local resolvers and lookup tools do not validate DNSSEC. Some return a cached answer from before the break. A plain lookup through a non-validating path only shows that the record exists, not that a validating resolver can trust it. The question that moves things forward is: what does a validating resolver say about this MX record?

The discovery: a SERVFAIL that disappears with +cd

The decisive test is to run the same query twice against a resolver you know validates. The first query uses normal settings. The second sets the CD (checking disabled) bit, which tells the resolver to skip DNSSEC validation and return whatever data it has. You can confirm that a resolver validates by querying a domain you know is signed and checking that the ad (authenticated data) flag appears in the response.

BASH

# Replace with a resolver you have confirmed validates DNSSEC
RESOLVER='192.0.2.53'

# Normal query: a validating resolver returns SERVFAIL if the chain is broken
dig example.com MX @$RESOLVER

# Same query with validation disabled (CD bit set)
dig example.com MX @$RESOLVER +cd

# Ask the validator to explain why validation fails
delv example.com MX

The failure fingerprint has two parts. The normal query returns status: SERVFAIL, and the +cd query returns NOERROR with your correct MX records. The data is fine, but the signatures do not verify. Newer versions of dig may also show an Extended DNS Error line that names the reason, if the resolver supports it. delv performs validation locally and reports where the chain breaks. The chain of trust explains why a key rollover causes this. Your zone has a Key Signing Key (KSK) that signs the zone's DNSKEY set, and that set contains the Zone Signing Key (ZSK) that signs everything else, including the MX record. The parent zone, meaning the TLD, publishes a DS (Delegation Signer) record: a hash of your KSK, which you submit through your registrar. A validator starts from the root, trusts the TLD, uses the DS to identify your KSK, and works down from there. If the DS does not match any KSK your nameservers publish, the chain stops at your zone and every record under it becomes bogus. That includes the MX, A, and TXT records. During a KSK rollover this mismatch usually happens in one of these ways:

The new KSK was published and the old KSK was removed, but the DS at the registrar still points to the old key.
The DS was updated before the new KSK had been published long enough for resolver caches to pick it up.
The submitted DS was generated from the wrong key, or uses a digest or algorithm that does not match.
The algorithm was changed without the required pre-publication stages.

Comparing the parent's DS with your published keys usually confirms which case you are dealing with:

BASH

# DS at the parent: the first field is the key tag
dig example.com DS +short

# DNSKEY set from your nameservers: flags 257 marks a KSK,
# and +multi prints each key's key id (key tag) in a comment
dig example.com DNSKEY +multi @$RESOLVER +cd

If the key tag in the DS record does not appear among your flag-257 keys, you have found the break. If it does appear, check the digest type and algorithm, and check whether the DNSKEY set has valid, unexpired signatures.

Temporary mitigation: make the chain match again

The goal is to get the DS and the published KSK back in agreement as quickly as possible. Do not change the MX record or the mail server, because neither one is the problem. You have three options, in order of preference:

Republish the old KSK. If the DS still points to the old key and you still have that key material, put it back into the DNSKEY set and sign with it. This is usually the fastest fix because it only depends on your own DNSKEY TTL, not the parent.
Update the DS at the registrar to match the new KSK. Use this when the old key is gone. Recovery then depends on how quickly the registry publishes the change and on the DS TTL at the parent, which the TLD sets and you cannot change.
Remove the DS entirely. This makes the zone unsigned from the validator's point of view. It is a last resort. It also waits on parent propagation, and it removes DNSSEC protection until you sign again properly.

Recovery is not instant everywhere. Validating resolvers can cache the bogus result or the failure for a while, and how long depends on the resolver, so some senders recover before others. Deferred mail delivers on its own the next time each sender retries, as long as it is still within that sender's queue lifetime. Mail that already bounced is gone. Affected senders need to know they must resend it, and telling them early saves a second round of support tickets.

The architectural fix: treat a rollover as a timed procedure

Most rollover outages come from steps that were done in the right order but too quickly, or from a step that was skipped because a different person or system owned it. RFC 7583 describes rollover timelines. The core rule is overlap. The new key must be visible in caches before the DS changes, and the old key must stay published until the old DS and DNSKEY records have expired from caches. Each wait is based on the TTLs involved, and the DS TTL is set by the parent, not by you. A few changes make this much harder to break:

Automate DS updates where possible. Some registries accept CDS or CDNSKEY records, which let the parent pick up the new DS from your zone instead of relying on someone to paste it into a registrar panel. Support varies by TLD and registrar, so check with yours rather than assuming it is available.
Make ownership explicit. If one team runs the signer and another holds the registrar login, the rollover plan must name who changes the DS and when. The same mismatch happens when a signed domain moves between DNS providers, which is covered in the article on SERVFAIL after moving a DNSSEC-signed domain to a new DNS provider.
Monitor validation, not just reachability. A check that connects to port 25 or loads the homepage stays green throughout this whole incident. Add an external check that resolves the MX record through a validating resolver and alerts on SERVFAIL, and use a chain visualizer such as DNSViz before and after each rollover step. Why uptime monitors miss authoritative DNS outages covers this blind spot in more detail.

If mail starts deferring right after a key rollover and your own logs show no connections from the failing senders, test the MX lookup against a validating resolver, with and without +cd, before touching the mail server. A SERVFAIL that goes away with +cd means the chain of trust is broken. The fix belongs at the DS record and the DNSKEY set, not in Exim or Postfix.