MTA-STS, TLS Reporting and ARC

SPF, DKIM and DMARC establish who is allowed to send as your domain. They say nothing about whether a message is encrypted while it travels, or about what happens to authentication when a message is forwarded. Three further standards address those gaps: MTA-STS and TLS reporting for encryption in transit, and ARC for forwarded mail.

The Problem With Opportunistic TLS

Most mail servers encrypt connections using STARTTLS. This encryption is opportunistic. The sending server asks whether the receiver supports TLS, and if the answer is missing or blocked, it falls back to sending in plain text.

An attacker positioned between two servers can strip out the STARTTLS offer and force that fallback, or redirect mail by tampering with DNS. Neither server notices. Opportunistic TLS protects against passive eavesdropping, but not against an active attack.

MTA-STS

MTA-STS, defined in RFC 8461, lets a domain declare that mail sent to it must be delivered over TLS, to servers with valid certificates. A sending server that supports MTA-STS will refuse to deliver if those conditions are not met.

Note the direction. MTA-STS protects mail sent to your domain. It is a policy for inbound mail.

How It Is Published

MTA-STS has two parts.

A DNS TXT record signals that a policy exists:

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

A policy file is served over HTTPS at a fixed address:

https://mta-sts.example.com/.well-known/mta-sts.txt

The file contains four fields: version: STSv1, a mode, one mx line for each mail server that may receive your mail, and max_age, the number of seconds a sender may cache the policy.

Modes

• testing means senders report failures but still deliver.
• enforce means senders must not deliver if TLS or certificate validation fails.
• none withdraws the policy.

Whenever the policy file changes, update the id value in the DNS record so senders know to fetch it again.

TLS Reporting

TLS-RPT, defined in RFC 8460, asks sending servers to report on TLS connections to your domain. Reports show how many sessions succeeded and why any failed, such as an expired certificate or a policy mismatch.

It is published as a DNS TXT record:

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Reports arrive as JSON files, usually daily. As with DMARC, a reporting service makes them readable. Enable TLS-RPT before or alongside MTA-STS, so that you can see problems while the policy is still in testing mode.

Deployment Steps

1. List every MX host that receives mail for the domain.
2. Confirm that each one supports TLS 1.2 or later and presents a valid certificate matching its hostname.
3. Publish the TLS-RPT record and start collecting reports.
4. Host the policy file on the mta-sts subdomain over HTTPS, in testing mode.
5. Publish the _mta-sts DNS record.
6. Review reports for a few weeks.
7. Switch the policy to enforce and update the id.

If you later change mail provider, update the mx lines in the policy before you change the MX records. Otherwise senders with a cached policy may refuse to deliver.

ARC

ARC, the Authenticated Received Chain, addresses a different problem. When a message passes through an intermediary such as a mailing list or a forwarding service, authentication often breaks. SPF fails because the forwarding server is not in the original sender's record. DKIM fails if the intermediary changes the subject or adds a footer. DMARC then fails for a message that was legitimate when it was first sent.

ARC, defined in RFC 8617, lets each intermediary record the authentication results it saw and sign that record. It adds three headers:

• ARC-Authentication-Results records the SPF, DKIM and DMARC results at that hop.
• ARC-Message-Signature signs the message as it was at that hop.
• ARC-Seal signs the ARC headers themselves, forming a chain.

A receiving server can examine the chain and, if it trusts the intermediaries that sealed it, accept a message that would otherwise fail DMARC.

Who Needs to Act

ARC is added by intermediaries, not by original senders. If you only send your own mail, there is nothing for you to configure. Your best protection against forwarding problems is to DKIM-sign everything with your own domain.

If you operate a mailing list, a forwarding service or a mail gateway that modifies messages, you should add ARC headers. Google's sender guidelines ask services that regularly forward email to do so. Google and Microsoft both evaluate ARC, and Microsoft 365 lets administrators designate trusted ARC sealers.

ARC is a signal, not an override. A receiver decides whether to trust a given sealer, so results vary.

How the Standards Fit Together

• SPF, DKIM and DMARC authenticate the sender and protect your domain from spoofing.
• MTA-STS and TLS-RPT protect mail to your domain while it is in transit.
• ARC preserves authentication results across forwarding.

None of these three affects inbox placement for your outbound campaigns directly. They complete the security of a domain's email, and they are increasingly expected in security reviews and compliance frameworks.

Common Mistakes

• Enabling enforce mode before reviewing TLS reports.
• Leaving an MX host out of the policy file.
• Letting the certificate on the mta-sts subdomain expire.
• Changing the policy without updating the id in DNS.
• Assuming ARC must be configured by ordinary senders.
• Treating MTA-STS as a replacement for DMARC. They solve different problems.