MTA-STS Check: a beginner's guide

MTA-STS (Mail Transfer Agent Strict Transport Security) is an email-security standard that closes a longstanding vulnerability in how mail servers negotiate encryption. The original version of email transport, STARTTLS, lets two mail servers upgrade an unencrypted connection to an encrypted one mid-conversation. The problem is that the upgrade is opportunistic: an attacker who can sit in the middle of the connection (a malicious ISP, a compromised router, a state-level adversary) can simply strip out the upgrade signal, and the mail servers will silently fall back to plaintext without raising any alarms. Email between the two servers — including potentially sensitive business correspondence — flows over the public internet completely unencrypted. MTA-STS fixes this by letting the receiving domain publish a public policy that says, "every server sending mail to me must use TLS, and must verify my certificate, no exceptions."

You should care because opportunistic STARTTLS is one of the longest-running quiet security failures in email, and most senders have no idea it affects them. If you handle anything sensitive over email — financial information, customer data, contracts, healthcare records, internal HR conversations — there is a real risk that a portion of it has been transmitted in plaintext at some point because a downstream mail relay quietly dropped TLS. MTA-STS is the only widely-deployed standard that closes this gap, and it is now treated as a baseline requirement by serious email-security and compliance reviews.

The four things every MTA-STS check looks at:

• Is there an MTA-STS DNS record? Lives at `_mta-sts.example.com` as a TXT record with a version and an ID.

• Is there a published policy file? The actual policy lives at `https://mta-sts.example.com/.well-known/mta-sts.txt` and lists the allowed MX hostnames and the enforcement mode.

