On this page

Fixing DANE in AWS Route 53 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. 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 Route 53 hosted zone. Google's own documentation doesn't describe a customer-facing DANE/TLSA setup for Workspace.

This holds regardless of DNS provider — Route 53 fully supports TLSA records (added October 2024), 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. Set this up via Menu → Apps → Google Workspace → Gmail → Advanced → MTA-STS in the Google Admin console — it requires only a TXT record and an HTTPS-hosted policy file, both straightforward in Route 53.

Common pitfalls

  • Spending time configuring a TLSA record for smtp.google.com/aspmx.l.google.com in Route 53 — Route 53 supports the record type, but you don't control that zone, so it won't apply.