Email DNS errors: bounces that start in the zone
Some bounces never reach the recipient’s mail server at all. The sending MTA asks DNS where to deliver, gets an answer it cannot use, and gives up before the SMTP conversation starts. These four failures look like recipient problems in a bounce log, but every one of them is resolved in a DNS zone.
The four DNS bounce families
The domain does not exist
An authoritative answer that the name is not registered or not published. Almost always a typo in the local part of the address or a dead domain on your list.
The resolver could not answer
A failure in resolution itself, not a verdict on the name. Broken DNSSEC, unreachable authoritative servers, or a lame delegation. Often transient, and often on your side.
The domain resolves but accepts no mail
The name exists and has no MX record. A sender may fall back to the address record of the domain itself, and when that fails too the message is undeliverable.
The MX target itself is unresolvable
The MX record points at a hostname with no usable address record, so the queue has a destination it can name but cannot reach. A recipient-side zone error you can only report, not fix.
How to read them
Ask one question first: did the resolver give a verdict, or did it fail? NXDOMAIN and a missing MX are verdicts, so they are permanent and belong in list hygiene. SERVFAIL is a failure to answer, so it is retried by the queue and belongs in infrastructure monitoring. Treating the second like the first is how a healthy address gets suppressed for good.
These four pages sit on top of the wider DNS records for email reference, which covers each record type and its syntax. When the bounce text carries a numeric code as well, look it up in the SMTP error code directory, and use hard bounce versus soft bounce to decide whether the address should be suppressed or retried.
