Google Workspace DNS Records: MX, SPF, DKIM and DMARC Setup

Google Workspace needs four groups of DNS records on your domain before email works reliably: MX (so mail reaches Google), SPF (so Google's servers may send as you), DKIM (so messages are signed) and DMARC (so receivers know what to do with failures). This guide shows the standard shape of each record with example.com placeholders and tells you how to verify them.

Where to edit

Records go in the DNS zone that is authoritative for your domain, which is not always your registrar. If the registrar's nameservers are in use, edit there. If you moved to Cloudflare, a hosting provider or a DNS service, edit there. Confirm with the Nameserver Lookup or the DNS Checker before you start, and see how long DNS changes take.

1. MX records

Google has two published MX setups. The newer one is a single record:

example.com.   3600  IN  MX  1  smtp.google.com.

The older, long-standing set uses five records:

example.com.   3600  IN  MX   1  aspmx.l.google.com.
example.com.   3600  IN  MX   5  alt1.aspmx.l.google.com.
example.com.   3600  IN  MX   5  alt2.aspmx.l.google.com.
example.com.   3600  IN  MX  10  alt3.aspmx.l.google.com.
example.com.   3600  IN  MX  10  alt4.aspmx.l.google.com.

Google has said both work for existing and new domains. If you are unsure which to use, follow what the admin console and Google's current setup page tell you for your account. Do not combine the two sets, and do not leave any previous provider's MX records in place. Old records at a different priority can cause part of your mail to go to your previous host.

Verify with the MX Lookup. For the underlying rules, see MX records explained.

2. Domain verification

Before Google activates the domain it asks you to prove ownership, normally with a TXT record at the root:

example.com.   3600  IN  TXT  "google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

The value is unique to your account and comes from the admin console. Keep this record; removing it may cause re-verification prompts later.

3. SPF

SPF authorizes Google's servers to send for your domain. The standard form:

example.com.   3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

Key points:

• You may only have one SPF record per domain. If you also send through a newsletter tool or CRM, merge them into the same record:

example.com.   3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.newsletter.example ~all"

• include:_spf.google.com costs you several DNS lookups once expanded, because Google's record contains nested includes. SPF has a hard limit of ten; see fixing too many lookups. Count with the SPF Record Checker.
• ~all (softfail) is a common starting point. -all (fail) is stricter. Move to -all once reports show every sender is covered. If DMARC is enforced, the difference matters less because DMARC acts on the combined result.

4. DKIM

DKIM is not automatically on just because the account exists. You generate the key in the admin console (the Gmail authentication settings under Apps, then Google Workspace, then Gmail), and then publish it.

1. In the console, select your domain and generate a new record. Choose a 2048-bit key if offered. (Some DNS providers have trouble with long TXT values; if yours does, ask them about splitting, since you should not fall back to 1024 bits without reason.)
2. Google shows a TXT host name and a value. By default the selector is google:

google._domainkey.example.com.   3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...your-long-public-key..."

1. Publish the record, wait for it to resolve (dig +short TXT google._domainkey.example.com).
2. Return to the console and click Start authentication.

Common pitfalls: the panel appends the domain to the host so you end up with google._domainkey.example.com.example.com; the value gets broken by line breaks or smart quotes; or you click start before DNS has propagated. For more diagnosis see DKIM setup and troubleshooting.

5. DMARC

DMARC is entirely your record, since Google does not generate it for you:

_dmarc.example.com.   3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Start at p=none to collect reports, then tighten using the DMARC rollout guide. Build a valid record with the SPF & DMARC Generator.

6. Optional records

• Subdomain mail streams. If a marketing tool sends from news.example.com, give that subdomain its own SPF and DKIM rather than loading everything into the root record.
• Reverse DNS is not something you configure: Google controls PTR for its own sending IPs.
• MTA-STS and TLS-RPT. Optional hardening for inbound mail, covered in the MTA-STS guide. Note that the policy file must list your Google MX hosts exactly as published.
• BIMI. Requires DMARC enforcement; see BIMI explained.

The complete record set at a glance

Verification checklist

1. MX: run the MX Lookup; only Google hosts should appear.
2. SPF: run the SPF Record Checker; one record, under ten lookups.
3. DKIM and DMARC: run the Email DNS Checker and confirm both records are found.
4. End to end: send a message to the Email Deliverability Test and read the authentication results: you want spf=pass, dkim=pass (with header.d=example.com) and dmarc=pass.
5. Third-party senders: each service you use must have its own DKIM and, ideally, an aligned return-path.

Troubleshooting quick answers

• Mail not arriving after the MX switch: old MX records still present, a typo in the host name, DNS edited in the wrong zone, or TTL has not expired. See the DNS propagation guide.
• Messages show dkim=none: DKIM was published but authentication was never started in the console.
• spf=fail for mail sent via Gmail: usually a duplicated or malformed SPF record, so check for two TXT records beginning v=spf1.
• Mail goes to spam despite passing: reputation or content; follow the spam diagnostic checklist.

Next steps

• Run the Email DNS Checker on your domain now.
• Confirm routing with the MX Lookup.
• Tighten policy with the DMARC rollout guide.
• Sending from other platforms too? Read the transactional email DNS checklist.

FAQ

Which MX records should I use for Google Workspace?

Use what Google's admin console and setup documentation currently show for your account. Either the single smtp.google.com record or the five-record aspmx.l.google.com set is accepted, but do not mix them or leave old provider records in place.

Do I need to turn on DKIM manually?

Yes. Generate the key in the admin console, publish the TXT record in DNS, then click Start authentication. Until you do, Google does not sign with your domain.

Can I have two SPF records if I use Google and a newsletter tool?

No. Multiple SPF records cause a permanent error. Combine all include: terms into one record and watch the ten-lookup limit.

Does Google set up DMARC for me?

No. You publish the _dmarc TXT record yourself. Start with p=none and reports, then move to enforcement.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.