What is MTA-STS? SMTP security policy explained

What are the requirements?

The domain publishes an MTA-STS DNS discovery record

RFC 8461 defines a TXT record at _mta-sts below the policy domain. The record contains v=STSv1 and an id value. The id signals that the policy may have changed, so a sender can decide whether to fetch a replacement.

_mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20260811"

This is illustrative only. Do not copy the example id as an operating process. Change the id when the policy content changes, and account for DNS and policy caching before assuming every supporting sender has retrieved the new policy.

A DNS record alone is insufficient. The record tells a sender where MTA-STS exists, but the enforcement mode, MX patterns, and cache duration are in the HTTPS policy.

The domain hosts a policy file over HTTPS

RFC 8461 specifies a fixed HTTPS retrieval URL:

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

The policy file contains version, mode, one or more mx fields, and max_age.

version: STSv1
mode: testing
mx: mail.yourdomain.com
max_age: 86400

This policy is illustrative only. Replace the example MX hostname with the real receiving MX hostname or supported wildcard pattern after confirming the production mail infrastructure.

The policy host needs HTTPS that a supporting sender can validate. The mx fields identify the hosts permitted to receive mail under the policy. They do not create mail routing records and do not replace the domain's DNS MX records.

The policy mode controls requested sender behavior

RFC 8461 defines enforce, testing, and none policy modes.

• enforce tells a supporting sender that delivery requires a valid TLS connection to an MX host matching the MTA-STS policy.
• testing tells a supporting sender to evaluate the policy and report failures, while continuing normal delivery behavior.
• none tells a supporting sender that the domain does not request MTA-STS enforcement through the current policy.

Do not move to enforce until every active production MX host presents a certificate that validates for its SMTP hostname. A mismatch can delay or prevent delivery from supporting senders.

For a closer explanation of the mode field, see what mode means in an MTA-STS policy.

Supporting senders cache the policy

The max_age field tells a supporting sender how long it may cache a retrieved policy. RFC 8461 uses cached policy data to preserve transport protections when a later policy lookup fails.

A policy update is therefore not an immediate global switch. Plan MX changes, certificate renewals, and policy edits around the published cache lifetime. The DNS id indicates a changed policy, but it does not guarantee that every supporting sender has refreshed at the same time. See what max_age means in an MTA-STS policy for the cache-specific behavior.

When does the requirement take effect?

RFC 8461 was published in September 2018 as an IETF Proposed Standard. It is the controlling MTA-STS specification. It did not replace an earlier MTA-STS RFC, and it does not set a universal enforcement date for all email domains.

A domain's policy becomes relevant when that domain publishes the required DNS record and policy file, and when a sending system that supports RFC 8461 delivers mail to it. The effective behavior also depends on the policy's mode and any cached policy held by the sender.

What is SMTP TLS Reporting?

SMTP TLS Reporting, or TLS-RPT, is defined in RFC 8460, published in September 2018 as a Proposed Standard alongside MTA-STS. It is the mechanism that gathers information about the TLS connections senders establish when delivering mail to a domain: a reporting sender generates a report that identifies which TLS sessions succeeded and which failed, along with the reasons behind failed connections, such as failed TLS negotiation, DNS-related issues, or problems with the MTA-STS policy itself. TLS-RPT does not make MTA-STS mandatory, and the TLS-RPT specification guide covers the standard in full.

To receive reports, the domain publishes a DNS TXT record at _smtp._tls that specifies where they should be delivered, including the URI that receives them. Reviewing the reports shows whether supporting senders are reaching the domain over secure connections and points at the failures to investigate.

The TLS report structure

TLS reports are JSON documents, delivered gzipped as application/tlsrpt+json. A report contains these components:

• Report ID: a unique identifier assigned to each report, used to track and reference it.
• Date range: the start and end dates of the period the report covers.
• Organization name: the reporting party that generated the report.
• Contact info: how to reach the reporting party with questions.
• Policies: the policies the sender evaluated for the domain. RFC 8460 defines three policy types: sts (MTA-STS), tlsa (DANE), and no-policy-found. For MTA-STS, this section repeats the policy file string.
• Summary: the total counts of successful and failed TLS sessions during the reporting period.
• Failure details: the type of each failure, such as failed TLS negotiation, a DNS-related issue, or an MTA-STS problem, plus the sending server, receiving IP, and MX hostname involved in the failed connection.

How do I implement the requirement?

1. Inventory every production receiving MX host

Retrieve the domain's MX records and identify every hostname that can receive production email. Include active failover hosts and any provider-operated host that receives mail for the domain.

Compare the list with the certificate names presented during SMTP TLS negotiation. An MTA-STS policy must authorize the real destination hosts that supporting senders use.

2. Verify TLS and certificate behavior on each host

Test each production MX host for SMTP TLS availability and certificate validation. Confirm that the certificate identity covers the hostname a sender reaches.

A public DNS result can show published MX records, but it cannot prove the live certificate behavior seen from every SMTP sending path. Keep message delivery tests and mail-server logs when investigating a TLS failure.

3. Publish the DNS record and HTTPS policy

Publish the _mta-sts TXT record with v=STSv1 and a new id. Serve the policy at the RFC-defined HTTPS path.

Begin with testing while you compare the policy's mx fields against active MX records, TLS certificates, and operational failover paths. Update the DNS id whenever the policy changes.

4. Add TLS-RPT when failure reports are needed

Publish TLS-RPT separately according to RFC 8460's SMTP TLS reporting requirements. Route reports to a monitored mailbox or processing endpoint that the team can review.

Use reports to investigate policy retrieval failures, certificate failures, and MX mismatches. The absence of reports does not prove that all sending systems reached the domain successfully.

5. Change to enforce after the evidence supports it

Move to enforce only after each active MX host has passed the TLS and certificate checks, the HTTPS policy is reachable, and the policy's MX patterns match the production path.

Keep a rollback plan. If an MX migration or certificate issue appears after enforcement, restore a safe policy mode only after identifying the affected hosts and the impact on mail delivery.

How do I validate compliance?

Validate MTA-STS in separate layers:

• Check DNS: confirm the authoritative DNS response and at least one public resolver return the intended _mta-sts TXT record.
• Check the policy host: retrieve /.well-known/mta-sts.txt over HTTPS and confirm that its syntax, mode, MX patterns, and max_age match the intended policy.
• Check SMTP TLS: test every active MX host for TLS negotiation and certificate validation under its delivery hostname.
• Check sender evidence: inspect TLS-RPT reports when configured, plus SMTP logs or delivery records from the actual sending path.
• Check ongoing changes: repeat the checks after MX, certificate, DNS, or mail-provider changes.

A public checker can identify published MTA-STS configuration issues. It cannot prove every production sender supports MTA-STS, continuously test each SMTP path, or establish how a specific mailbox provider handled an individual message.

Check the published MTA-STS policy before enforcing it

Run the receiving domain through the MTA-STS checker to inspect the published DNS record and HTTPS policy. Compare the result with the domain's real MX inventory and SMTP TLS evidence before moving from testing to enforce.

For teams responsible for many domains, Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies authentication and alignment issues, and creates prioritized remediation tickets. It can help organize the sender-authentication work that accompanies a broader domain-security program, while a human reviews the evidence and applies policy changes.

Start with Palisade

Palisade can also host a domain's MTA-STS policy through CNAME delegation, with the agent proposing changes and a human approving them before anything is applied. It does not prove SMTP TLS behavior for every sender or guarantee future mail delivery.