MTA-STS — the DNS Record

MTA-STS — the DNS record

MTA-STS is the standard that lets a domain tell sending servers: “use TLS when you connect to my mail servers, and validate the certificate.” Before MTA-STS, opportunistic TLS was the norm — senders would attempt TLS but downgrade to plaintext if anything went wrong. That downgrade was exploitable.

MTA-STS has two parts: a DNS record and an HTTPS policy file. This lesson covers the DNS record. The next covers the policy file.

What the record looks like

A TXT record at _mta-sts.{domain}:

_mta-sts.isidoregroup.com.  3600  IN  TXT  "v=STSv1; id=20240115093000"

Two tags:

  • v=STSv1 — version identifier. Required. There is no v=STSv2 yet.
  • id= — an arbitrary string that changes whenever the policy file changes. Senders cache the policy keyed by this id. Increment it to force re-fetch.

The convention is to use a timestamp (id=20240115093000 is 2024-01-15 09:30:00). This makes the change history obvious. Any unique string works.

What the DNS record does and does not do

The TXT record by itself does nothing operational. It is a pointer — it tells senders “I have an MTA-STS policy; go fetch it.” The actual TLS enforcement is encoded in the policy file at https://mta-sts.{domain}/.well-known/mta-sts.txt.

This is why the DNS record without a working policy file is worse than no DNS record at all. Senders will look for the policy, fail to fetch it, and may treat that as a soft fail or simply log it as a TLS configuration error. The next lesson covers what Cathedra does with that case.

What Cathedra reports

MtaStsCheck.php reads _mta-sts.{domain} looking for any TXT record containing v=STSv1. Three possible outcomes for this first stage:

No record found

Field Value
status info
severity —
finding “No MTA-STS TXT record found at _mta-sts.{domain}. MTA-STS is not deployed.”
recommendation “Consider deploying MTA-STS to enforce TLS for inbound SMTP connections.”

The status is info — not warning, not error. This is the distinction that matters about MTA-STS in the Cathedra worldview. Not having it is not a failure. It is an opportunity.

Most client domains will return this finding when first scanned. That is normal. MTA-STS is a hardening control, not a baseline expectation.

When the DNS record is absent, the check stops here. There is no policy file to evaluate.

Record present

When a v=STSv1 record is found, Cathedra emits:

Field Value
status pass
severity —
finding “MTA-STS TXT record present: {full TXT value}”
recommendation —

And then proceeds to the policy file check (next lesson).

Why the status is info, not warning

The choice of info rather than warning reflects the operational reality. A client that has not deployed MTA-STS is in the same shape as 90% of small-to-medium business domains. Their mail still flows. STARTTLS is still happening opportunistically between any modern mail server pair. What they lack is the explicit enforcement guarantee that a downgrade attack will be refused.

That gap is real but it is not urgent in the way a missing DMARC record is urgent. A client without DMARC is being phished by every spammer who finds them. A client without MTA-STS is theoretically exposed to an active TLS downgrade attack — a much rarer adversary and a much narrower attack window.

Cathedra reflects that asymmetry. Missing DMARC is error / high. Missing MTA-STS is info. Both findings are real and both belong in a remediation list, but they sit at different priorities.

When you would actually deploy MTA-STS

Three triggers that should move MTA-STS up the priority list for a client:

  1. Compliance requirement. Some frameworks (CMMC, certain SOC 2 implementations, NIST hardening profiles) explicitly call for MTA-STS. If the client is under one of those, deployment is non-negotiable.
  2. A specific TLS-failure incident. A delivery failure tied to TLS handshake problems with a major partner has surfaced. Deploying MTA-STS plus TLS-RPT (Lesson 6.3) gives you forward visibility on those failures.
  3. The client has all other email security controls in place (SPF, DKIM, DMARC at p=reject). MTA-STS is the next natural hardening step.

Outside those triggers, MTA-STS is a strategic recommendation for the annual review, not an urgent fix.

What the record looks like for cloud-hosted mail

For an M365 tenant, the DNS record is published at the client’s domain, but the policy file points to Microsoft’s MX hostnames. Same for Google Workspace.

A typical M365 tenant’s record:

_mta-sts.isidoregroup.com.  3600  IN  TXT  "v=STSv1; id=20240115093000"

The policy file (covered next lesson) lists *.mail.protection.outlook.com as the allowed MX pattern. The DNS record itself is identical regardless of provider — the provider-specific details are in the policy.

A note on the mta-sts.{domain} hostname

MTA-STS uses two distinct hostnames:

  • _mta-sts.{domain} — the TXT record (underscored, DNS-only).
  • mta-sts.{domain} — the HTTPS host that serves the policy file. Not underscored. This is a real web host that needs an A or CNAME record and a TLS certificate.

The two are easy to confuse. The TXT record goes at the underscored name; the policy is served from the non-underscored name. The next lesson covers the policy host.

What you should remember

  • MTA-STS DNS record is a TXT at _mta-sts.{domain} containing v=STSv1; id={string}.
  • The record is a pointer to the real policy file at https://mta-sts.{domain}/.well-known/mta-sts.txt.
  • Cathedra reports missing MTA-STS as info, not error or warning. Not deployed is not a failure.
  • Finding when missing: “No MTA-STS TXT record found at _mta-sts.{domain}. MTA-STS is not deployed.”
  • Two hostnames involved: _mta-sts.{domain} (TXT) and mta-sts.{domain} (HTTPS). Don’t confuse them.

Cathedra alignment: MtaStsCheck.php — first stage of the check, the TXT record at _mta-sts.{domain}

Previous Lesson
Back to Lesson
Next Topic