What Is MTA-STS and Why Does It Matter?

Mail Transfer Agent Strict Transport Security (MTA-STS) is an email security standard designed to ensure that emails are transmitted over secure, encrypted connections. In simpler terms, it forces email delivery over TLS (Transport Layer Security) and prevents attackers from eavesdropping or tampering with messages in transit Without MTA-STS, SMTP encryption (STARTTLS) is opportunistic – meaning encryption is optional and can be stripped away by attackers (a vulnerability known as a downgrade attack). This leaves emails potentially traveling as plaintext, like postcards anyone could read. MTA-STS closes this gap by requiring encryption and valid certificates for mail delivery to your domain

Why MTA-STS matters:

It protects against man-in-the-middle (MITM) attacks and STARTTLS downgrade attacks. For example, an attacker on the network could intercept an email and trick sending servers into sending it unencrypted; with MTA-STS in place, the sending server would refuse to send unless a secure TLS channel is established. This means:

• Your domain’s mail servers must use TLS encryption (v1.2 or higher) for incoming mail. Unencrypted delivery attempts will be rejected (if enforcement is enabled).
  
  
• The sending server will validate the receiving server’s certificate – ensuring it’s not expired and matches your domain’s mail hostnames
• You define which servers are authorized to receive mail for your domain (so attackers can’t redirect mail to rogue servers)
  
  
• You have enforcement options – you can start in a monitoring mode and later enforce the policy strictly
  
  

In short, MTA-STS adds a layer of trust on top of TLS by telling senders: “For this domain, encryption isn’t optional – and here’s how to securely reach my mail servers.” This boosts confidentiality and integrity of emails, preventing unauthorized access or modification. It complements existing email security protocols (like SPF, DKIM, DMARC, which fight spoofing) by protecting the transport layer, i.e., the path an email takes from sender to recipient.

How MTA-STS Works (Step-by-Step)

MTA-STS involves two main components: a DNS record and an HTTPS-hosted policy file. Together, these tell external mail servers how to securely deliver email to your domain. Here’s a step-by-step breakdown of the process:

• Policy Publication: You, as the domain owner, need to create an MTA-STS policy file (a simple text file) that defines your security requirements. This file is hosted on a web server at a fixed URL and TDMARC tool provide you a cname record to host and manage the web-server for the domain https://mta-sts.<your-domain>/.well-known/mta-sts.txt

For example, if your domain is threatcop.com, you would host the policy at https://mta-sts.threatcop.com/.well-known/mta-sts.txt on a site that supports HTTPS.

DNS Advertisement: In your DNS records, you publish record on a special subdomain _mta-sts.<your-domain>. This DNS TXT record indicates that your domain has an MTA-STS policy and provides a version ID for the current policy and TDMARC provides you one more CNAME entry to entirely manage this process for you.

• Here, v=STSv1 is the version (currently only “STSv1” is valid) and id=20250101T000000Z is an identifier string (often a timestamp or number) for your policy. The ID is used by senders to know if the policy has changed. (If you update the policy file, you should change this id value to signal an update.)
  
  
• Policy Discovery: When another mail server wants to send email to your domain, it first checks DNS for the _mta-sts record. If found, this tells the sending server that MTA-STS is supported. The sending server then knows it needs to retrieve the policy file from the mta-sts subdomain It makes an HTTPS request (verifying the TLS certificate) to 

mta-sts.threatcop.com/.well-known/mta-sts.txt and downloads the policy.

• Policy Evaluation: The sending mail server parses the MTA-STS policy file it just fetched. The policy will specify:
  
  

• Allowed MX hosts for the domain (mx entries in the file). These are the legitimate mail servers that should receive email for the domain If an attacker tries to redirect mail to a server outside this list, the policy will detect a mismatch.
  
  
• Policy mode – whether to enforce TLS strictly or not, ther are 3 mode: 
• Enforce
• Testing
•  None
  
  
• Policy max age – how long (in seconds) the policy can be cached by senders
  
  

