The Gmail Requirement Your DNS Records Can't Show You: TLS on the SMTP Connection

Every deliverability checklist leads with SPF, DKIM and DMARC, because they're easy to verify - paste a domain into any checker and get a pass or fail in seconds. Google added a fourth requirement to its bulk sender guidelines back in December 2023 that gets almost no attention, precisely because it doesn't work that way: TLS on the SMTP connection.

This isn't the TLS you're thinking of

The confusion starts here almost every time: TLS in this context has nothing to do with whether links in your email body use https://. It's about the encryption on the SMTP session between the server that sends your mail and Gmail's mail servers that receive it - a connection your recipient never sees and your email client never shows you.

Google requires that connection to use TLS. If it doesn't, Gmail can return an SMTP error (temporary or permanent, both coded distinctly from an authentication failure) rather than accept the message.

Why it's invisible to every DNS-based check

SPF, DKIM and DMARC live in TXT records you publish yourself, so any tool - ours included - can query DNS and tell you instantly whether they're set up correctly. TLS on the SMTP connection isn't a DNS record. It's a property of the actual server session at send time, configured on whatever sends your mail: your own mail server, or more commonly, your ESP's or cold email platform's sending infrastructure.

A domain can pass every DNS-based deliverability check available and still fail Google's TLS requirement, because the two are checking completely different layers - one is what you published, the other is what your sending server actually does when it connects.

This is also why it's usually not something you personally configure. If you send through a mainstream ESP or cold outreach platform, TLS on outbound connections is almost always already on by default - but "almost always" is exactly the kind of assumption worth confirming once, especially on a self-hosted mail server or an older SMTP relay that hasn't been touched in years.

How to actually verify it

The most direct way: send a real test message to an address you control, then look at the Received header that the receiving server adds - it typically logs the TLS version and cipher the connection used (something like "version=TLS1_3"). No entry there, or a bare unencrypted line, means the connection wasn't encrypted.

Paste those headers into our Email Header Analyzer to see the delivery path

If you send through a third-party platform, the more reliable path is simply asking their support team to confirm TLS is enforced on their outbound MTA - a two-line question that resolves the entire uncertainty, and one most senders never think to ask because the requirement doesn't show up in the DNS-first checklists everyone uses.