How do you require TLS for email in Google Workspace with Secure transport compliance?

Gmail encrypts most mail in transit already, but only when the other server cooperates. If a partner's server can't or won't use TLS, Gmail quietly sends the message in plain text. Google Workspace's Secure transport (TLS) compliance setting changes that for the domains you choose: mail to or from them goes over TLS or not at all. This guide covers the steps, every option, what happens when TLS fails, and how the setting fits with MTA-STS.

For the protocol background, read STARTTLS: email encryption in transit explained. For S/MIME, confidential mode and client-side encryption, see Google Workspace email encryption. Menu paths were checked against Google's Admin Help at the time of writing (November 2026).

What is Secure transport (TLS) compliance in Google Workspace?

Secure transport (TLS) compliance is a Gmail admin setting that makes TLS mandatory for mail exchanged with addresses or domains in an address list. TLS (Transport Layer Security) encrypts the SMTP connection between two mail servers so the message can't be read or altered on the way.

Google explains the default this way: "By default, Gmail always tries to send messages over a secure TLS connection," but "if the receiving server doesn't use TLS, Gmail still sends messages but the connection isn't secure" (Google Workspace Admin Help). That fallback is called opportunistic TLS. The compliance setting removes the fallback for the partners you list, and it "includes options to require a CA-signed certificate, verify the hostname associated with the certificate, and test the TLS connection."

Typical reasons to use it: a contract or regulator requires encrypted transmission with a named partner, you exchange payroll or patient data with a specific firm, or a partner asks you to enforce TLS on their domain.

What happens to email that can't use TLS?

Mail that can't use TLS is stopped, not delivered in plain text. Google describes the outcome for each direction:

Two details matter in practice. First, there's no retry queue: a single failed attempt becomes a bounce. Second, inbound rejections are invisible to you, so a partner whose server breaks TLS will only find out from their own bounces.

How do you add a TLS compliance setting, step by step?

You add the setting under Gmail's Compliance page and attach an address list of the partners that need TLS. You need the Gmail Settings administrator privilege. These steps follow Google's TLS help page.

1. Check which TLS versions your own standards accept. Google says Google Workspace supports TLS 1.0, 1.1, 1.2 and 1.3, and warns that "not all standards support the TLS versions that Google Workspace supports."
2. In the Google Admin console, go to Menu > Apps > Google Workspace > Gmail > Compliance.
3. On the left, select an organizational unit. Choose the top level unless only one department deals with the partner.
4. Point to Secure transport (TLS) compliance and click Configure (or Add Another for more settings). Enter a name, such as TLS required - payroll provider.
5. Under Email messages to affect, select Inbound, Outbound or both.
6. Under Use TLS for secure transport when corresponding with these domains / email addresses, click Use existing list, or Create or edit list to make one. Add the partner's domain, for example payroll.example, and save the list.
7. Under Options, keep Require CA signed certificate and Validate certificate hostname ticked. Google labels both "Recommended."
8. Click Test TLS connection to check the partner's receiving server.
9. Click Save. The setting appears in the Secure Transport (TLS) compliance settings table.

Google says changes "can take up to 24 hours but typically happen more quickly." Tell the partner before you switch it on, and send a test message in each direction afterwards.

What do the certificate options mean?

Require CA signed certificate requires the other SMTP server "to present a certificate signed by a trusted Certificate Authority." That rules out self-signed certificates. Validate certificate hostname "verifies that the receiving hostname matches the certificate presented by the SMTP server." Without these, an attacker who intercepts the connection could present any certificate and still count as TLS. Encryption without verification protects against eavesdropping, not against impersonation.

How does Gmail decide which messages the setting covers?

Gmail matches the From: sender for inbound mail and each recipient for outbound mail. Google says "for inbound messages, the From: sender must exactly match an address or domain in the setting," and that you "must use an address list to enforce TLS for inbound and outbound messages."

Outbound matching works per recipient. Google's own example: if the list includes admin@solarmora.com but not help@solarmora.com, "only the copy destined for admin@solarmora.com requires TLS" (address lists help). Gmail also ignores the sender authentication requirement when it checks recipients, and treats subdomains as a match for the parent domain.

Matching inbound mail on the From address has a limit you should know. If the partner sends through a marketing or ticketing platform with your partner's address in From, that platform's server must also offer valid TLS, or the mail is rejected.

What is the "Outbound - messages requiring Secure Transport via another setting" option?

