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

URL: https://iblockspam.com/blog/google-workspace-tls-compliance-secure-transport
Last updated: 2026-11-03
Published: 2026-11-03
Topic: Setup guides
Author: iBlockSpam Team

> Require TLS for chosen partners in Google Workspace with Secure transport (TLS) compliance: steps, certificate options, bounces, MTA-STS and how to test.

## Short answer

Gmail always tries TLS but falls back to unencrypted delivery. To require it, go to Apps > Google Workspace > Gmail > Compliance > Secure transport (TLS) compliance, choose inbound, outbound or both, select an address list of partner domains, and keep Require CA signed certificate and Validate certificate hostname on. Non-TLS mail to or from those partners then bounces or is rejected.

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](https://iblockspam.com/blog/starttls-email-encryption-in-transit). For S/MIME, confidential mode and client-side encryption, see [Google Workspace email encryption](https://iblockspam.com/blog/google-workspace-email-encryption-s-mime-confidential-mode). 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](https://knowledge.workspace.google.com/admin/gmail/advanced/send-email-over-a-secure-tls-connection)). 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:

| Direction | What Gmail does | Who is told |
|---|---|---|
| Outbound (your user to a listed partner) | "Messages aren't delivered, and will bounce." Gmail "makes only one attempt to send messages over a non-TLS connection." | Your user gets a non-delivery report |
| Inbound (a listed partner to your user) | "Incoming messages from non-TLS connections are rejected." | "You aren't notified. The sender gets a non-delivery report." |
| Mail with partners not on the list | Normal opportunistic TLS | Nobody; it falls back silently if needed |

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](https://knowledge.workspace.google.com/admin/gmail/advanced/send-email-over-a-secure-tls-connection).

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](https://knowledge.workspace.google.com/admin/gmail/advanced/use-address-lists-to-apply-settings-to-specific-people-or-domains)). 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](https://knowledge.workspace.google.com/admin/gmail/advanced/send-email-over-an-alternate-secure-route-tls)). 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](https://iblockspam.com/blog/gmail-routing-rules-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](https://www.rfc-editor.org/rfc/rfc8461.html)) 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](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting)).

| Control | Protects | Who enforces | Scope |
|---|---|---|---|
| Opportunistic TLS (default) | Eavesdropping, when both sides support TLS | Both servers, voluntarily | All mail |
| Secure transport (TLS) compliance | Plain-text delivery to or from named partners | Gmail, for your domain | Address list only |
| Route or host "Require secure transport (TLS)" | Plain-text onward delivery to a server you route to | Gmail | That route |
| MTA-STS policy (enforce mode) | Downgrade and fake-server attacks on mail to you | Senders that support MTA-STS | All inbound mail from supporting senders |
| TLS reporting (TLS-RPT) | Nothing directly; reports failures | Senders that send reports | All inbound mail |

Why not just require TLS from everyone? Because the SMTP standard forbids it for public mail servers. [RFC 3207](https://www.rfc-editor.org/rfc/rfc3207.html) 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](https://iblockspam.com/blog/mta-sts-tls-rpt-explained) covers the DNS records and rollout, and the [MTA-STS Checker](https://iblockspam.com/tools/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](https://support.google.com/mail/answer/6330403)).
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](https://iblockspam.com/tools/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](https://knowledge.workspace.google.com/admin/reports/view-and-edit-system-defined-rules)). Activate it under **Menu** > **Rules** and add recipients. Our [alert center guide](https://iblockspam.com/blog/google-workspace-alert-center-email) 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](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-rules-for-advanced-email-content-filtering)). 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](https://iblockspam.com/tools/smtp-error-codes) 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](https://iblockspam.com/blog/google-workspace-inbound-gateway-setup) 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](https://iblockspam.com/tools/email-health-check) shows your current transport security, and iBlockSpam's [Google Workspace setup](https://iblockspam.com/platforms/google-workspace) covers TLS on the gateway hop.

## Frequently asked questions

### Does Google Workspace encrypt email with TLS by default?

Gmail always tries TLS first, but it doesn't insist on it. Google says that if the receiving server doesn't use TLS, Gmail still sends the message, but the connection isn't secure. To make TLS mandatory for specific partners, add a Secure transport (TLS) compliance setting with an address list of their domains.

### What happens to an email when TLS compliance fails in Gmail?

For outbound mail, Gmail makes one attempt over the non-TLS connection, doesn't deliver the message, and returns a non-delivery report to your user. For inbound mail, Gmail rejects the non-TLS connection; you aren't notified, and the sending side receives the non-delivery report. Turn on the TLS failure alert so admins see outbound failures.

### Can I require TLS for all inbound mail to Google Workspace?

Not with the TLS compliance setting, which needs an address list of specific senders or recipients. RFC 3207 says a publicly referenced SMTP server must not require STARTTLS to deliver mail locally. To ask every sender to use authenticated TLS for your domain, publish an MTA-STS policy in enforce mode and turn on TLS reporting.

### Which TLS versions does Google Workspace support?

Google's Admin Help says Google Workspace supports TLS 1.0, 1.1, 1.2 and 1.3 at the time of writing (November 2026). Google advises checking which versions your own compliance standards allow before you configure TLS settings, because not every standard accepts all four. MTA-STS separately asks senders for TLS 1.2 or higher.

### Should I tick Require CA signed certificate and Validate certificate hostname?

Yes, Google marks both as Recommended. The first requires the other server to present a certificate signed by a trusted certificate authority; the second checks that the hostname matches that certificate. Together they stop a man-in-the-middle with a self-signed certificate. Test the connection first, because a validation failure makes outbound mail bounce.

## Sources

- [Google Workspace Admin Help: Send email over a secure TLS connection](https://knowledge.workspace.google.com/admin/gmail/advanced/send-email-over-a-secure-tls-connection)
- [Google Workspace Admin Help: Send email over an alternate secure route (TLS)](https://knowledge.workspace.google.com/admin/gmail/advanced/send-email-over-an-alternate-secure-route-tls)
- [Google Workspace Admin Help: Use address lists to apply settings to specific people or domains](https://knowledge.workspace.google.com/admin/gmail/advanced/use-address-lists-to-apply-settings-to-specific-people-or-domains)
- [Google Workspace Admin Help: About MTA-STS and TLS reporting](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting)
- [Google Workspace Admin Help: View and edit system-defined rules](https://knowledge.workspace.google.com/admin/reports/view-and-edit-system-defined-rules)
- [Gmail Help: Learn how Gmail encrypts your emails](https://support.google.com/mail/answer/6330403)
- [RFC 3207: SMTP Service Extension for Secure SMTP over TLS](https://www.rfc-editor.org/rfc/rfc3207.html)
- [Google Workspace Admin Help: Set up rules for advanced email content filtering](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-rules-for-advanced-email-content-filtering)

## Free tools for this guide

- [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker): Fetch and validate your MTA-STS policy, match it to your MX hosts and check TLS-RPT.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [Email Deliverability Test](https://iblockspam.com/tools/deliverability-test): Send one email and see its SPF, DKIM and DMARC results, reverse DNS, blocklists, TLS and spam verdict.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.

---

Source: iBlockSpam, https://iblockspam.com/blog/google-workspace-tls-compliance-secure-transport (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt