What does an MX record actually do?

It tells other mail servers where to deliver mail for your domain. Each entry has a preference (priority) number — lower wins. Without MX records, receivers fall back to the domain's A record, which usually isn't a mail server at all.

What is a null MX record?

A single MX record with the value "." (RFC 7505). It's the official way to declare "this domain accepts NO email" — used by domains that only send, never receive.

Should I monitor port 25?

Yes — a firewall change on any MX host silently kills inbound mail while DNS still looks healthy. TCP 25 reachability is the cheapest canary you can run.

MX Health Checks: Diagnose Email Delivery Before It Hurts | yas.sh

How to read MX records, test port 25 reachability, detect null MX and duplicate priorities, and build a mail-delivery check that runs before customers complain.

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.