That option applies the TLS compliance setting to outbound messages that another Gmail setting already sends over a secure connection. Google gives two examples: email routing that sends outbound mail "through a secure connection," and an alternate secure route.

An alternate secure route is a fallback host for mail that must be encrypted. Google says it's for when "you require that email always be sent over a secure TLS connection, even when you're not sure receiving servers use TLS"; outgoing mail is then "sent through a host or third-party service that encrypts messages before they're delivered to receiving servers" (alternate secure route help). You set it up in two steps:

1. Add the encryption host under Apps > Google Workspace > Gmail > Hosts.
2. Go to Gmail > Routing, select the top-level organization, edit Alternate secure route, tick Use an alternate route when secure transport is required, and choose the host.

Most organizations don't need this. It suits firms whose rules forbid any unencrypted hop and who already use a secure-delivery service. For how Gmail routes in general, see Gmail routing rules in Google Workspace.

How is TLS compliance different from MTA-STS?

TLS compliance enforces TLS for partners you list, from your side. MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) asks every sending server that supports it to use authenticated TLS when delivering to your domain. Google says that with MTA-STS on, you ask external servers to deliver only over connections that are "authenticated with a valid public certificate" and "encrypted with TLS 1.2 or higher" (About MTA-STS and TLS reporting).

Why not just require TLS from everyone? Because the SMTP standard forbids it for public mail servers. RFC 3207 says "a publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally." MTA-STS is the standards-based way to raise the bar for everyone. Our MTA-STS and TLS-RPT guide covers the DNS records and rollout, and the MTA-STS Checker validates your policy.

How do you test and monitor TLS enforcement?

Test before you enforce, then watch for failures. Use this checklist:

1. Run Test TLS connection in the setting. Google warns that if the test gives a certificate validation error, "messages sent from your organization will bounce, even though you could save the new mail route."
2. Check the lock icon in Gmail. Google says standard TLS shows a gray lock, and "if you get a message with a red open lock icon, it means the message is unencrypted" (Gmail Help).
3. Read the headers. A TLS hop usually shows the cipher in a Received line, for example (illustrative):

Received: from mail.payroll.example (mail.payroll.example. [203.0.113.25])
        by mx.google.com with ESMTPS id ...
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);

ESMTPS means the session used TLS. Paste headers into the Email Header Analyzer to see each hop. 4. Turn on the TLS failure alert. Google's system-defined rule TLS failure fires when "messages requiring Transport Layer Security (TLS) can't be delivered," and it is Inactive by default (system-defined rules). Activate it under Menu > Rules and add recipients. Our alert center guide walks through it. 5. Audit before you enforce. A content compliance rule can match Secure transport (TLS) > Connection is not TLS encrypted for received mail (content filtering help). Point it at the partner's domain with a harmless action such as adding a header, and you'll see whether any of their mail arrives without TLS today.

Why is TLS compliance bouncing email?

TLS compliance bounces mail when the partner's server can't complete a verified TLS session. Google's troubleshooting advice covers the common causes:

• Hostname mismatch. "If your mail server has more than one host name, make sure you're using the host name that's on the server's certificate."
• Expired or untrusted certificate. Install a new certificate from a trusted certificate authority with the correct hostname.
• A relay in the path. If a third-party relay service is involved, contact that provider.

Google lists unticking Require CA signed certificate or Validate certificate hostname as a workaround, but adds: "We recommend keeping these options turned on whenever possible so the connection can be verified." Fix the certificate instead, and use the partner's bounce text with our SMTP error code lookup if the message isn't clear.

Does a filtering gateway change any of this?

Yes, for inbound mail. If your MX records point to a filtering gateway, external senders connect to the gateway, not to Gmail, so inbound TLS with the partner happens at the gateway. The hop from the gateway to Gmail is a separate connection. Gmail's Inbound gateway setting has its own Require TLS for connections option for that hop; our inbound gateway guide explains it. Outbound TLS compliance is unaffected unless you route outgoing mail through a smart host.

Next steps

• List the partners whose contracts or data require encrypted email, and confirm their servers pass Test TLS connection.
• Add one Secure transport (TLS) compliance setting per group of partners, with both certificate options on.
• Activate the TLS failure alert so outbound failures don't go unnoticed.
• Publish MTA-STS and TLS-RPT for your own domain; the free Email Health Check shows your current transport security, and iBlockSpam's Google Workspace setup covers TLS on the gateway hop.