Can an MX record point to a CNAME?

No. RFC 5321 requires MX targets to be hostnames with address records. CNAME targets are a specification violation and fail with some senders, even though many tolerate them.

A single record of '0 .' declaring that the domain accepts no mail. It makes misdirected mail bounce immediately instead of being delivered somewhere unintended via the A-record fallback.

Do I need a backup MX?

Usually not. Sending servers already queue and retry for days. A poorly maintained backup MX often becomes a spam sink or a delivery black hole.

Why do lower preference numbers get mail first?

The number is a preference, not a priority score — senders try the lowest value first, then higher ones on failure. Equal values are used in a round-robin.

TLS & Email🌐 YAS server-sideAPI availableadvanced

MX Health

Checks MX records, their A/AAAA resolution, port 25 reachability and null-MX (RFC 7505).

Processed by YAS · not stored

Ready to runInstant execution

All tools →

MX Health — records, resolution & port 25

Lists MX hosts, resolves A/AAAA, probes TCP 25 and detects null MX (RFC 7505) and duplicate priorities.

What does this tool do?

Checks MX records, their A/AAAA resolution, port 25 reachability and null-MX (RFC 7505).

Why would I use it?

Email is bouncing and you want to check mail routing.
You are testing a new mail server before cutover.
You want to confirm null MX for a domain that should not receive mail.

Real-life example

Input

example.com

Output

MX 10 mail.example.com → A 93.184.216.34 · port 25: reachable

Each MX host is resolved and probed.

Input → Process → Output → Next

Input: Enter a domain.
Process: YAS queries MX records, resolves each host, and probes port 25.
Output: MX list with resolution and reachability.
Next action: Fix missing or unreachable MX hosts; add null MX to stop mail.

Common mistakes

Probing port 25 from networks that block outbound SMTP.
Expecting a reachable MX from hosts behind firewalls.
Forgetting that MX precedence (lower = preferred) matters.

What the result means

Reachable MX hosts accept incoming mail for the domain.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/mx-health

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/mx-health" \
  -H "Content-Type: application/json" \
  -d '{"input":"example.com"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/mx-health", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "example.com"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/mx-health", json={"input":"example.com"})
data = r.json()

Field	Type	Required	Description
input	string	Yes	Domain, e.g. example.com

Success response

{ "result": { "nullMx": false, "hosts": [{ "preference": 10, "exchange": "mx1.example.com", "ips": ["93.184.216.34"], "port25": { "open": true } }], "duplicatePriorities": [], "issues": [] } }

MX audit: priorities, A/AAAA resolution, STARTTLS-era port-25 probe, null MX (RFC 7505), duplicates.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How MX Health works

The check resolves the domain's MX records, which list mail exchangers with numeric preferences — lower values are tried first, equal values are load-balanced. Each host is then resolved to an address and probed on port 25 to confirm it accepts connections, presents a banner and advertises STARTTLS. A domain with no MX record falls back to its A record under RFC 5321, which is rarely what an operator intends.

Beyond reachability, the health signals that matter are structural: MX hostnames must be names, never IP addresses or CNAMEs (both violate the specification, and CNAME targets break some senders); every host should offer STARTTLS; and a domain that sends no mail should publish a null MX record — a single '.' at preference 0 — to explicitly declare that, rather than leaving the fallback behaviour to chance.

When to use it: real-world scenarios

Diagnosing inbound mail failures

Before investigating filters and mailbox rules, confirm the MX hosts resolve and accept connections. A backup MX pointing at a decommissioned server absorbs mail into nothing.

Verifying a mail migration

During a move between providers, both old and new records often coexist. Checking preferences shows which one actually receives mail.

Locking down non-sending domains

Parked and brand-protection domains should publish a null MX and v=spf1 -all so they cannot be used to spoof or to accept misdirected mail.

Auditing transport encryption

An MX host without STARTTLS receives mail in cleartext and will be flagged by senders enforcing MTA-STS.

Pro tips

MX must point to a hostname with an A or AAAA record — never to a CNAME and never to an IP literal. Both are specification violations that fail with some senders.
A backup MX at a higher preference is only useful if it queues and forwards correctly. A misconfigured one is worse than none.
Publish a null MX (0 .) on every domain that receives no mail. It converts silent misdelivery into an immediate, clear bounce.
Keep MX TTLs moderate — 3600 seconds — so a provider migration does not depend on a day-long cache expiry.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Connectivity and advertised capabilities are checked; message acceptance, filtering and mailbox routing are not.
Outbound port 25 is blocked on many networks, so a probe failure can reflect network policy rather than server state.
Greylisting and rate limiting can make a healthy server appear unresponsive on a single probe.
TLS certificate validity on the MX host is reported separately by the TLS Analyzer.

Frequently asked questions

Can an MX record point to a CNAME?: No. RFC 5321 requires MX targets to be hostnames with address records. CNAME targets are a specification violation and fail with some senders, even though many tolerate them.
What is a null MX?: A single record of '0 .' declaring that the domain accepts no mail. It makes misdirected mail bounce immediately instead of being delivered somewhere unintended via the A-record fallback.
Do I need a backup MX?: Usually not. Sending servers already queue and retry for days. A poorly maintained backup MX often becomes a spam sink or a delivery black hole.
Why do lower preference numbers get mail first?: The number is a preference, not a priority score — senders try the lowest value first, then higher ones on failure. Equal values are used in a round-robin.