Google Workspace email authentication: SPF, DKIM and DMARC
Google Workspace needs three DNS records to authenticate your mail: an SPF include, a DKIM key you generate in the Admin console, and a DMARC policy you publish yourself. This guide covers the whole chain, including what changes when other services also send as your domain.
Record values checked against Google Workspace’s own documentation on 2026-11-10. Every section links its source.
Only need the quick answer? Google Workspace MX records (quick answer) · Google Workspace SPF record (quick answer) · Short version of this setup. This page is the full setup, including how it interacts with your other senders.
Check your domain against Google Workspace
Enter the domain you send from. We run the checks on the live DNS and show what is missing.
Free, no signup. The scan reads public DNS records only.
MX records for Google Workspace
| Type | Name | Priority and host |
|---|---|---|
| MX | @ | 1 smtp.google.com |
- Google now documents one MX record: smtp.google.com at priority 1. Any account can use it.
- The older aspmx.* records are still supported. If mail already works on them, Google says no change is required.
- Use your registrar default TTL, or 1 if you can set it. Google notes it can take up to 72 hours for new MX records to be recognised.
SPF for Google Workspace
The mechanism to add is include:_spf.google.com. A domain can publish only one SPF record, so you add it to the record that exists, you do not create a second one.
Google Workspace is your only sender
v=spf1 include:_spf.google.com ~allMerging into an existing record
Before
v=spf1 ip4:203.0.113.25 include:_spf.crm.example ~allAfter
v=spf1 ip4:203.0.113.25 include:_spf.google.com include:_spf.crm.example ~allLookup budget
SPF allows 10 DNS-querying terms in total (RFC 7208), nested includes included. This include costs 1 DNS lookup (the include itself plus whatever it points to), measured by querying DNS on 2026-11-10. That leaves 9 for every other sender. Providers change their records, so re-measure with the SPF checker before you add the next one.
- Google recommends ~all in your SPF record.
- Google states that each domain must have its own SPF record, so another sender is added to this record as one more include, not as a second TXT record.
- Google says an SPF record can have up to 10 include: tags. The real limit is 10 DNS-querying terms in total, nested ones included, so count the includes your other senders pull in as well.
DKIM for Google Workspace
Where: Google Admin console (Menu > Apps > Google Workspace > Gmail), DKIM section for the domain
- Open the DKIM settings for your domain in the Admin console and click Generate new record.
- Choose a key length: 2048 if your DNS host supports it, otherwise 1024. Keep the default selector prefix google unless you have a reason to change it.
- Copy the TXT record value Google shows and publish it at google._domainkey.<your-domain> at your DNS host.
- Wait for DNS to update, then click Start authentication. The status changes to "Authenticating email with DKIM".
| Type | Name | Value |
|---|---|---|
| TXT | google._domainkey | v=DKIM1; k=rsa; p=<public key from the Admin console>The key is generated per domain. Copy it from the Admin console; never reuse one from another domain. |
Selector. Default selector prefix is google. Google lets you change the prefix, so if the check finds nothing, read the s= value from a message you sent.
- Google says it can take up to 48 hours after adding the key before DKIM authentication starts working.
- Google also mentions a 24 to 72 hour wait before a DKIM key can be fetched in the Admin console.
- Google asks you to turn on SPF and/or DKIM first and to allow 48 hours before you set up DMARC.
DMARC with Google Workspace
DMARC passes when SPF or DKIM passes and aligns with the domain in the From address. Start by watching, not blocking.
- Google recommends starting with p=none and always including a rua address, with the record at _dmarc.<your-domain>.
- Google asks you to change the policy to quarantine (or reject) over time and, when rolling out gradually, to raise the percentage until you reach 100.
- Once the key above is active, messages are signed with your own domain, so DKIM can align with the From domain even when SPF does not.
Step 1
Monitor
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comPublish at _dmarc.<your-domain>. Nothing changes for delivery; receivers start sending aggregate reports to the rua address. Collect two to four weeks of reports, list every service that sends as your domain, and fix each one that fails SPF or DKIM alignment.
Step 2
Quarantine
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.comFailing mail goes to spam. Start with a small pct and raise it in steps (10, 25, 50, 75, 100) while the reports stay clean. pct is a rollout tool, not a permanent setting.
Step 3
Reject
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.comFailing mail is refused. This is the goal for any domain that sends mail. Keep the rua address so you notice when a new sender breaks.
A rua address on a different domain than the one you protect needs an authorisation record published by the receiving domain (<your-domain>._report._dmarc.<report-domain> as a TXT record with the value v=DMARC1;), otherwise receivers will not deliver the reports. Subdomains inherit the DMARC record of the parent domain unless they publish their own.
Common Google Workspace mistakes
- Publishing a second SPF record for another sender instead of adding an include to the existing one. Two v=spf1 records on one name are both ignored.
- Turning on DMARC before DKIM is active. Google asks for SPF and/or DKIM first and a 48-hour wait.
- Leaving the old aspmx MX records next to smtp.google.com, or old MX records from the previous provider in place. Use one MX configuration.
- Adding the DKIM TXT record at the wrong host. It belongs at google._domainkey (or your own prefix), and some DNS panels append the domain automatically, giving google._domainkey.example.com.example.com.
- Forgetting to click Start authentication after the record is published. The record alone does not turn signing on.
- Counting only the visible includes. A marketing tool, a CRM and a helpdesk each add their own lookups on top of Google.
Google Workspace email authentication FAQ
What SPF record does Google Workspace need?
Google documents v=spf1 include:_spf.google.com ~all for a domain that only sends through Google Workspace. If other services also send as your domain, keep one record and add their includes to it.
Which DKIM selector does Google Workspace use?
The default prefix selector is google, so the record lives at google._domainkey.<your-domain>. The record type is TXT. You can pick another prefix when you generate the key.
Do I need a 2048-bit DKIM key?
Google offers 2048 and 1024. Choose 2048 if your DNS host supports it; choose 1024 only when the host cannot hold a 2048-bit key.
How long until Google DKIM works?
Google says it can take up to 48 hours after you add the DKIM key before authentication starts. You then click Start authentication in the Admin console.
Should I start DMARC at p=reject?
No. Google recommends starting with p=none and a rua address so you can see who sends as your domain, then moving to quarantine and reject.
Can I have SPF records for both Google Workspace and my other senders?
Yes, but in one record. A domain must publish exactly one v=spf1 TXT record. Add each sender as an include or an ip4/ip6 term to that record. Two records give a permerror and both are ignored.
How do I check my Google Workspace authentication after changing DNS?
Enter your domain in the check on this page. It runs the IntoDNS.ai scan, the SPF checker (which counts DNS lookups) and, where the selector is known, the DKIM checker. DNS changes can take time to propagate, so re-check later.