MTA-STS - Revision history

Sebastian at 13:52, 15 August 2025

2025-08-15T13:52:10Z

← Older revision		Revision as of 15:52, 15 August 2025
Line 4:		Line 4:
	In modern E-Mail communication, [[wikipedia:Opportunistic_TLS\|Opportunistic TLS]] is common. This means that [[wikipedia:Transport_Layer_Security\|TLS]] encryption for the transition of E-Mail is negotiated by [[MTA]]s 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.		In modern E-Mail communication, [[wikipedia:Opportunistic_TLS\|Opportunistic TLS]] is common. This means that [[wikipedia:Transport_Layer_Security\|TLS]] encryption for the transition of E-Mail is negotiated by [[MTA]]s 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/html/rfc8461 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.		'''SMTP MTA Strict Transport Security''' (MTA-STS) was introduced in [https://tools.ietf.org/html/rfc8461 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=		=Configuration and setup=
Line 54:		Line 54:
	''Main article: [[TLSRPT]]		''Main article: [[TLSRPT]]

	RFC 8461 states that <q>MTA-STS is intended to be used along with TLS reporting (TLSRPT)</q> ([https://tools.ietf.org/html/rfc8460 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.		RFC 8461 states that <q>MTA-STS is intended to be used along with TLS reporting (TLSRPT)</q> ([https://tools.ietf.org/html/rfc8460 RFC 8460]). It doesn't include the recommendation to send reports, but MTA-STS compliant domains should be able to receive and process TLSRPT reports at least.

	=Useful links=		=Useful links=

Sebastian at 11:53, 15 August 2025

2025-08-15T11:53:34Z

← Older revision		Revision as of 13:53, 15 August 2025
Line 2:		Line 2:
	[[Category:Authentication]]		[[Category:Authentication]]

	In modern E-Mail communication, [[wikipedia:Opportunistic_TLS\|Opportunistic TLS]] is common. This means that [[TLS]] encryption for the transition of E-Mail is negotiated by [[MTA]]s 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.		In modern E-Mail communication, [[wikipedia:Opportunistic_TLS\|Opportunistic TLS]] is common. This means that [[wikipedia:Transport_Layer_Security\|TLS]] encryption for the transition of E-Mail is negotiated by [[MTA]]s 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/html/rfc8461 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.		MTA-STS was introduced in [https://tools.ietf.org/html/rfc8461 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.

Sebastian: 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..."

2024-11-01T20:45:36Z

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..."

New page

[[Category:Deliverability]]
[[Category:Authentication]]

In modern E-Mail communication, [[wikipedia:Opportunistic_TLS|Opportunistic TLS]] is common. This means that [[TLS]] encryption for the transition of E-Mail is negotiated by [[MTA]]s 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/html/rfc8461 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:

<pre>
version: STSv1
mode: enforce
mx: mta1.policydomain.TLD
mx: mta2.policydomain.TLD
max_age: 86400
</pre>

==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:

<pre>
_mta-sts.policydomain.TLD. IN TXT "v=STSv1; id=202403010850;"
</pre>

=TLS reporting=

''Main article: [[TLSRPT]]

RFC 8461 states that <q>MTA-STS is intended to be used along with TLS reporting (TLSRPT)</q> ([https://tools.ietf.org/html/rfc8460 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=

* [https://tools.ietf.org/html/rfc8460 RFC 8460]: TLSRPT RFC
* [https://tools.ietf.org/html/rfc8461 RFC 8461]: MTA-STS RFC
* [https://inboxsys.com/dmarc-monitor/ InboxSys DMARC Monitor]
* [[wikipedia:Opportunistic_TLS]]