• The sending server uses this information to decide how to proceed. For example, if the policy lists only mx1.example.com and mx2.example.com as valid mail exchangers, the sending server will expect the recipient’s MX DNS records and certificates to match those names.
  
  
• Secure Connection Attempt: Next, the sending server looks up your domain’s MX records (as usual) to find the actual hostnames of your mail servers. Under normal SMTP, it would then connect on port 25 and attempt STARTTLS if available. With MTA-STS in effect, the sending server requires that: (a) the connection can be upgraded to TLS, and (b) the TLS certificate presented by the MX matches the hostname and is signed by a trusted CA (Certificate Authority). The sending server initiates the SMTP connection and the STARTTLS negotiation and all these steps can be easily configured over the TDMARC tool with the help of 3 CNAME records.
  
  

• If a secure TLS connection is successfully established (e.g., your mail server offered STARTTLS and presented a valid certificate matching one of the mx names in the policy), then the email is sent over this encrypted channel Everything proceeds normally, with the reassurance that the link is secure.
  
  
• If the connection does not meet the policy requirements, the behavior depends on the policy mode:
  
  

• Enforce mode: The sending server must not deliver the email if TLS can’t be negotiated or the certificate validation fails. It will abort the delivery and usually generate a bounce or an error back to the sender, treating it as a delivery failure. In other words, it refuses to fall back to an insecure delivery.
  
  
• Testing (or Report-Only) mode: The sending server will still deliver the email, even if encryption fails or the certificate is untrusted, but it will send a report about this incident (if reporting is enabled). This mode is like a dry-run: you get to see what would have failed, without actually blocking any mail.
  
  
• None mode: The sending server will ignore the policy (treat the domain as if it had no MTA-STS). This essentially turns off MTA-STS for the domain. (Domains typically use “none” only if they need to temporarily disable MTA-STS or as a default before deploying.)
  
  

• Policy Caching: For efficiency, sending servers cache the fetched MTA-STS policy for the duration specified by max_age (which can be up to a year). That means the next time the same server sends email to your domain. If you update your policy file, you must update the DNS id value; when senders see a new id, they know to fetch the policy afresh rather than rely on cache
  
  
• Reporting: MTA-STS itself doesn’t notify you of issues – it just enforces encryption. However, there is a companion mechanism called SMTP TLS Reporting (TLS-RPT) that you can enable via another DNS record. TLS-RPT will cause sending servers to send you daily reports about any TLS failures or policy violations they encountered when emailing your domain.

In summary, MTA-STS works like a security guard for your domain’s inbound email: The DNS record is the sign that says “This site is protected – fetch policy for rules,” and the policy file is the rulebook that says “Only deliver via these secure channels, otherwise don’t deliver (or just report).” Legitimate sending servers will comply with these rules. Attackers who attempt to reroute or snoop on your mail by exploiting SMTP’s openness will be thwarted because the sending server will detect something’s wrong (no valid TLS, or wrong host) and refuse the connection.

Set Up SMTP TLS Reporting (TLS-RPT)

SMTP TLS Reporting is highly recommended to accompany MTA-STS. Without it, you have no easy way of knowing if something’s wrong – your mail might just silently not arrive if there’s a problem. TLS-RPT provides visibility by having external mail servers send you aggregated reports about TLS failures (and successes).

The TDMARC tool will provide you one TLS reporting CNAME record that need to be published on DNS record:

Example Value: a string specifying the reporting version and where to send reports. For example:

"v=TLSRPTv1; rua=mailto:tlsreports@mta-sts.kdmarc.com"

• This says version TLSRPTv1 (the current and only version) and rua (Reporting URI for aggregate reports) is an email address to send the reports to. 

What Data Does MTA-STS Provide?

MTA-STS itself doesn’t send back data to you when things go right – it simply causes sending servers to enforce encryption. However, the SMTP TLS Reporting (TLS-RPT) mechanism, when enabled, provides valuable data about how your policy is doing. The combination of MTA-STS + TLS-RPT gives you insight into:

• Which emails were successfully delivered with TLS (and how many).
  
  
• Which emails ran into issues because of encryption or certificate problems (and were either still delivered in testing mode or blocked in enforce mode).
  
  
• What those issues were – e.g., failed TLS negotiation, certificate name mismatches, expired certs, DNS problems, etc.
  
  
• Who is sending you these reports – usually large email providers who attempted to send you mail.