MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard specified in RFC 8461 that enables mail servers to enforce secure, encrypted TLS connections for inbound email traffic.

It prevents Man-in-the-Middle (MitM) and TLS-downgrade attacks by requiring sending servers to negotiate encrypted connections and verify the receiving server's TLS certificate before delivering email.

When an external mail transfer agent (MTA) attempts to send an email to your domain, it executes the following steps:

# **DNS TXT Record Check:** Queries DNS for ''_mta-sts.yourdomain.com'' to check if MTA-STS is enabled and if the policy version has changed.
# **Policy Fetching:** Fetches the host's policy file over HTTPS from ''https://mta-sts.yourdomain.com/.well-known/mta-sts.txt''.
# **TLS Certificate Verification:** Connects to the destination mail server via SMTP and verifies that its TLS certificate matches the hostnames listed in the MTA-STS policy file.
# **Enforcement:**
  * If TLS validation succeeds: Delivers the email over an encrypted TLS connection.
  * If TLS validation fails or is tampered with (in ''enforce'' mode): Aborts delivery and drops the unencrypted connection.

The policy file must be hosted via HTTPS on a dedicated web endpoint at: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mail.telenegar.ir
mx: *.telenegar.ir
max_age: 604800

• testing: Sending MTAs evaluate TLS validity and send failure reports (via TLS-RPT), but deliver unencrypted mail if TLS fails. (Recommended for initial setup).
• enforce: Sending MTAs must negotiate valid TLS. Delivery is rejected if encryption fails or certificates are invalid.
• none: Disables MTA-STS enforcement.

To notify sending MTAs that your domain supports MTA-STS, create a TXT record at _mta-sts.yourdomain.com.

• v=STSv1: Protocol version tag.
• id=YYYYMMDDNN: Unique identifier string (usually a timestamp or hash). Note: Whenever you update your HTTPS policy file, you must change this ID value in DNS so remote servers clear their cache and fetch the new policy.

To implement MTA-STS successfully, satisfy the following infrastructure requirements:

• HTTPS Subdomain: Set up an HTTP/S web server or CDN endpoint resolving to mta-sts.yourdomain.com.
• Valid SSL/TLS Certificate: The HTTPS server for mta-sts.yourdomain.com must serve a valid, public SSL certificate (e.g., Let's Encrypt).
• Correct Path: Host the plain text file strictly at /.well-known/mta-sts.txt returning HTTP header Content-Type: text/plain.

In enforce mode, if your mail server's SSL certificate expires or becomes invalid, external MTAs enforcing MTA-STS will bounce inbound email rather than falling back to plain-text port 25.

Ensure every hostname defined in your MX Records is explicitly covered by an mx: line in your mta-sts.txt policy file.

If you modify your MX configuration, remember to update the id= tag in your _mta-sts DNS record to force external servers to refresh their cached policy.

You can verify your MTA-STS record, MX configuration, and TLS status using Telenegar Tools or terminal commands:

• DNS Lookup: Validate your _mta-sts TXT record with the Telenegar DNS Check Tool.
• Mail Server Diagnostics: Audit outbound encryption capabilities and MX setup using the Telenegar Mail Check Tool.

 bash
dig +short TXT _mta-sts.example.com

 cmd
nslookup -type=TXT _mta-sts.example.com

 bash
curl -i https://mta-sts.example.com/.well-known/mta-sts.txt

• Telenegar DNS Check Tool — Diagnostic tool for DNS record lookup and propagation.
• Telenegar Mail Check Tool — Diagnostic tool for email authentication and encryption health.
• TLS-RPT (TLS Reporting) — Receive automated reports on MTA-STS enforcement failures.
• MX Records — Configure mail exchanger targets for your domain.
• DMARC — Complete your email security suite alongside MTA-STS.