Understanding How MTA-STS Enhances Email Security

Overview

MTA-STS (Mail Transfer Agent Strict Transport Security) is a security protocol designed to improve the security of email in transit. It allows domain owners to declare a policy that enforces the use of TLS (Transport Layer Security) for SMTP connections to their domain. MTA-STS prevents attackers from intercepting or tampering with email communications by requiring that messages sent to the domain be encrypted and validated.

MTA-STS is an enhancement to the opportunistic encryption used in SMTP, which by default does not guarantee encryption, as connections can downgrade to plaintext without strict enforcement. With MTA-STS, senders can ensure that the receiving domain mandates the use of encryption, thus increasing the security of email delivery.

Workflow

1. Policy Declaration: The receiving domain publishes an MTA-STS policy via a DNS record and a web server that hosts the policy file.
2. Sender Queries the DNS: When an MTA sends an email to the receiving domain, it first queries the DNS to check if an MTA-STS policy is available.
3. Fetching the Policy: If the DNS query returns a valid MTA-STS policy record, the sending MTA fetches the policy from the specified HTTPS endpoint.
4. Policy Enforcement: The sending MTA checks the policy, which specifies whether to require TLS for email delivery. If the policy enforces strict TLS, the email will only be sent if a secure TLS connection can be established. If TLS cannot be negotiated, the email is not delivered.

Pros

• Prevents Downgrade Attacks: MTA-STS ensures that emails are transmitted over secure, encrypted channels, preventing attacks such as STARTTLS downgrades.
• Encrypted Delivery: MTA-STS enforces TLS encryption for emails in transit, ensuring that sensitive data is not transmitted over plaintext connections.
• Mitigates Man-in-the-Middle (MITM) Attacks: By enforcing TLS and requiring certificate validation, MTA-STS reduces the risk of MITM attacks, where attackers could intercept or modify emails in transit.

Cons

• Limited Support: Not all mail servers fully support MTA-STS yet, which limits its adoption and may not provide complete protection in all cases.
• DNS & HTTPS Configuration: Correctly configuring DNS and hosting the policy on an HTTPS server can be complex, especially for smaller organizations without technical expertise.
• No Email Bounce for Policy Failures: If a sender cannot deliver an email due to a failure to negotiate a TLS connection under MTA-STS, the message might not be delivered, but this failure may not always result in a bounce-back notification.

Details

DNS Record

MTA-STS is enabled by creating a DNS TXT record and hosting the policy file on a secure HTTPS server. The DNS record tells sending MTAs that the receiving domain supports MTA-STS and provides the URL where the policy file can be found.

DNS TXT Record

The DNS TXT record must be created at _mta-sts.[domain].[tld] and includes the version of the policy and the URL for fetching the policy file.

Example:

_mta-sts.example.com. IN TXT "v=STSv1; id=2021090100"

Field	Description
v=	The version of the MTA-STS protocol. This should always be set to STSv1.
id=	A unique identifier for the policy. This can be a timestamp or version number to track updates.

MTA-STS Policy File

The policy file is hosted on a secure HTTPS server at https://mta-sts.[domain]/.well-known/mta-sts.txt. This file defines the rules for enforcing TLS connections. It includes parameters such as the version of the policy, the mode (enforce or testing), and the list of valid MX hosts.

Example Policy File

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 86400

Field	Description
version:	The version of the MTA-STS protocol. Must be STSv1.
mode:	Specifies the mode of the policy. Can be enforce, testing, none. In enforce mode, emails will only be delivered if TLS is properly negotiated.
mx:	Lists the MX servers that are allowed to receive email for the domain.
max_age:	Specifies how long the policy is valid, in seconds. After this period, the sending MTA will query the DNS again to fetch the latest policy.

Policy Modes

MTA-STS supports different modes to allow for gradual rollout and testing.

Mode	Description
enforce	Strict mode that requires TLS for all connections. Emails will only be delivered if the TLS connection is successfully negotiated.
testing	Emails will be delivered even if the TLS connection fails, but logs will record whether TLS was successfully used. This is useful for testing MTA-STS without risking message delivery failures.
none	Disables MTA-STS enforcement but allows the policy file to remain in place for future use.

Example MTA-STS Workflow

1. A sending mail server attempts to deliver an email to [email protected].
2. The sending server queries _mta-sts.example.com for the MTA-STS DNS record.
3. The DNS TXT record is found, containing v=STSv1; id=2021090100.
4. The sending server fetches the policy from https://mta-sts.example.com/.well-known/mta-sts.txt.
5. The policy specifies that the connection should use enforce mode and lists mail.example.com as the valid MX server.
6. The sending server attempts to negotiate a TLS connection with mail.example.com.
7. If the TLS connection is successful and the certificate is valid, the email is delivered securely. If not, the email is not delivered (if in enforce mode).

Long DNS Records

Like other DNS-based security protocols (e.g., SPF, DKIM), MTA-STS records may become long, especially if multiple parameters are included. However, DNS TXT records can be split across multiple strings, as per DNS standards, allowing for flexibility in configuration.

Example of a Long DNS Record

_mta-sts.example.com. IN TXT "v=STSv1; id=2021090100; other-configurations"
                      "additional-strings-can-go-here"

Multiple strings in a DNS record are concatenated together when used.

Troubleshooting

• Policy Not Found: If the policy file cannot be found at the specified HTTPS URL, the sending MTA will not enforce MTA-STS.
• Invalid Certificates: If the TLS certificates for the receiving domain's mail servers are invalid or expired, email delivery will fail if the policy is in enforce mode.
• MX Record Mismatch: Ensure that the MX servers listed in the MTA-STS policy match those configured in the DNS MX records. A mismatch could result in delivery failures.

Common Errors and Solutions

Error	Cause	Solution
Policy Fetch Failure	Incorrect HTTPS URL or missing policy file.	Verify that the policy is correctly hosted athttps://mta-sts.example.com/.well-known/mta-sts.txt.
TLS Negotiation Failure	Invalid or missing TLS certificates on the MX servers.	Ensure valid certificates are in place and that the MX servers are correctly configured to support TLS.
MX Record Mismatch	The MX servers listed in the MTA-STS policy do not match DNS records.	Ensure that the MX records in DNS match those listed in the policy.

Benefits of MTA-STS

• Prevents Downgrade Attacks: Ensures emails are only delivered over TLS and mitigates potential downgrade attacks where the encryption is stripped.
• Strengthens Email Security: Improves the security of emails in transit by enforcing encryption.
• Compatibility with Other Standards: MTA-STS complements other email authentication protocols such as SPF, DKIM, and DMARC, offering an additional layer of security.

Drawbacks

• Not Universally Supported: Some email servers do not yet support MTA-STS, meaning its enforcement may be limited in some cases.
• Complex Configuration: Setting up and maintaining MTA-STS policies, along with valid certificates and DNS records, requires careful configuration and ongoing monitoring.