To pass email authentication on Google Workspace you need three DNS records in a specific order: an SPF TXT record that authorizes Google's servers, a DKIM key generated inside the Admin Console and published as a TXT record, and a DMARC policy that tells receivers what to do when a message fails. Do them in that sequence, and validate each one live before you touch the next. Get the order wrong and you can lock yourself into a broken DMARC policy before DKIM is even signing.
This guide gives you the exact values to publish, the Admin Console clicks in order, and the one DKIM setting people miss that leaves them signing with a weak key.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Step 1: Publish the SPF record
SPF (RFC 7208) lets a receiver confirm that the server sending your mail is one you approved. For Google Workspace, Google publishes a single include mechanism that expands to all of their sending IP ranges, so your record stays short and never needs manual IP updates.
Add this TXT record at the root of your domain:
v=spf1 include:_spf.google.com ~all
A few rules that matter:
- You may only have one SPF record per domain. If you already have a
v=spf1record for another service, you merge them into a single record rather than publishing a second one. Two SPF records is a permerror and both are ignored. - The
~allat the end is a soft fail. It tells receivers that anything not listed is suspicious but should still be accepted and marked. Start here. Move to-all(hard fail) only once you are certain every legitimate sender is included, otherwise you will bounce your own mail. - Never use
+all. That authorizes the entire internet to send as you and is worse than having no record at all. We cover why in the +all danger guide.
If you send through other services too (a CRM, a helpdesk, a marketing platform), each one adds its own include. Watch the count: SPF allows a maximum of 10 DNS lookups before it errors out. If you are near the limit, read how to fix too many SPF lookups before you add more.
Validate before moving on
DNS propagation is usually minutes but can take up to an hour. Run your domain through the scanner at the top of this page and confirm SPF shows a pass with Google's include resolving cleanly. Do not start on DKIM until SPF is green.
Step 2: Generate and publish DKIM in the Admin Console
DKIM (RFC 6376) adds a cryptographic signature to every outgoing message. The receiver fetches your public key from DNS and verifies the signature, which proves the message body and key headers were not altered in transit and that the mail genuinely came from your domain. Unlike SPF, DKIM survives most forwarding, which is why it carries more weight for DMARC alignment.
Google does not sign your mail until you turn DKIM on. A brand new Workspace domain sends unsigned mail by default, so this step is not optional.
The exact flow
- Sign in to the Google Admin Console at admin.google.com with a super admin account.
- Go to Apps > Google Workspace > Gmail > Authenticate email.
- Select your domain from the dropdown at the top.
- Before you generate anything, set the DKIM key bit length to 2048. This is the gotcha. Some Workspace tenants still default the selector to a 1024-bit key, which is weaker and increasingly distrusted. Change it to 2048 first, then generate.
- Click Generate new record. Google shows you a DNS host/selector (
google) and a long TXT value starting withv=DKIM1; k=rsa; p=.... - Copy the host and the value into a new TXT record at your DNS provider. The host is typically
google._domainkey. Publish it.
The selector Google uses is google, so your DKIM record lives at google._domainkey.yourdomain.com. Because the 2048-bit public key is long, some DNS providers split it into multiple quoted strings inside the same record. That is normal and resolvers reassemble it.
Turn on signing
After the DNS record is published and has propagated, return to the same Authenticate email page and click Start authentication. Until you click this, the key exists in DNS but Google is not signing anything. If you click it too early, before DNS has propagated, Google reports that it cannot find the record. Wait a few minutes and try again.
Validate before moving on
Run the scanner again. Confirm DKIM shows a valid 2048-bit key on the google selector and that the status is signing. If you switched from a 1024-bit key, understand that the old key can linger; a clean check confirms the 2048-bit key is the one in use. This is also the moment to plan a key rotation schedule for later.
Step 3: Add the DMARC policy last
DMARC (RFC 7489) ties SPF and DKIM together. It tells receivers what to do with mail that fails authentication and where to send reports. You add it last for a reason: if you publish an enforcing DMARC policy before SPF and DKIM both pass and align, you can send your own legitimate mail straight to quarantine or reject.
Start in monitor-only mode. Publish this TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
p=nonemeans take no enforcement action, just watch. Nothing gets blocked.ruais the address that receives daily aggregate reports. Use a mailbox you control. These reports show you every source sending as your domain, which is how you catch a forgotten service before you turn on enforcement.
Let this run for one to two weeks. Read the aggregate reports (our guide on reading DMARC aggregate reports walks through the XML) and confirm that all of your legitimate mail is passing SPF or DKIM with alignment. Only then tighten the policy.
Moving to enforcement
Once the reports are clean, step the policy up rather than jumping straight to reject:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
Then, after quarantine looks healthy, move to p=reject. The full progression, including how to use the pct tag to ramp gradually, is in how to move DMARC from none to reject. Reaching p=reject is what actually stops spoofing of your domain, because p=none blocks nothing.
Why the order and the enforcement matter
Google and Yahoo now require SPF, DKIM, and a DMARC record (at minimum p=none) for anyone sending to their users at volume. Meeting those sender requirements is the baseline for reaching the inbox, and missing them is a common reason mail lands in spam. Doing the three records in order, and validating each live, means you never debug three unknowns at once. If DMARC fails, you already know SPF and DKIM were green, so alignment is the only thing left to check.
Frequently asked questions
Do I still need SPF if DKIM is set up?
Yes. DMARC passes if either SPF or DKIM passes with alignment, but you want both. SPF breaks on forwarding while DKIM usually survives it, so having both gives you two independent chances to authenticate. Publish all three records.
Why is my Google Workspace DKIM still showing 1024-bit?
Because the tenant generated the key before you set the bit length to 2048, or the older selector is still published in DNS. Regenerate the key with 2048 selected in the Admin Console, publish the new TXT value, click Start authentication, and confirm with a live check that the 2048-bit key is the one signing.
How long until my records work after publishing?
DNS changes usually resolve within minutes but can take up to an hour depending on your provider and TTL. For DKIM specifically, wait until the record is visible in DNS before clicking Start authentication, or Google will report it as not found.
Can I skip DMARC and just do SPF and DKIM?
No, not if you send to Gmail or Yahoo at any real volume, since they require at least a p=none DMARC record. A published p=none also gives you the aggregate reports you need to see who is sending as your domain before you enforce.