SMTP MTA Strict Transport Security (MTA-STS) (defined in RFC 8461) provides a way for domain owners to tell email services that they should only send email to their domain over a verified TLS connection to specific email servers. This prevents man-in-the-middle attacks if the sending server supports the standard and the policy is set to enforce, similar to how HTTP Strict Transport Security (HSTS) works for web servers. With MTA-STS, the use of TLS can be enforced for incoming email from servers that support MTA-TLS without disabling port 25 and breaking applications that use STARTTLS opportunistic encryption to send email.

Deployment of MTA-STS consists of a TXT DNS record, and a policy file hosted at a specific HTTPS URL. The TXT DNS record must be located at the subdomain _mta-sts. The record must start with v=STSv1; and include a unique alphanumeric ID. The ID is used to track policy updates, so senders can see if a policy has changed. By convention, this is usually a timestamp. For example, v=STSv1; id=20160831085700Z;.

The MTA-STS policy file must be located at https://mta-sts.example.com/.well-known/mta-sts.txt, replacing example.com with the actual domain.

The MTA-TLS policy file uses key:value pairs, one per line:

    mx: mail.example.com
    mx: *.example.net
    

Here is a complete example policy file:

        version: STSv1
        mode: enforce
        mx: mail.example.com
        mx: *.example.net
        mx: backupmx.example.com
        max_age: 604800
      

Start out with a policy in testing mode, use this website to validate the policy, and briefly monitor TLS reporting for any legitimate failures. If no such failures are found, change the mode in the policy file to enforce, and update the id value in the _mta-sts TXT DNS record. The id value must be updated after any change, such as modifying mx values in the policy.

SMTP TLS Reporting (Referred to in the spec as TLSRPT, though often called TLS-RPT elsewhere) is a mechanism (defined in RFC 8460) for sending email servers to provide statistics to domain owners about failures to establish TLS connections for SMTP. This allows domain owners to proactively identify TLS misconfigurations and man-in-the-middle attacks. Many commercial and open source DMARC parsing providers also support parsing TLSRPT reports, including ParseDMARC.

To set up TLSRPT, simply publish a TLSRPT policy as a DNS TXT record at the subdomain _smtp._tls. Like DMARC and MTA-STS DNS records, this DNS record consists of tag=value pairs separated by semicolons.

Here is the schema of a TLSRPT report.

 {
   "organization-name": organization-name,
   "date-range": {
     "start-datetime": date-time,
     "end-datetime": date-time
   },
   "contact-info": email-address,
   "report-id": report-id,
   "policies": [{
     "policy": {
       "policy-type": policy-type,
       "policy-string": policy-string,
       "policy-domain": domain,
       "mx-host": mx-host-pattern
     },
     "summary": {
       "total-successful-session-count": total-successful-session-count,
       "total-failure-session-count": total-failure-session-count
     },
     "failure-details": [
       {
         "result-type": result-type,
         "sending-mta-ip": ip-address,
         "receiving-mx-hostname": receiving-mx-hostname,
         "receiving-mx-helo": receiving-mx-helo,
         "receiving-ip": receiving-ip,
         "failed-session-count": failed-session-count,
         "additional-information": additional-info-uri,
         "failure-reason-code": failure-reason-code
         }
       ]
     }
   ]
 }