MX Health: a beginner's guide

MX health is the broader category of "are your mail servers actually working?" — beyond just "do the MX records exist?" An MX record can pass every basic validation check (it resolves, it has the right priority, it points at a real hostname) and still be completely broken in production. The mail server it points at might be refusing connections. It might be on a public spam blocklist. It might be advertising the wrong TLS version. It might be running on an IP address with bad reverse DNS. Each of these is a silent failure mode that breaks email delivery without breaking the MX record itself.

You should care because email is the highest-stakes piece of infrastructure most businesses run, and "works" is not the same as "healthy". An MX setup that looks fine in a basic DNS lookup can be quietly losing 5%, 20%, or 100% of inbound mail because of one of the deeper problems above. The first symptom is usually a customer saying "I never got your reply" or a partner saying "your invoices keep bouncing." By the time you hear about it, you have already lost real conversations and real revenue. Health checks catch these problems before customers do.

The five things every MX health check looks at:

• TCP port 25 connectivity. Can the mail server actually be reached on the standard SMTP port from the public internet? Some misconfigured firewalls block it.

• SMTP banner. When you connect to port 25, the server should respond with a `220` greeting. A blank response or a `421` deferral means the server is up but unhealthy.

• STARTTLS support. Modern mail servers should advertise STARTTLS so that incoming mail is encrypted in transit. Servers without it are quietly downgrading every message to plaintext.

• Reverse DNS. The IP address of the mail server should have a PTR record that resolves to the same hostname listed in the MX record. Mismatched reverse DNS is one of the strongest spam-filter signals.

• Public blocklists. Is the mail server's IP address listed on Spamhaus, SpamCop, Barracuda, or any other widely-used reputation feed? Even one listing can dramatically cut inbox placement.

Three questions an MX health check answers:

• Is my mail server actually reachable, healthy, and accepting mail right now?

• Are there any silent issues (blocklist listings, missing TLS, broken reverse DNS) that are quietly costing me deliverability?

• After my recent infrastructure change, is everything still healthy in all the places that matter?

The cost of skipping MX health checks is the slow accumulation of small deliverability problems that nobody notices until customers start complaining. The fix is a few minutes of automated checks on a recurring schedule. Email is too important to leave unmonitored; this is the cheapest insurance you can give it.

In one sentence: Check mail server health and redundancy

Performs health checks on mail servers by verifying MX record (Mail eXchanger record) DNS (Domain Name System) resolution and checking redundancy configuration. Resolves each MX host to A and AAAA records to confirm DNS-level reachability. Detects Null MX (the official internet standard) domains and identifies potential delivery issues including single-server configurations and fake redundancy (all MX records resolving to the same IP (Internet Protocol address)).

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Resolves each MX server to verify DNS (Domain Name System) reachability (both A and AAAA records for IPv4/IPv6), checks for proper redundancy (multiple MX records with different priorities and distinct IP (Internet Protocol address) addresses), and detects Null MX configurations (the official internet standard). Note: SMTP port connectivity checks are not performed because Cloudflare Workers' shared IP ranges are commonly blocked by major mail providers.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the MX Health tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Verifies that mail server DNS (Domain Name System) records are properly configured and resolvable before issues affect email delivery. Complements SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance) checks by testing the underlying mail server DNS infrastructure. Identifies MX hosts that lack A or AAAA records, single points of failure, and fake redundancy.

Picture this in real life. Imagine an email marketing manager. Here's the situation they're walking into: Before launching a major campaign, verify that recipient domains' mail servers are healthy and accepting connections. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the MX Health tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the MX Health tool is built for you:

• Is my domain pointing to the right place right now?

• Did the DNS change I just made actually take effect everywhere in the world?

• Is anything in my DNS misconfigured in a way that could break email or break the website?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders running their own infrastructure, marketers coordinating launches, IT admins inheriting domains from a former employee, and ops engineers troubleshooting live outages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you're flying blind on the one piece of config that decides whether your website and email work at all. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the MX Health tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an email marketing manager, a procurement manager, and an SRE / devops — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Pre-Campaign Health Check

Imagine you're an email marketing manager. Before launching a major campaign, verify that recipient domains' mail servers are healthy and accepting connections.

Why it matters: Avoid sending to domains with offline mail servers, improving campaign metrics.

Story 2: Vendor Email Reliability Assessment

Imagine you're a procurement manager. Evaluate the email infrastructure reliability of potential vendors or partners before signing contracts.

Why it matters: Ensure business-critical communications won't be lost due to partner email issues.

Story 3: Continuous Monitoring

Imagine you're an SRE / devops. Set up automated health checks for critical business partner domains to detect DNS-level mail server issues early.

Why it matters: Detect unreachable MX targets, missing A records, and single points of failure before they cause delivery failures.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the MX Health tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• Right before launching a new website or migrating to a new host.

• After making any DNS change, to confirm the new settings are live everywhere.

• When customers report that your site or email "just stopped working" out of nowhere.

• As a recurring monthly health check to catch silent misconfigurations early.

If you can see yourself in even one of those bullets, the MX Health tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the MX Health tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the MX Health tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with MX Health. If you're already running this check, the related ones often answer the next question that comes up:

• MX Records — Find mail servers and detect email provider

• SPF Check — Validate SPF record syntax, DNS lookups, and policy

• Email Score — Rate email security (SPF, DKIM, DMARC)

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check MX Health and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

IP (Internet Protocol address) — A unique number that identifies a computer on the internet, like a phone number for a server.

MX record (Mail eXchanger record) — A DNS entry that tells the internet which servers handle email for your domain.

SPF (Sender Policy Framework) — A list, published in your DNS, of which servers are allowed to send email pretending to be you. Helps stop spammers from forging your address.

DKIM (DomainKeys Identified Mail) — A digital signature added to every email you send. The receiving mail server checks the signature to make sure the message really came from you and was not changed in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) — An email rulebook you publish in your DNS. It tells receiving servers what to do with email that fails SPF or DKIM checks — ignore it, send it to spam, or block it entirely.

IPv4 (Internet Protocol version 4) — The original kind of internet address — four numbers separated by dots, like 203.0.113.10. The internet has run out of new ones, which is why IPv6 exists.

IPv6 (Internet Protocol version 6) — The newer, longer kind of internet address. Looks like 2001:0db8:85a3::8a2e:0370:7334. Designed because the world ran out of IPv4 addresses.

RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.