MTA-STS Overview

Welcome to the MTA-STS documentation. Use the sidebar or the links below to navigate:

What is MTA-STS?

MTA-STS is a security protocol that enables email servers to enforce Transport Layer Security (TLS) encryption and certificate validation when sending emails to other servers that support the protocol. MTA-STS stands for Mail Transfer Agent Strict Transport Security over TLS, and it is defined in RFC 8461.

How Does MTA-STS Work?

MTA-STS works by allowing email servers to publish a policy that specifies how other servers should connect to them. The policy includes the following information:

• The duration of the policy's validity
• Whether TLS encryption is required or optional
• Whether the server's certificate must match the domain name or be signed by a trusted authority
• How to report any connection failures or policy violations

The policy is published in two ways: as a DNS TXT record and as a file hosted on a web server. The DNS TXT record contains a pointer to the web server where the policy file is located. The policy file is named .well-known/mta-sts.txt and it is formatted as a plain text file with key-value pairs.

When an email server wants to send an email to another server that supports MTA-STS, it first queries the DNS TXT record of the recipient domain to check if there is a policy available. If there is, it then fetches the policy file from the web server and follows the instructions in the policy. If the policy requires TLS encryption and certificate validation, the email server will only deliver the email if it can establish a secure and authenticated connection with the recipient server. If the policy is optional, the email server will try to use TLS encryption and certificate validation, but it will fall back to a plain text connection if it fails. If the policy is not available or expired, the email server will use its default settings for email delivery.

MTA-STS max-age Settings

The max_age directive in MTA-STS policy specifies the maximum lifetime of the policy in seconds. Here are some key points about it:

• Accepted Values: Any positive integer up to 31,557,600 seconds (which is equivalent to one year).
• Example: You can set max_age to 604,800 seconds (which is one week).

The purpose of max_age is to determine how long servers should cache your MTA-STS policy before checking for a new one. Google, for instance, processes policies with a max_age higher than 86,400 seconds (one day). The maximum value for max_age is 31,557,600 seconds.

Choosing an appropriate max_age value is crucial. Here are some considerations:

1. Shorter max_age:
   • Allows easier removal or changes of MTA-STS if interoperability issues arise.
   • Useful for large integrators that may not yet support MTA-STS but plan to in the future.
2. Longer max_age:
   • Reduces the frequency of policy checks.
   • Provides better performance by minimizing the need for frequent policy updates.
   • However, it also means that any necessary policy changes take longer to propagate.

How MTA-STS Works with DMARC

MTA-STS and DMARC complement each other in enhancing the security and privacy of email communication. MTA-STS protects the connection between email servers from interception and modification, while DMARC protects the content and header of the email from spoofing and phishing. By using both protocols, email servers and users can achieve a higher level of trust and confidence in their email communication.

Why is MTA-STS Important?

MTA-STS is important because it enhances the security and privacy of email communication. By enforcing TLS encryption and certificate validation, MTA-STS prevents attackers from intercepting, modifying, or spoofing emails in transit.

This reduces the risk of phishing, malware, spam, and identity theft. MTA-STS also helps email servers to comply with the security standards and regulations of their industry or region.

Limitations of MTA-STS

MTA-STS has some limitations that email servers and users should be aware of. Some of them are:

• Scope: MTA-STS only applies to the connection between email servers, not between email clients and servers. Therefore, email clients and users still need to use other security measures, such as end-to-end encryption, to protect their emails from unauthorized access or tampering.
• Reliance on DNS and Web Servers: MTA-STS relies on the availability and integrity of the DNS and web servers that host the policy. If these servers are compromised, offline, or misconfigured, the policy may not be accessible or accurate, and the email delivery may be affected.
• Policy Enforcement: MTA-STS does not prevent email servers from accepting or sending emails that do not comply with the policy. For example, an email server may accept an email from a sender that does not use TLS encryption or certificate validation, or it may send an email to a recipient that does not support MTA-STS. Therefore, email servers and users still need to use other security mechanisms, such as SPF, DKIM, and DMARC, to verify the identity and authenticity of the email senders and recipients.

Related Topics

• TLS-RPT Domain Settings - Configure TLS-RPT/MTA-STS Settings