Nameserver and MX hostname hygiene
Nameserver and mail (MX) hostnames follow a few rules that keep resolution and mail delivery predictable. Breaking them "mostly works" until it does not.
Real hostnames, not IP literals
NS and MX records must point at hostnames, not IP addresses. An IP literal where a name belongs is invalid and many resolvers and mail servers reject it. Use ns1.example.com / mail.example.com, each with its own A/AAAA record.
Not CNAMEs
A name used as a nameserver or an MX target must not be a CNAME - it has to resolve directly to an address. A CNAME there is against the DNS rules (RFC 2181 for NS, RFC 2181/1035 for MX) and behaves inconsistently across resolvers. Point NS and MX at names that carry A/AAAA directly.
Distinct MX addresses
When you list several MX hosts for redundancy, they should resolve to different IP addresses. Two MX names that both point at the same server give you no real failover - if that server is down, both are down. The report warns when MX targets collapse to the same address.
Stealth nameservers
A stealth nameserver is one that answers for the zone but is not listed in the parent's delegation (or vice versa). A little of this is normal (a hidden primary), but an unexpected stealth server usually means the parent delegation and your zone's NS records have drifted apart - add it at the registrar if it should serve the domain, or remove it from the zone if it should not.
How to fix it
- Replace any IP-literal NS/MX with a hostname that has its own A/AAAA.
- Make sure no NS or MX name is a CNAME; if one is, create direct A/AAAA records instead.
- Give redundant MX hosts genuinely separate servers/addresses.
- Reconcile the parent delegation and your zone's NS set so there are no unexpected stealth servers (see the delegation article).
How to verify
dig example.com NS +short # names, not IPs
dig example.com MX +short # names + preferences
dig ns1.example.com A +short # each NS/MX name resolves directly (no CNAME)
dig mail.example.com CNAME +short # should be empty