• Is the policy in `enforce` mode? The other modes are `testing` (logs failures but doesn't actually block) and `none` (effectively disabled).

• Is TLS-RPT (TLS Reporting) configured? A complementary standard (RFC 8460) that tells you when other senders' attempts to use TLS to reach you fail.

Three questions an MTA-STS check answers:

• Is incoming email to my domain protected against TLS downgrade attacks?

• Is the policy actually in enforcement mode, or is it stuck in testing?

• If a sending server failed to negotiate TLS to me, would I find out?

The cost of skipping MTA-STS is the small but persistent risk that some fraction of inbound mail is being silently transmitted in plaintext across the public internet. The fix is publishing two records and one HTTPS file, and is increasingly expected on financial-services and healthcare email infrastructure. The standard is defined in RFC 8461.

In one sentence: Validate email transport encryption policy

Validates MTA-STS (Mail Transfer Agent Strict Transport Security) (Mail Transfer Agent Strict Transport Security, the official internet standard) configuration that enforces TLS (Transport Layer Security) encryption for inbound email delivery. Checks both the DNS (Domain Name System) TXT record (text record) at _mta-sts.<domain> and the policy file hosted at HTTPS://mta-sts.<domain>/.well-known/mta-sts.txt. Also checks for TLS-RPT (TLS Reporting) (the official internet standard) reporting configuration. Validates max_age against recommended ranges (86,400-31,557,600 seconds) and flags common implementation pitfalls.

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:

Queries the _mta-sts.<domain> TXT record (text record) for the MTA-STS (Mail Transfer Agent Strict Transport Security) DNS (Domain Name System) entry (v=STSv1; id=<policy-id>), fetches the policy file from the well-known URL (web address), validates policy syntax (version tag ordering per the official internet standard §3.2, mode, mx patterns, max_age), cross-validates MX patterns against actual MX records, and checks for TLS-RPT (TLS (Transport Layer Security) Reporting) reporting at _smtp._tls.<domain>. Evaluates the mode progression (none → testing → enforce), validates max_age against recommended ranges (minimum 86,400 for testing, 604,800-31,557,600 for enforce), and detects common issues like DNS record without policy file, mismatched MX patterns, missing policy ID, and version ordering violations. Note: STARTTLS capability of MX servers cannot be verified from this platform (SMTP port 25 is not accessible).

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 MTA-STS Check 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.

MTA-STS (Mail Transfer Agent Strict Transport Security) prevents email interception by requiring TLS (Transport Layer Security) encryption between mail servers (the official internet standard). Without MTA-STS, even domains with HTTPS (secure HyperText Transfer Protocol) everywhere can have their emails intercepted via SMTP downgrade attacks — attackers can strip STARTTLS from the initial negotiation. MTA-STS is the email equivalent of HSTS (HTTP Strict Transport Security) and is complementary to DANE (the official internet standard, which requires DNSSEC (Domain Name System Security Extensions)). Combined with TLS-RPT (TLS Reporting), it provides visibility into delivery failures. Adopted by Google (exclusively uses MTA-STS) and Microsoft (supports both DANE and MTA-STS). Required for SOC 2 (Service Organization Control 2), HIPAA, and GDPR (General Data Protection Regulation) compliance for encrypted email transmission.

Picture this in real life. Imagine a security engineer. Here's the situation they're walking into: Verify MTA-STS (Mail Transfer Agent Strict Transport Security) is properly configured to enforce encrypted email delivery to your domain. Check that the policy mode is "enforce" and max_age is sufficient. 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 MTA-STS Check 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 MTA-STS Check tool is built for you:

• Will the emails I send actually reach the inbox, or are they going to spam?

• Can someone else send phishing emails pretending to be my domain?

• Have I set up the three rulebooks (SPF, DKIM, DMARC) that mailbox providers now require?

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. Small-business owners worried about deliverability, marketing managers onboarding a new email service, IT admins prepping for a security audit, and brand teams protecting against phishing. 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 your real emails risk landing in the spam folder while scammers find it easier to impersonate your brand. 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 MTA-STS Check tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security engineer, a compliance officer, and a security analyst — 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: Email Encryption Enforcement

Imagine you're a security engineer. Verify MTA-STS (Mail Transfer Agent Strict Transport Security) is properly configured to enforce encrypted email delivery to your domain. Check that the policy mode is "enforce" and max_age is sufficient.

Why it matters: Protect sensitive email communications from man-in-the-middle and downgrade attacks.

Story 2: Compliance Documentation

Imagine you're a compliance officer. Document MTA-STS (Mail Transfer Agent Strict Transport Security) configuration as evidence of email encryption controls for SOC 2 (Service Organization Control 2), HIPAA, or GDPR (General Data Protection Regulation) audits.

Why it matters: Meet compliance requirements for encrypted email transmission.

Story 3: Partner Email Security Assessment

Imagine you're a security analyst. Evaluate partner or vendor email security by checking their MTA-STS (Mail Transfer Agent Strict Transport Security) enforcement level before sharing sensitive information via email.

Why it matters: Ensure sensitive communications with partners are encrypted in transit.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the MTA-STS Check 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:

• When setting up email on a brand-new domain.

• After signing up for a new email-sending service (Mailchimp, SendGrid, HubSpot, etc.).

• When a customer reports that your emails are landing in their spam folder.

• Before a security audit, a SOC 2 review, or a major marketing campaign.

If you can see yourself in even one of those bullets, the MTA-STS Check 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 MTA-STS Check 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 MTA-STS Check tool to check google.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 MTA-STS Check. If you're already running this check, the related ones often answer the next question that comes up:

• DMARC Check — Analyze DMARC policy, alignment, and reporting

• MX Records — Find mail servers and detect email provider

• 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 MTA-STS Check 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.

URL (web address) — The full address of a page, like https://example.com/about.

HTTPS (secure HyperText Transfer Protocol) — HTTP with encryption — the little padlock in your browser. It means nobody between you and the website can read what you're sending.

TXT record (text record) — A DNS entry that holds plain text. Used for things like proving you own a domain or listing who can send email as you.

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-RPT (TLS Reporting) — A way for your mail server to receive reports when other servers fail to deliver email to you over a secure connection — pairs with MTA-STS.

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.

DNSSEC (Domain Name System Security Extensions) — A way to digitally sign DNS records so attackers can't trick your computer into looking up the wrong server.

GDPR (General Data Protection Regulation) — Europe's privacy law. Requires websites to be transparent about what personal data they collect and how they use it.

HSTS (HTTP Strict Transport Security) — A header that tells browsers "always use HTTPS for this site, never plain HTTP, even if the user types it." Prevents downgrade attacks.

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.

SOC 2 (Service Organization Control 2) — A widely used security audit. Proves to customers that you handle their data responsibly.