MTA-STS

From InboxSys document library
Revision as of 21:45, 1 November 2024 by Sebastian (talk | contribs) (Created page with "Category:Deliverability Category:Authentication In modern E-Mail communication, Opportunistic TLS is common. This means that TLS encryption for the transition of E-Mail is negotiated by MTAs on both ends. If two MTAs can agree on a TLS encryption method and cypher, transit proceeds TLS encrypted. If, however, no agreement can be reached, mail is transferred unencrypted. MTA-STS was introduced in [https://tools.ietf.org/h...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


In modern E-Mail communication, Opportunistic TLS is common. This means that TLS encryption for the transition of E-Mail is negotiated by MTAs on both ends. If two MTAs can agree on a TLS encryption method and cypher, transit proceeds TLS encrypted. If, however, no agreement can be reached, mail is transferred unencrypted.

MTA-STS was introduced in RFC 8461. It's main purpose is to secure TLS connections. MTA-STS compliant Mail is returned to the sender if the TLS negotiation fails.

Configuration and setup

MTA-STS is set up on a so-called "policy domain". This is the domain that holds the policy. Each RFC5322.From domain should have it's own MTA-STS policy configuration. Subdomains don't automatically inherit MTA-STS settings.

MTA-STS consists of two components:

  • Policy file
  • DNS record

Policy file

The policy file is stored on a webhost in the ".well-known" webdirectory with a subdomain of the policy domain named "mta-sts" and the filename named "mta-sts.txt". It must be reachable from outside and contain the following keys:

  • version: This is the mta-sts version used. Currently, "STSv1" is the only valid value.
  • mode: This can be either
    • testing: Testing mode,
    • enforce: Enforced TLS, or
    • none: MTA-STS is disabled. May be useful to receive TLSRPT reports only.
  • mx: Each MX has its own line.
  • max_age: Should not exceed 31557600 (~1 year).

For example, the policy domain for policydomain.TLD is located at https://mta-sts.policydomain.TLD/.well-known/mta-sts.txt and contains the following text: 

version: STSv1
mode: enforce
mx: mta1.policydomain.TLD
mx: mta2.policydomain.TLD
max_age: 86400

DNS record

In order to tell the world that a particular domain is an MTA-STS policy domain, it's required to create another subdomain with a TXT record present. The subdomain is "_mta-sts" and the TXT record syntax has two switches:

  • v: For "version". This is exactly the same key/value pair as in the policy file. "STSv1" currently is the only valid value.
  • id: A unique and incremental number, indicating the version update of the policy. This number should be changed each time the policy file is modified. It's recommended to use a generic value, such as date and time.

For example, policy domain "policydomain.TLD" could have the following DNS TXT MTA-STS record: 

_mta-sts.policydomain.TLD. IN TXT "v=STSv1; id=202403010850;"

TLS reporting

Main article: TLSRPT

RFC 8461 states that MTA-STS is intended to be used along with TLS reporting (TLSRPT) (RFC 8460). It doesn't include the recommendation to send reports, but MTA-STS compliant MTAs should be able to receive and process TLSRPT reports at least.

Useful links

Retrieved from "https://docs.inboxsys.com/index.php?title=MTA-STS&oldid=347"