Beyond DMARC, DKIM, and SPF: MTA-STS + TLS-RPT for inbound SMTP

DMARC, DKIM, and SPF are about message identity.

They help receivers decide whether mail claiming to be from your domain is authentic and aligned.

They do not tell other mail servers how to protect SMTP delivery to your inbound MX hosts.

That gap is where MTA-STS and TLS-RPT fit.

If you already run DMARC enforcement, this is the next inbound control to understand: publish a TLS policy for your receiving mail servers, then ask participating senders to report when that policy breaks.

What problem MTA-STS actually solves

Plain old SMTP transport encryption is usually based on STARTTLS.

STARTTLS is useful, but by itself it is still opportunistic. A sender can attempt TLS, but if a network attacker strips the 250 STARTTLS capability or redirects delivery toward the wrong MX, mail can fall back in ways the receiving domain never sees directly.

RFC 8461 was created to reduce exactly that risk. It lets a receiving domain publish a policy saying:

• which MX hosts are valid for this domain
• that those MX hosts are expected to support STARTTLS
• that those MX hosts should present a certificate chaining to a trusted public CA
• what a sending MTA should do when the TLS policy cannot be validated

That is very different from DMARC.

DMARC protects the identity shown in From:. MTA-STS protects the path used when another mail server delivers mail to you.

The short distinction

Keep this mental model simple:

• SPF, DKIM, and DMARC protect domain identity and policy evaluation for messages
• MTA-STS protects inbound SMTP transport expectations for your receiving domain
• TLS-RPT gives you aggregate reports about TLS policy successes and failures seen by participating senders

So if someone asks, "Do I still need MTA-STS if I already have DMARC?"

The answer is yes, because they solve different problems.

What MTA-STS publishes

MTA-STS uses two publication points.

1. A DNS TXT record at _mta-sts.example.com

This TXT record tells sending MTAs that your domain has an MTA-STS policy and exposes a policy id used for change tracking.

Example:

_mta-sts.example.com. IN TXT "v=STSv1; id=2026042201"

Per RFC 8461, the v value is STSv1, and the id changes whenever you publish a new policy version.

2. An HTTPS policy file at https://mta-sts.example.com/.well-known/mta-sts.txt

This file is where you declare the actual policy.

Example:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

The main fields are:

• mode: testing, enforce, or none
• mx: allowed MX hostnames or wildcard patterns
• max_age: how long senders may cache the policy

The HTTPS host itself must present a valid certificate for mta-sts.example.com, and sending MTAs fetch the policy from that exact well-known path.

What senders validate when MTA-STS is active

When a sender has a valid cached MTA-STS policy for your domain, it checks whether:

1. The selected MX matches one of the policy's mx patterns.
2. The MX supports STARTTLS.
3. The MX presents a valid certificate for that host from a trusted public CA.

If those checks fail, the sender's behavior depends on the policy mode.

mode: testing

This is the soft rollout mode.

Senders may still deliver as if no strict policy existed, but participating senders that implement TLS reporting can send failure reports. This is the safest place to start because it helps you see misconfigurations before you ask senders to refuse delivery.

mode: enforce

This is the strict mode.

When a sender honors the policy and cannot validate TLS or MX identity, it must not deliver to a non-compliant host. In practice, that means you should move to enforce only after you are confident that every active MX path, certificate, and hostname pattern is correct.

mode: none

This is the opt-out mode defined by the spec for clean removal of MTA-STS.

Where TLS-RPT fits

TLS-RPT stands for SMTP TLS Reporting and is defined in RFC 8460.

It complements MTA-STS by letting your domain publish a reporting destination under _smtp._tls.example.com.

Example:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

You can also use HTTPS for the rua destination.

The important operational point is this:

• TLS-RPT reports are sent by participating sending MTAs
• the reports are aggregate, not per-message forensic evidence
• the reports can include both success counts and failure categories

That means TLS-RPT is best for visibility and detection, not for debugging a single missing message in isolation.

What shows up in TLS-RPT reports

