Enhancing Email Security with MTA-STS and TLS Reporting in Google Workspace

This guide provides a comprehensive overview for Google Workspace administrators on implementing and managing MTA-STS (MTA Strict Transport Security) and TLS (Transport Layer Security) reporting to enhance email security for your domain. It covers the core concepts, setup procedures, and troubleshooting insights to ensure secure email communication.

Understanding MTA-STS and TLS Reporting

Email communication, traditionally reliant on Simple Mail Transfer Protocol (SMTP), is inherently vulnerable to certain security threats, such as man-in-the-middle attacks, where communication between two servers can be intercepted and altered without detection. While SMTP supports TLS for encryption, many SMTP servers may not enforce its use, or might use outdated TLS versions or invalid certificates.

MTA-STS and TLS reporting are designed to address these vulnerabilities by enforcing authentication and encryption for email connections, thereby increasing Gmail security for your domain.

What is MTA-STS?

MTA-STS ensures that external mail servers sending email to your domain do so only over SMTP connections that are both:

• Authenticated with a valid public certificate.
• Encrypted with TLS 1.2 or higher.

When a sending server supports MTA-STS and the receiving server has an MTA-STS policy in enforced mode, messages are transmitted only over these secure connections. Similarly, Gmail messages from your domain comply with MTA-STS when sent to external servers with an MTA-STS policy in enforced mode.

MTA-STS tells sending servers not to send messages unless the sending server supports MTA-STS, and the receiving server has a published MTA-STS policy in enforced mode.

What is TLS Reporting?

TLS reporting requests daily reports from external mail servers that connect to your domain. These reports provide valuable information about any connection problems encountered by external servers when sending mail to your domain. This data is crucial for identifying and resolving security issues related to your mail server.

Reports contain information about the MTA-STS status, connection status, traffic statistics, failed connections, and messages that couldn't be sent. Before enforcing MTA-STS encryption and authentication, it is recommended to set your policy to testing mode and use these daily reports to identify and fix any connection issues.

Prerequisites and Server Requirements for MTA-STS

Before configuring MTA-STS, ensure your mail servers that receive incoming mail meet the following criteria:

• They require mail to be transmitted via a secure (TLS) connection.
• They use TLS version 1.2 or later.
• The server TLS certificates:
  • Match the domain name used by the inbound mail server (the server in your MX records).
  • Are signed and trusted by a root certificate authority.
  • Are not expired.

Setting Up MTA-STS and TLS Reporting

The setup process involves checking your current configuration, creating and publishing an MTA-STS policy, and updating your domain's DNS TXT records.

1. Checking Your MTA-STS Configuration

You can check your current MTA-STS configuration in Google Workspace to identify domains without a configuration or with an invalid one.

• Check status and get suggested configurations (Recommended for first-time setup): This option provides valid configurations to use in your policy file and DNS TXT records for missing or invalid configurations.
  • Sign in to the Google Admin console with an administrator account.
  • Navigate to Menu > Apps > Google Workspace > Gmail > Compliance.
  • Scroll to MTA-STS and click Validate your MTA-STS configuration here.
  • Click on a domain name to view its current configurations: MTA-STS DNS TXT record (_mta-sts), MTA-STS policy file, and TLS reporting DNS TXT record (_smtp._tls).
  • If an invalid configuration is found, the left column shows an error message, and the right column provides a suggested configuration. For missing configurations, it will show "Not Configured" with a suggested configuration.
• Check status only on the security health page: This option shows the status (Correctly configured, Configured for all domains, Missing or misconfigured) but does not provide suggested configurations. This option requires a Google Workspace edition that includes security health.
  • Sign in to the Google Admin console with an administrator account.
  • Go to Security > Security Health > MTA-STS.

2. Creating an MTA-STS Policy

An MTA-STS policy defines the mail servers in your domain that use MTA-STS. Each domain must have a separate plain text policy file named mta-sts.txt, though content can be similar. The file size can be up to 64 KB. You must update this file every time you add or change mail servers or change the domain.

The policy file includes key-value pairs, with the version field on the first line.

• Policy Modes:

  • Testing mode: External servers send daily reports on connection issues, but MTA-STS encryption and authentication requirements are not enforced. It's recommended to start with testing mode for two weeks to identify and fix problems before enforcing.
  • Enforce mode: Your domain requests external servers to verify the SMTP connection is both encrypted and authenticated. If not, servers supporting MTA-STS will not send mail to your domain. You continue to receive daily reports.
  • None mode: Tells external servers that your domain no longer supports MTA-STS. Use this when you stop using MTA-STS.

• Policy File Contents:

  • version: Protocol version, must be STSv1.
  • mode: Can be testing, enforce, or none.
  • mx: MX record for the domain. The policy must have an mx entry for each MX record added to the domain, on its own line. Wildcards (*) can be used for naming patterns (e.g., *.solarmora.com).
  • max_age: Maximum time in seconds the policy is valid. The value must be between 86400 (1 day) and 31557600 (about 1 year). For testing mode, 604800 to 1209600 seconds (1-2 weeks) is recommended.

