---
title: Mail Transfer Agent Strict Transport Security
kind: note
description: 'Purpose The primary purpose of MTA-STS is to address vulnerabilities in the traditional SMTP (Simple Mail Transfer Protocol) email delivery process, specifically: 1. Preventing Downgrade Attacks:…'
words: 751
readingMinutes: 3
created: '2025-07-24T00:00:00.000Z'
updated: '2025-07-24T14:03:55+02:00'
---
# Purpose
The primary purpose of MTA-STS is to address vulnerabilities in the traditional <span class="dead-link">SMTP</span> (Simple Mail Transfer Protocol) email delivery process, specifically:
1. **Preventing Downgrade Attacks:** Historically, while [TLS](/notes/tls) was introduced to encrypt <span class="dead-link">SMTP</span> communications (often initiated with the `STARTTLS` command), it was optional. An attacker could strip out the STARTTLS command, forcing the [email](/notes/email) to be sent in plain text, making it vulnerable to interception and reading. MTA-STS prevents this by mandating [TLS](/notes/tls) encryption.
2. **Mitigating Man-in-the-Middle (MITM) Attacks:** In a MITM attack, an attacker intercepts communication between two [mail](/notes/email) servers, potentially altering the [email](/notes/email) or redirecting it to a malicious server. MTA-STS helps prevent this by ensuring that the sending server verifies the identity of the receiving server using valid [TLS](/notes/tls) certificates and only sends mail over authenticated, encrypted connections. 
3. **Enforcing [TLS](/notes/tls) Usage:** It provides a mechanism for <span class="dead-link">domain</span> owners to declare that their [mail](/notes/email) servers require [TLS](/notes/tls) encryption for all incoming mail, and to specify what should happen if a secure connection cannot be established (e.g., refuse delivery).
4. **Improving [Email](/notes/email) Privacy:** By enforcing encryption, MTA-STS helps protect the confidentiality of [email](/notes/email) content during transit, which is crucial for sensitive information.
5. **Building Trust and Compliance:** Implementing MTA-STS signals a commitment to [email](/notes/email) security, which can enhance trust with senders and help organizations comply with data protection and privacy regulations.
# How it works
MTA-STS works through a combination of [DNS](/notes/dns) records and a policy file hosted on a [web](/notes/web-development) server:
1. **Policy Publication:**
    - **MTA-STS Policy File:** The <span class="dead-link">domain</span> owner creates a plain-text policy file named `mta-sts.txt`. This file defines the rules for incoming [email](/notes/email), including:
        - `version: STSv1`: The version of the MTA-STS protocol.
        - `mode:`: The enforcement mode, which can be:
            - `testing`: Sending servers will report any issues with [TLS](/notes/tls) connections but will still deliver mail even if a secure connection cannot be established. This is recommended for initial deployment to identify and fix problems without disrupting mail flow.
            - `enforce`: Sending servers that support MTA-STS _must_ use [TLS](/notes/tls) and verify the certificate. If a secure connection cannot be established, they will refuse to deliver the mail.
            - `none`: Disables MTA-STS.
        - `mx:`: A list of the domain's legitimate MX (Mail eXchanger) servers (mail server hostnames) that are authorized to receive mail. Wildcards can be used.
        - `max_age:`: The maximum time (in seconds) that sending servers should cache this policy. A common value is 604800 seconds (7 days).
    - **Policy File Location:** This `mta-sts.txt` file must be hosted over <span class="dead-link">HTTPS</span> at a specific, well-known URL: `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt`. The web server hosting this file must have a valid, publicly trusted SSL/[TLS](/notes/tls) certificate.
    - **MTA-STS [DNS](/notes/dns) TXT Record:** The domain owner publishes a [DNS](/notes/dns) TXT record at `_mta-sts.yourdomain.com`. This record indicates that the domain supports MTA-STS and contains an `id` field. The `id` value should be updated whenever the policy file is changed, signaling to sending servers that a new policy is available.
        - Example TXT record: `_mta-sts.example.com. IN TXT "v=STSv1; id=20240724120000Z;"`
2. **Policy Discovery and Evaluation (by the Sending Server):**
    - When an external mail server (the "sending MTA") wants to send an email to a domain (e.g., `recipient@example.com`), it first checks for the `_mta-sts.example.com` [DNS](/notes/dns) TXT record.
    - If the record exists, the sending MTA then fetches the MTA-STS policy file from `https://mta-sts.example.com/.well-known/mta-sts.txt`. This fetch must be over a secure HTTPS connection, providing an initial layer of trust and preventing [DNS](/notes/dns) spoofing for the policy itself.
    - The sending MTA evaluates the policy, checking the `mode`, `mx` records, and `max_age`.
3. **Secure Connection Establishment:**
    - Based on the evaluated policy, the sending MTA attempts to establish a secure [TLS](/notes/tls) connection to one of the authorized MX servers listed in the policy.
    - It verifies that the receiving server presents a valid [TLS](/notes/tls) certificate that matches the domain name in the policy.
    - If the policy mode is `enforce` and a secure, authenticated connection cannot be established (e.g., [TLS](/notes/tls) isn't offered, or the certificate is invalid), the sending server will refuse to deliver the [email](/notes/email), preventing it from being sent over an insecure connection. If the mode is `testing`, it will report the failure but still attempt delivery (potentially over an insecure connection if a secure one fails).
4. **TLS Reporting (Optional but Recommended):**
	- Domain owners can also publish a `_smtp._tls.yourdomain.com` [DNS](/notes/dns) TXT record to specify an [email](/notes/email) address or URL where sending servers can send daily reports about MTA-STS connection attempts (successes and failures). This is known as *TLS-RPT* (TLS Reporting). These reports provide valuable insights for monitoring and troubleshooting MTA-STS implementation.
# Resources
- [List of common mail servers (mostly German) and their MTA-STS support](https://dismail.de/serverlist.html) - not updated since 2021
- [Hosting your MTA-STS policy using GitHub Pages](https://emailsecurity.blog/hosting-your-mta-sts-policy-using-github-pages)
