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 end-to-end health checks on mail servers — DNS (Domain Name System) resolution AND a real SMTP handshake. Resolves each MX host to A and AAAA records, then opens a TCP probe to the mail server, reads the SMTP greeting, sends EHLO, and verifies opportunistic TLS (Transport Layer Security) works (the official internet standard). Probes the Submission port (SMTP Submission port (587)) (587, the official internet standard) with STARTTLS (STARTTLS) and the SMTPS port (465) with implicit TLS — both expose the same TLS configuration that the MX uses for relay traffic. Detects Null MX (the official internet standard) domains and surfaces classification (status, capabilities, TLS state) per MX.

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:

For each MX, resolves the hostname to A and AAAA records, then performs a real SMTP probe over TCP. The probe opens a connection, reads the SMTP 220 greeting, sends EHLO, parses advertised capabilities, performs STARTTLS (STARTTLS) (port 587) or implicit TLS (Transport Layer Security) (port 465), and returns per-MX status: greeting line, capability list, TLS handshake outcome. Aggregates whether any MX is healthy (`any_smtp_ok`) and whether every probed MX successfully negotiated TLS (`all_tls_ok`). Probing is opt-out via `?smtp_probe=false` for callers who only want the DNS-level checks.

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.

A name that says "Health" should health-check the actual mail service, not just resolve names. Reading the SMTP greeting and verifying the TLS (Transport Layer Security) handshake answers the questions email administrators actually have: is the server up? does it offer opportunistic TLS as the official internet standard requires? are the cipher and certificate negotiation healthy? Failed handshakes and missing STARTTLS (STARTTLS) surface as actionable issues, not buried network noise. Complements SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), DMARC (Domain-based Message Authentication, Reporting and Conformance), and MTA-STS (Mail Transfer Agent Strict Transport Security) by testing the live mail-transport layer.

Picture this in real life. Imagine an email deliverability engineer. Here's the situation they're walking into: Before launching a major campaign, verify that recipient mail servers accept connections AND offer opportunistic TLS (Transport Layer Security) per the official internet standard. The live SMTP probe sends EHLO, parses advertised capabilities, and confirms STARTTLS (STARTTLS) or SMTPS works — the exact controls Gmail and Microsoft 365 require under their bulk-sender policies. 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 deliverability engineer, a security / procurement, 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 TLS Posture Check

Imagine you're an email deliverability engineer. Before launching a major campaign, verify that recipient mail servers accept connections AND offer opportunistic TLS (Transport Layer Security) per the official internet standard. The live SMTP probe sends EHLO, parses advertised capabilities, and confirms STARTTLS (STARTTLS) or SMTPS works — the exact controls Gmail and Microsoft 365 require under their bulk-sender policies.

Why it matters: Catch recipients whose MX is up but TLS (Transport Layer Security) is broken (expired cert, missing STARTTLS (STARTTLS)) — the failure mode that turns deliverable mail into spam-folder mail.

Story 2: Vendor Email Security Assessment

Imagine you're a security / procurement. Evaluate a vendor's mail infrastructure during onboarding. The probe surfaces whether their MX accepts TLS (Transport Layer Security) submissions, advertises proper capabilities (SIZE, 8BITMIME, AUTH), and completes the handshake cleanly. Combined with SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance) checks, gives a complete email-stack posture in two API (Application Programming Interface) calls.

Why it matters: Identify partners running outdated or misconfigured mail servers before signing contracts that depend on reliable email exchange.

Story 3: Continuous TLS-Posture Monitoring

Imagine you're an SRE / devops. Schedule mx-health probes against business-critical partner domains. Alert on `all_tls_ok` regressions — the most common cause is a silently-expired TLS (Transport Layer Security) cert on the MX, which degrades from "works" to "delivered as cleartext" without any visible error.

Why it matters: Detect TLS (Transport Layer Security) regressions on inbound mail paths within minutes, not after the certificate-monitoring tool finally surfaces the renewal.

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.

You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.

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.

API (Application Programming Interface) — A way for one program to ask another program for something — like a waiter taking your order to the kitchen.

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.

MTA-STS (Mail Transfer Agent Strict Transport Security) — A way to tell other mail servers "always use encryption when sending email to me, and refuse to fall back to unencrypted delivery."

TLS (Transport Layer Security) — The encryption that puts the 'S' in HTTPS. It scrambles data so nobody between you and a website can read it.

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.

Submission port (SMTP Submission port (587)) — The standard TCP port for client-to-server email submission with STARTTLS, defined in RFC 6409. Distinct from port 25 (server-to-server relay) and 465 (SMTPS, implicit TLS).

STARTTLS (STARTTLS) — A protocol upgrade that turns a plaintext SMTP connection into an encrypted TLS one. RFC 8314 makes opportunistic TLS the modern baseline — an MX without STARTTLS is delivering mail in cleartext.