jeffers.me

Bringing a ten-year-old Google Workspace domain up to 2026 email standards

Five MX records, a DMARC policy that only covered 5% of mail, and no transport security. Here is what I changed, in what order, and why each record matters.

Published
Length
3 min, 2U

I set up Google Workspace on my personal domain a long time ago, followed the instructions of the day, and then didn’t look at the DNS again. Mail kept arriving, so nothing ever forced the issue. A review this week showed how far the “it works” setup had drifted from what a well-run domain looks like now.

Here is what I found and what I changed.

The starting point

Record What it said Problem
MX Five records: aspmx.l.google.com, two alt hosts, two googlemail.com hosts Still works, but it’s the old pattern
SPF include:_spf.google.com ~all Fine
DKIM 2048-bit Google key Fine
DMARC p=quarantine; pct=5 The policy applied to one message in twenty
MTA-STS None Sending servers could fall back to plaintext
TLS-RPT None No visibility into delivery failures over TLS

One MX record

Google has recommended a single MX record, smtp.google.com at priority 1, for new setups since 2023. The five-record set isn’t broken, and Google still accepts mail on those hosts, but there’s no reason to keep it. One record is easier to read, easier to audit, and it’s the value MTA-STS will pin later.

The safe order is to add the new record first, then remove the old ones, so there is never a moment without a valid MX.

DMARC at 100%

My DMARC record already said quarantine, which looks strict until you notice pct=5. That told receivers to apply the policy to 5% of failing mail and let the rest through. I had set it during a cautious rollout years ago and never finished the job.

Before changing it, I checked the aggregate reports. SPF and DKIM were both aligned for everything legitimately sending as the domain, so moving to pct=100 carried little risk. The next step, in a couple of weeks of clean reports, is p=reject.

If you send mail from a domain and haven’t looked at DMARC reports, Cloudflare’s free DMARC Management will parse them into something readable. That’s what told me the change was safe.

MTA-STS and TLS-RPT

SMTP between mail servers uses opportunistic TLS. If a sending server can’t negotiate encryption, or someone in the middle strips the offer, it falls back to plaintext and nobody notices. MTA-STS (RFC 8461) fixes that by publishing a policy that says “my mail servers support TLS, and these are their names; don’t deliver any other way.”

It takes two pieces:

  1. A small text file at https://mta-sts.<your-domain>/.well-known/mta-sts.txt.
  2. A TXT record at _mta-sts.<your-domain> with an ID that changes whenever the policy does.
version: STSv1
mode: testing
mx: smtp.google.com
max_age: 86400

I serve the file from a tiny Cloudflare Worker on its own hostname. It’s about fifteen lines, costs nothing at this volume, and lives in Git with the rest of my infrastructure.

I started in testing mode, which tells senders to report problems without refusing delivery. That’s where TLS-RPT (RFC 8460) comes in: one more TXT record, _smtp._tls, asks senders to email a daily report of TLS successes and failures. Once those reports come back clean, I’ll switch the policy to enforce.

What I left alone

Two verification records from old services are still in the zone. They’re harmless, and I’d rather confirm nothing depends on them than find out by breaking something.

The checklist

If your domain has been on autopilot, this is the order I’d go in:

  • Read your DMARC reports before touching anything.
  • Replace legacy MX records with smtp.google.com, adding before removing.
  • Raise DMARC to 100%, then to reject once reports stay clean.
  • Add TLS-RPT so you can see transport problems.
  • Publish MTA-STS in testing mode, then enforce.

None of it took more than an hour. The hard part was noticing it needed doing.