What MX records are for
The MX record (mail exchanger) declares which server accepts email for a domain. Each entry has a priority — the lowest value is tried first, higher values serve as fallbacks. Without an MX record a sending server falls back to the domain's A record, which is rarely what was intended.
MX records concern receiving only. They are irrelevant for sending — a widespread misconception. Even a domain that only sends still needs an MX, otherwise bounces and replies have nowhere to go, and some filters score the absence negatively.
What AnalyzeMy.Email checks
- All MX records of the sender domain with their priorities
- A and AAAA records of every MX host — does the hostname resolve at all?
- Reverse DNS for every IP found
- FCrDNS — the PTR name is resolved back and checked for the originating IP
Typical failure patterns
- MX pointing at a CNAME: not permitted by RFC. Some servers follow it anyway, others reject — an error that shows up as sporadic delivery problems.
- MX host without an A record: the entry exists but does not resolve. Delivery impossible.
- Only one MX: no backup. If the server fails, sending servers do hold mail in their queues and retry for days — but delays are unavoidable.
- Backup MX less protected: the second MX is readily forgotten during configuration changes and then lacks STARTTLS, a valid certificate or a TLSA record. Attackers aim at exactly that.
- Orphaned entries: MX records pointing at servers that ceased to exist after a provider migration.
Recommendations
- At least two MX hosts with different priorities, ideally on separate infrastructure.
- Always point MX at an A/AAAA name, never at a CNAME.
- Treat all MX hosts equally — STARTTLS, certificate, DANE and spam defence belong on every one of them.
- Think about IPv6: if you publish AAAA records, those addresses need proper reverse DNS too — otherwise some large providers will reject.