Example Policy File (Testing Mode):

version: STSv1
mode: testing
mx: mail.solarmora.com
mx: *.solarmora.net
mx: backupmx.solarmora.com
max_age: 604800

3. Publishing Your MTA-STS Policy

After creating your policy file, you must upload it to a public web server where remote servers can access it.

• Host Server Requirements:
  • Must support SSL/HTTPS.
  • Server certificate must be signed and trusted by a third-party root certificate authority.
• Steps to Add Policy to a Web Server:
  • Verify your domain is set up with a public web server.
  • Add a subdomain to your domain starting with mta-sts, for example: mta-sts.solarmora.com.
  • Create a directory named .well-known in the subdomain.
  • Upload the mta-sts.txt policy file to the .well-known directory.

An example URL for an MTA-STS policy is: https://mta-sts.solarmora.com/.well-known/mta-sts.txt.

• Policy Changes: Every time you modify the policy file (e.g., changing modes), you must update the file on the public web server and change the policy ID in the DNS records.

4. Turning On MTA-STS and TLS Reporting

To activate MTA-STS and TLS reporting for your domain, you need to update your domain's DNS TXT records. These records signal to external servers that your domain requires authentication and encryption for SMTP connections and that you can receive TLS reports. These records must be added at your domain host, not in the Google Admin console.

• Create a Mailbox for Reports: Before turning on reporting, set up one or more email addresses in your domain to receive reports (e.g., tls-report@solarmora.com).

• Update DNS Records: Add two DNS TXT records at the following subdomains:

  • For TLS Reporting (_smtp._tls):

    • TXT record name (Host name): _smtp._tls.yourdomain.com (replace yourdomain.com with your actual domain).
    • TXT record value: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com (replace tlsrpt@yourdomain.com with the email address you created for reports).
      • To receive reports at multiple email addresses, separate them with commas: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com,mailto:mta-sts@yourdomain.com.

  • For MTA-STS (_mta-sts):

    • TXT record name (Host name): _mta-sts.yourdomain.com.
    • TXT record value: v=STSv1; id=20190425085700 (The id can be 1-32 alphanumeric characters).
      • The id signals support for MTA-STS and must be updated to a new, unique value every time your MTA-STS policy changes. Using the current date and time for the id value is recommended.

• Save your changes at your domain provider's management console.

• Verify the setup: After adding the DNS records, verify that MTA-STS and TLS reporting are correctly set up by checking your MTA-STS configuration on the Security Health page in the Google Admin console. Be aware that DNS record changes can take up to 24 hours to propagate, depending on the Time To Live (TTL) value.

Turning Off MTA-STS

There might be situations where you need to turn off MTA-STS, such as troubleshooting or changing mail providers. MTA-STS is turned off per domain.

Option 1: Change the Mode for Your MTA-STS Policy

This method turns off MTA-STS within 24 hours or less.

1. Update your policy file:

   • Locate the mta-sts.txt policy file you created (or download it from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt).
   • Change the mode value to none.
   • Change the max_age value to 86400 (about one day).
   • Remove all mx key-value pairs (all lines starting with mx).

   Example MTA-STS Policy in none mode:

   version: STSv1 mode: none max_age: 86400 2. Upload the updated policy file to the same web server and directory, overwriting the current file. 3. Change the ID in your MTA-STS DNS TXT record: * Sign in to your domain management console. * Find the MTA-STS TXT record (_mta-sts). * Change the id value in the TXT record (e.g., id=20200425085700) to a new, unique value. * Save your changes. DNS propagation may take up to 24 hours.

Option 2: Delete Your MTA-STS DNS TXT Record

This method turns off MTA-STS when the current and any previous policies expire, which can take from one day to one year depending on the max_age value. Some remote sites might have cached previous policy versions with longer expiration dates.

1. Verify the policy expiration time: Check the max_age value in your policy file (viewable on your web server at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt). The max_age is in seconds. If the expiration is too long, use Option 1.
2. Delete the MTA-STS record for your domain:
   • Sign in to your domain management console.
   • Locate the MTA-STS TXT record (_mta-sts).
   • Delete the TXT record.
   • Save your changes.

MTA-STS will be turned off for your domain when the policy with the longest expiration time expires.

References

• About MTA-STS and TLS reporting - Google Workspace Admin Help
• 3. Publish your MTA-STS policy - Google Workspace Admin Help
• 1. Check your MTA-STS configuration - Google Workspace Admin Help
• 2. Create an MTA-STS policy - Google Workspace Admin Help
• 4. Turn on MTA-STS and TLS reporting - Google Workspace Admin Help
• Turn off MTA-STS - Google Workspace Admin Help