On this page

Fixing DANE in Cloudflare for Google Workspace

Why you can't fix this

DANE works by publishing a TLSA record on your mail server's own hostname, signed via DNSSEC, so senders can verify your server's certificate through DNS instead of a public CA. See Setting Up DANE for Email for the general mechanism.

For a Google Workspace domain, your MX records point to Google's own infrastructure (smtp.google.com, or the legacy aspmx.l.google.com set for older domains) — hostnames that live in google.com's zone, not yours. A TLSA record for inbound mail security has to sit on that same hostname, so it isn't something you can publish from your own Cloudflare zone. Google's own documentation doesn't describe a customer-facing DANE/TLSA setup for Workspace — it isn't a Cloudflare limitation, it's that the record has nowhere in your control to live.

This holds true regardless of which DNS provider manages your zone — Cloudflare fully supports TLSA records, but that's not the blocker here.

What to do instead

Google's documented mechanism for enforcing inbound transport security is MTA-STS, not DANE. It works differently: you publish an MTA-STS policy (a _mta-sts TXT record plus an HTTPS-hosted policy file listing your MX hosts) telling senders to require valid-certificate TLS when delivering to you. Set this up via Menu → Apps → Google Workspace → Gmail → Advanced → MTA-STS in the Google Admin console.

Common pitfalls

  • Searching Cloudflare for a way to add a TLSA record for smtp.google.com or aspmx.l.google.com — you can't publish records in a zone you don't control, no matter how the DNS record type is supported elsewhere.
  • Treating this as a Cloudflare gap — Cloudflare supports TLSA records fine; the limitation is entirely on Google Workspace's side.