SPF record for Google Workspace

The record to publish, what it costs against your 10-lookup budget, and the DKIM part most guides leave out.

The record

If Google Workspace (also called Gmail, G Suite, Google Apps) is the only thing that sends mail as your domain, this is your complete SPF record:

Type

TXT

Name

@ (the domain itself)

Value

v=spf1 include:_spf.google.com ~all

TTL

3600 (or your panel's default)

If you already have an SPF record, add the include term to it — do not publish a second record. Two SPF records on one domain is a permanent error, and receivers respond by ignoring SPF for your domain completely.

What it costs you

RFC 7208 gives a receiver a budget of 10 DNS lookups to evaluate your record. Every include:, a, mx and exists: term costs one — including the terms inside the records you include. That last part is what catches people.

Google flattened this record years ago — it is pure ip4/ip6 with no nested includes, so it costs exactly one lookup. It is one of the cheapest providers you can have in your record.

DKIM, which matters more than SPF

SPF authorises a sending server. The moment a message is forwarded, the forwarding server is not on your list, and SPF fails — legitimately. DKIM signs the message itself, so it survives forwarding. For anything transactional (invoices, receipts, password resets) DKIM is the record that keeps working.

Google Workspace publishes DKIM as CNAME-free TXT published by Google, normally under the selector google. Two things go wrong most often:

• Only some of the records get published. Providers that use several CNAMEs (Amazon SES uses three, Microsoft 365 uses two) look configured in their own UI while signing is still broken.
• The CNAME points somewhere with nothing behind it. The setup was started, the provider side was never finished, and mail is signed with a key nobody can fetch. That is worse than no DKIM at all.

The checker follows CNAME chains and tells you which of those two you are looking at.

MX, for reference

Google Workspace receiving mail uses these MX hosts:

MX has nothing to do with SPF or DKIM — it controls incoming mail. It is listed here because a domain with no MX cannot receive the DMARC reports you asked for, or the bounces that tell you something is wrong.

Then add DMARC

SPF and DKIM on their own tell receivers nothing about what to do when a check fails. DMARC does, and it is also the only way you ever find out that someone is sending forged invoices as your domain. Start in monitor mode:

Publish that at _dmarc.yourdomain.com, read the reports for two to four weeks, then move to p=quarantine and eventually p=reject. The staged rollout is here.

Lookup costs on this page were measured against live DNS on 2026-08-21 with the checker above, not copied from documentation. Providers do change their records — re-check yours rather than trusting a number in a blog post, including this one.

FAQ

Related

Other providers

All 24 providers and 12 guides →