#readwise
# Mta-STS
## Metadata
- Author: [[dmarcian.com]]
- Full Title: Mta-STS
- URL: https://dmarcian.com/mta-sts/
## Highlights
- **MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers. It was designed to patch an existing hole in the STARTTLS protocol that allowed for communication to be unencrypted via an attacker who could remove parts of the SMTP session (such as the “250 STARTTLS” response). This is accomplished by bringing DNS as a third party to verify connections.**
- MTA-STS is short for SMTP MTA-STS, which is short for Simple Mail Transfer Protocol (SMTP) Mail Transfer Agent (MTA) Strict Transport Security (STS). The purpose of MTA-STS is to encrypt and secure communications between SMTP servers via TLS (Transport Layer Security) preventing man-in-the-middle attackers from viewing and manipulating in-transit emails.
- **The MTA-STS protocol works by having a DNS record that tells mail servers to fetch a policy file via HTTPS from a defined subdomain. This file contains a list of the receiver’s mail servers which are authenticated and approved to receive the messages and also what policy to apply to inbound messages.**
### What is the MTA-STS Policy File?
- This file is a plain text file containing a set of the following key/value pairs.
- `version`: The protocol version of the file. At the time of this writing, it must be STSv1.
- `mode`: This is the policy mode. The values available are `testing`, `enforce` or `none`.
- `testing`: Senders will send your reports (TLSRPT) indicating policy application failures. This requires TLSRPT to also be implemented to work. TLS connection failures will not be blocked, while being able to receive reports.
- `enforce`: Sending mail servers that support MTA STS will not deliver mail to your domain where the certificate authentication fails, or cannot negotiate TLS. Reports on these failures are sent as well.
- `none`: Senders will treat the domain as thought it does not have any active policy. It effectively disables MTA STS.
- `mx`: The MX records for the domain. It has to match the MX records published in your domain’s DNS. You can specify either the FQDN or a wildcard host (`mx: mail.example.org` or `mx: *.example.org`). Ensure each MX records are added on their own line in the policy file.
- `max_age`: The maximum lifetime of the policy expressed in seconds. This represents the length of time a sender would cache the domain’s policy. It is recommended to use a value equivalent of several weeks or greater, but not exceeding 31557600 (roughly 1 year).
Example of policy file:
```
version: STSv1
mode: testing
mx: mail.example.org
mx: *.example.org
mx: mail2.example.org
max_age: 604800
```
- Once the policy text file is ready, it must be published on the web to be accessed by senders.
The file must be available at a specific URL on a subdomain of your domain. An example of URL would be:
`https://mta-sts.[example.org]/.well-known/mta-sts.txt`
- A DNS TXT resource record is needed in order to enable MTA-STS on your domain. This record exists at a unique subdomain: `_mta-sts`. For the example.org domain, it would be `_mta-sts.example.org`. The TXT record contains 2 key/value pairs.
- `v` The version of the protocol, which currently only supports the value STSv1.
- `id` A string of 1 to 32 alphanumeric characters meant to track policy updates. This string must be updated every time there is a change made to your MTA-STS policy file. A good practice is to use the date and time of the change to make up the ID number.
An example of such record is as below:
`_mta-sts.example.org. IN TXT “v=STSv1; id=202104012135;”`