When an MX target has no A or AAAA record, senders cannot find a server to connect to, so mail to your domain is delayed and eventually bounced. RFC 5321 §5.1 requires the name in an MX record to return “at least one address record (e.g., A or AAAA RR)”. Look up your domain in the MX lookup, then query each target in the DNS lookup for A and AAAA. A target that answers NXDOMAIN or an empty result is the fault. The three common causes are below.
Causes
| Cause | What you see | Fix |
|---|---|---|
| Typo in the target | mx1.provder.example returns NXDOMAIN | Correct the spelling, copy from the provider’s documentation |
| Missing trailing dot in a zone file | MX target shown as mail.example.com.example.com | Add the final dot, or enter the name relative to the zone as your DNS host expects |
| Host deleted or never created | Target is in your own zone (mail.example.com) but no A/AAAA exists | Create the A (and AAAA) record, or point the MX elsewhere |
| Provider retired the hostname | Name was valid once, now NXDOMAIN | Fetch the current MX values from the provider and replace |
The trailing dot
In a zone file or a BIND-style editor, a name that ends in a dot is absolute. A name without it is relative: the zone name is appended. So this line in the zone example.com:
example.com. 3600 IN MX 10 mail.provider.example
is read as mail.provider.example.example.com., which does not exist. The correct line is:
example.com. 3600 IN MX 10 mail.provider.example.
Many web panels do the opposite: they add the zone automatically only when you leave the dot off, or they strip a final dot you typed. Look at the saved record afterwards and compare it with what the DNS lookup shows. If you see your own domain repeated inside the target, the dot is the problem.
How mail fails
RFC 5321 §5.1 describes the sender’s steps: look up the MX records, order them by preference, then resolve each target to addresses and try them. If a target does not resolve, the sender moves to the next MX. If none of them resolves, no connection is possible.
What happens next depends on how the sender classifies the DNS failure. RFC 5321 §5.1 says that on a temporary lookup error “the message MUST be queued and retried later”. A permanent error (NXDOMAIN) is typically reported back to the sender at once as a bounce. In practice you will see one of two outcomes:
- Senders get a delayed-delivery warning, then a final failure after their retry period ends (commonly a few days, the exact value is each server’s own setting).
- Senders get an immediate bounce stating that the host or domain was not found.
An MX that resolves for some of its targets but not others is also hazardous: with equal preference the sender picks randomly, so part of your mail works and the rest fails.
Do not delete the MX records to “reset” them. RFC 5321 §5.1 says that without any MX, the sender treats the domain’s own A or AAAA record as an implicit MX with preference 0. Your mail would then go to your web server’s address, which is rarely what you want. If the domain should not receive mail, publish a null MX instead.
Fix step by step
- Run the MX lookup and list each target and priority.
- For each target, check
AandAAAAin the DNS lookup. Note any NXDOMAIN or empty answer. - Decide whether the name is yours or the provider’s. For provider names, copy the current value from the provider’s documentation; the provider setup check compares your records with the expected ones for supported providers.
- Edit the record, then re-query. Remember that resolvers may keep the earlier answer, including a cached “does not exist” (see DNS propagation explained).
- Send a test message from an outside mailbox and read any bounce.
FAQ
The target resolves from my computer but senders still fail. Why? Your local resolver may have a cached or different answer. Compare resolvers with the DNS propagation tool, and check that the authoritative servers for the zone are the ones holding your fix.
Can the target have only an AAAA record? RFC 5321 §5.1 accepts A or AAAA. A target with only AAAA works only for senders that can connect over IPv6, so publish both when you can.
Is a target in another domain acceptable? Yes, that is how hosted mail works. The target only has to resolve to addresses and not be a CNAME; see MX points to a CNAME.
Sources
- RFC 5321, §5.1 Locating the Target Host: https://www.rfc-editor.org/rfc/rfc5321#section-5.1
- RFC 5321, §4.5.4.1 Sending Strategy: https://www.rfc-editor.org/rfc/rfc5321#section-4.5.4.1
- RFC 1035, §5.1 Master files, Format (absolute and relative names): https://www.rfc-editor.org/rfc/rfc1035#section-5.1