Every "our email stopped working" incident I've debugged had the same shape: DNS said everything was fine, and everything was not fine. The fix is a repeatable MX health check — the kind that runs before customers notice, not after.
The MX Health tool automates the four checks below. This article is the "why" behind each one.
1. Do you even have MX records?
Mail for yourdomain.com is routed by its MX records — a ranked list of hosts. If the zone has zero MX records, receivers fall back to the domain's A record, which almost certainly points at your website, not your mail server. Result: mail bounces with No MX record for domain or lands on an Apache server that answers with a 5xx.
yourdomain.com. 3600 IN MX 10 mx1.yourdomain.com.
yourdomain.com. 3600 IN MX 20 mx2.yourdomain.com.
The number before the host is the preference. Lower = preferred. 10 beats 20; mail only tries mx2 when mx1 is unreachable.
2. Duplicate priorities are a silent failover killer
If two MX hosts share the same preference, receivers pick arbitrarily between them. That sounds harmless until one of the two hosts is decommissioned and every other sender picks the dead one. Duplicate priorities are one of those configs that works for months and then fails at the worst moment.
# BAD — same preference, ambiguous failover
yourdomain.com. MX 10 mx1.yourdomain.com.
yourdomain.com. MX 10 mx2.yourdomain.com.
# GOOD — unambiguous order
yourdomain.com. MX 10 mx1.yourdomain.com.
yourdomain.com. MX 20 mx2.yourdomain.com.
3. Do the MX hosts resolve — and to the right things?
Each MX hostname must resolve to A (and ideally AAAA) records. Common failure modes:
- The MX host is a CNAME to a host that no longer exists (
NXDOMAIN). - The MX points at a shared host whose IP was recycled.
- The host resolves, but only to IPv6, and your receivers have no IPv6 path.
The tool resolves every MX host and lists the IPs — a host with no A/AAAA gets flagged red instantly.
4. Is port 25 actually open?
This is the check that catches real incidents. A mail server can have perfect DNS and still refuse connections because:
- A firewall (security group, iptables, cloud ACL) started blocking inbound 25.
- The hosting provider silently blocks SMTP ports on new instances.
- The mail service crashed and nothing restarted it.
The tool opens a raw TCP connection to port 25 on each MX host with a 3-second timeout — open means "at least reachable", which is the right level for a canary. (A full SMTP conversation with banner-grabbing is a separate, deeper probe.)
Null MX: the record that says "don't email me"
RFC 7505 defines a special MX value: a single record pointing at . with preference 0.
nodomain.com. 3600 IN MX 0 .
This is the official way to say "this domain sends mail but never receives any". Senders must not fall back to the A record. It's a great anti-spam control for throwaway domains — but it's also the most dangerous record to copy-paste by mistake. If you see it on a domain that's supposed to receive mail, that's an outage waiting to happen.
The 5-minute habit
Run this on your domain and your provider's domains:
curl -X POST https://yas.sh/api/v1/tools/mx-health -d '{"domain":"yourdomain.com"}'
Check three things in the output: MX records exist, preferences are unique, port 25 is open on every host. Then put it on a schedule — the tool is one POST away from your monitoring pipeline, and the JSON shape is stable enough to alert on issues being non-empty.
Email infrastructure doesn't degrade gracefully. It degrades suddenly, usually on a Friday, usually right before a big campaign. The MX check is five minutes that buys you the opposite.
What an MX health check actually inspects
An MX check answers one core question: "where should mail for this domain be delivered, and can it get there?" But a thorough check looks at several layers:
- Record presence and value. Does the domain have an MX record, and does it point at a real, reachable mail server rather than a dead or misconfigured host?
- Priority ordering. Lower numeric priority means higher precedence; the check confirms the primary server is what receives mail first and that fallbacks exist.
- Propagation. Is the record visible from external resolvers, or is a stale value still cached because of a high TTL?
- The destination's health. The record may be correct while the server behind it is down, slow, or rejecting mail — which no amount of record editing will fix.
Distinguishing "the record is wrong" from "the record is right but the server is sick" is the single most useful output of a good MX check, because it tells you whether to edit DNS or call your mail host.
Reading the symptoms back to the cause
Different delivery problems point to different MX faults, and mapping symptoms to causes speeds the fix:
- Mail rejected outright usually means a missing or incorrect MX record, or a record pointing at a host that no longer accepts mail.
- Mail delayed by hours often means the primary server is down and the fallback (or a slower route) is absorbing the load.
- Mail landing in spam is usually not an MX problem at all but an authentication problem (SPF/DKIM/DMARC); see the email authentication guide.
- Inbound mail misrouted can mean a stale MX still pointing at a former provider.
Using these mappings, a single symptom points you at the right record family instead of guesswork across all of DNS.
A routine that prevents surprises
MX problems rarely announce themselves before they hurt a campaign. A small routine — a monthly MX check plus a check before any mail-related change — catches the slow drift (a record left pointing at a decommissioned server, a certificate expiring, a server degrading) while it is cheap to fix rather than during an outage. Because mail is infrastructure, treating its health as a monitored asset rather than an afterthought is what keeps delivery dependable.
Extending the check to the full chain
An MX check is one link in the delivery chain, and a complete health review also looks at the sending side: whether SPF/DKIM/DMARC are in place and aligned, whether the server's TLS certificate is valid, and whether there are obvious deliverability red flags. Doing the MX check alongside these gives a complete picture of delivery health rather than a single-record snapshot.