2. Create an MTA-STS policy

Set up MTA-STS for your domains by creating and publishing a policy for each domain. The policy defines the mail servers in the domain that use MTA-STS.

Each domain must have a separate policy file. The policies can be the same but they must be hosted separately for each domain using MTA-STS.

Server requirements for MTA-STS

Verify the following for your mail servers that get incoming mail:

• They require mail 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.

Learn more about TLS certificates at Use Google Workspace certificates for secure transport (TLS).

MTA-STS policy modes

You can set up an MTA-STS policy in testing mode or enforce mode.

Testing mode

Testing mode requests that external mail servers send you daily reports. The reports have information about issues detected when connecting to your domain. Reports include detected MTA-STS policies, traffic statistics, unsuccessful connections, and unsent message details.

In testing mode, your domain only requests reports. This mode does not enforce any connection security required by MTA-STS. We recommend starting with testing mode for 2 weeks. 2 weeks of report data is enough to learn about and fix any problems with your domain.

Use the information in the daily reports to resolve encryption or other security issues with your server or domain. Then, change the policy to enforce mode.

Enforce mode

When the policy is in enforce mode, your domain requests external servers to verify the SMTP connection is both encrypted and authenticated.

If the connection is not both encrypted and authenticated:

• Servers that support MTA-STS will not send mail to your domain.
• Servers that don't support MTA-STS continue to send messages to your domain over SMTP connections as they normally do. These SMTP connections might not be encrypted.

In enforce mode, you continue to receive the daily reports from external servers.

Create a policy file

The policy file is a plain text file that has key and value pairs. Each pair must be on its own line in the text file, as shown in the example below. The policy text file size can be up to 64 KB.

Policy filename: The filename for the text file must be mta-sts.txt

Updating policy files: Update the policy file every time you add or change mail servers, or change the domain.

Policy file format: The version field must be in the first line of the policy. The other fields can be in any order. Here's an example policy file:

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

Policy file contents: The policy must include all of these key and value pairs. To get a policy that is customized for your domain, follow the steps in Check MTA-STS status and get suggested configurations.

Key	Value
version	Protocol version. Must be STSv1
mode	Policy mode: testing: External servers send you reports about encryption and other issues detected when connecting to your domain. MTA-STS encryption and authentication requirements are not enforced enforce: If the SMTP connection doesn't have both authentication and encryption, mail servers set up for MTA-STS won't send messages to your domain. You also get reports from external servers about connection issues, as in testing mode. none: Tells external servers that your domain no longer supports MTA-STS. Use this value if you stop using MTA-STS. Learn about Removing MTA-STS (RFC 8461).
mx	MX record for the domain. The policy must have an mx entry for each MX record added to the domain. Each mx entry must be on its own line in the policy file, as shown in the example. The mail server name must be in standard Subject Alternative Name (SAN) format. The mx value must be in one of the formats shown in these examples: Specify a single server in standard MX form: alt1.aspmx.solarmora.com To specify servers that match a naming pattern, use a wildcard. The wildcard character replaces one leftmost label only, for example: *.solarmora.com Learn more about MX records and MX record values.
max_age	Maximum time in seconds the policy is valid. The max_age is reset for an external server every time the server checks the policy. So, external servers can have different expiration dates for the same policy. The value must be between 86400 (1 day) and 31557600 (about 1 year). For testing mode, we recommend between 604800 and 1209600 (1–2 weeks).

Next Steps

Publish your MTA-STS policy