RFC 8460 defines result types such as:

• starttls-not-supported
• certificate-host-mismatch
• certificate-expired
• certificate-not-trusted
• sts-policy-fetch-error
• sts-policy-invalid
• sts-webpki-invalid

That makes TLS-RPT useful for spotting issues like:

• a backup MX that was forgotten in the policy
• a certificate renewed on the primary MX but not on another node
• a broken mta-sts HTTPS endpoint
• a sender seeing a policy fetch or validation problem you did not notice internally

It can also act as a heartbeat showing that policy-compliant TLS sessions are succeeding.

Why this is "beyond" DMARC rather than a replacement for it

It is tempting to group all of these records together as one email-security bundle, but the control planes are different.

So MTA-STS does not replace SPF, DKIM, or DMARC.

It hardens a different part of the mail flow: server-to-server delivery into your environment.

Common admin misunderstandings

"We already force HTTPS on our website, so we are covered"

Not for SMTP.

MTA-STS needs its own HTTPS policy endpoint at mta-sts.<domain> and applies to SMTP delivery, not browser traffic to your main website.

"Our MX offers STARTTLS, so MTA-STS adds nothing"

STARTTLS without policy is still opportunistic. MTA-STS adds authenticated expectations around the MX hostname and certificate and tells compliant senders what to do when those expectations fail.

"TLS-RPT means we will get reports from everyone"

No. Reporting depends on sender support and sender behavior. It is very useful, but it is not universal telemetry.

"This protects outbound mail from spoofing"

No. That is DMARC territory. MTA-STS is about inbound SMTP transport to your domain.

A practical rollout path

If you are deploying this on a production domain, the safest sequence is:

1. Inventory every live MX hostname, including backup and regional nodes.
2. Confirm each MX supports STARTTLS and presents the correct certificate for its hostname.
3. Publish the HTTPS policy host mta-sts.example.com with a valid certificate.
4. Publish an MTA-STS policy in testing mode.
5. Publish a TLS-RPT record so participating senders can report failures.
6. Watch reports and operational logs long enough to catch stale or forgotten MX paths.
7. Move to enforce only when you are confident the policy matches reality.

This is similar in spirit to a DMARC rollout: visibility first, enforcement second.

The easiest way to break MTA-STS

The most common failure is simple mismatch between policy and infrastructure.

Examples:

• policy lists mx1.example.com, but DNS still advertises mx-us.example.com
• primary MX certificate is valid, backup MX certificate is expired
• HTTPS policy file was updated, but the TXT id was not changed
• TXT id was changed before the new HTTPS policy was actually available

RFC 8461 explicitly warns that policy changes must be coordinated carefully because sending MTAs cache policies for up to max_age.

Operationally, that means careless updates can create temporary delivery failures even when your current config looks correct to you.

MTA-STS versus DANE for SMTP

You will sometimes see DANE mentioned in the same conversations.

DANE for SMTP also strengthens SMTP TLS, but it relies on DNSSEC. MTA-STS was designed as a deployable alternative for domains that want stronger transport policy without requiring DNSSEC everywhere.

For many administrators, MTA-STS is the more practical next step because it fits common web PKI and DNS hosting models.

What success looks like

A mature inbound posture often looks like this:

• SPF, DKIM, and DMARC protect domain identity and visible-author trust
• MTA-STS publishes strict expectations for inbound SMTP TLS
• TLS-RPT provides visibility when those expectations fail in the wild

That combination covers both who the message claims to be from and how the message reached your receiving infrastructure.

Bottom line

DMARC, DKIM, and SPF are necessary, but they are not the whole email-security story.

If you want to protect inbound SMTP against downgrade and MX impersonation risks, MTA-STS is the mechanism that tells participating senders which MX hosts are valid and when TLS must be trusted. TLS-RPT then gives you the reporting loop needed to detect policy and certificate problems before they quietly become delivery issues.

For domains that already take DMARC seriously, MTA-STS plus TLS-RPT is the natural next layer.