Do I need both SPF and DKIM, or is one enough?

Google's guidelines technically require SPF or DKIM for all senders, but bulk senders (5,000+/day to Gmail) also need DMARC, which only passes if at least one aligned mechanism is in place. In practice you should set up all three: SPF, DKIM, and DMARC. For Workspace both SPF and DKIM align to your domain, so doing both gives DMARC two ways to pass.

I published the DKIM TXT record but DKIM still isn't passing — why?

Almost always because you didn't click Start authentication on the Authenticate email page, or you clicked it before the TXT propagated. Confirm google._domainkey.yourdomain.com resolves (dig TXT google._domainkey.yourdomain.com), then click Start authentication. If the key resolves but is reported invalid, check that a 2048-bit key wasn't truncated or its split strings mangled by your DNS panel.

Should I pick 2048-bit or 1024-bit for the DKIM key?

2048-bit — it's Google's recommendation and materially stronger. Only choose 1024-bit if your DNS host genuinely can't store the longer value. If you have an old 1024-bit key from years ago, generate a fresh 2048-bit one and re-run Start authentication.

How many SPF lookups does Google Workspace use?

One, today. include:_spf.google.com now resolves to a single flat SPF record with only ip4:/ip6: mechanisms, so it consumes just one of your 10 allowed DNS lookups. It historically nested three _netblocks includes (about four lookups total), which is why many older articles and some SPF checkers still cite 3–4.

Can I change the DKIM selector from 'google'?

You can, but you rarely need to. Keep the default google unless that selector is already used by another service on the same domain. The selector just names the DKIM key; what matters for DMARC is that the signature aligns to your domain.

I already send through SendGrid / Mailchimp / Microsoft 365. Will Google's records conflict?

No — DKIM uses the google selector, so it won't collide with other providers' selectors, and DMARC is a single shared record. The only rule is SPF: keep one SPF record and merge include:_spf.google.com with the other senders' mechanisms, watching the 10-lookup limit.

Do I still need MX records set up for authentication to work?

MX (Google's current setup uses a single smtp.google.com record) is about receiving mail, not authenticating outbound. SPF, DKIM, and DMARC work independently of MX — but you do need SPF/DKIM/DMARC on every domain you actually send from, whether or not it receives mail.

SPF setup guide

SPF, DKIM & DMARC for Google Workspace.

Authenticating Google Workspace means proving that the Gmail servers sending as your domain are really you. It comes down to three DNS records plus one switch inside the Admin console: an SPF TXT record that adds Google's shared include, a DKIM key you generate in the console and publish as a TXT record (then turn on with "Start authentication"), and a DMARC policy record. Google Workspace is one of the few senders that is also the receiver, so getting all three aligned is what makes your mail land in Gmail inboxes instead of drawing a "via" notice or sliding into spam.

SPF include

Your DNSAdd the CNAME / TXT records

Google WorkspaceSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Google Workspace?

Google Workspace mail already flows through Google's own infrastructure, but until you authenticate, that mail is only weakly attributable to your domain — Gmail may show a "via" note, DMARC can't pass, and your From address isn't cryptographically yours. Since February 2024, Google's own sender guidelines require every sender to pass SPF or DKIM, and every bulk sender (roughly 5,000+ messages a day to Gmail) to additionally publish a DMARC policy of at least p=none, with alignment. Yahoo adopted the same rules the same month and Microsoft began enforcing in 2025. Because Google is grading mail against its own guidelines here, an unauthenticated Workspace domain is the fastest route to the spam folder or an outright rejection. Doing SPF + DKIM + DMARC properly aligns both mechanisms to your domain, removes the "via" tag, lets DMARC pass, and builds sending reputation under your own name.

The SPF reality for Google Workspace

Google Workspace is a genuine "include" provider: you add one shared mechanism, include:_spf.google.com, to the single SPF TXT record on your root domain — the full record is v=spf1 include:_spf.google.com ~all. This is a real shared include (every Workspace customer uses the same one), unlike CNAME-delegation providers. It matters more here than for most senders because mail you send through Google uses an envelope sender on your own domain, so SPF actually aligns to your organizational domain and contributes a DMARC pass (not just DKIM). One important update: include:_spf.google.com is now a single flat SPF record containing only ip4:/ip6: mechanisms — it no longer nests the old include:_netblocks.google.com / _netblocks2 / _netblocks3 chain. That means it costs just one DNS lookup toward the RFC 7208 limit of 10, not the three-to-four that older guides and some cached SPF checkers still report. Google recommends ending with ~all (softfail) rather than -all, because Workspace users often also send legitimately through other tools; only tighten to -all once you're certain every sender is listed. And there must be exactly one SPF TXT record on the domain — if you also use SendGrid, Mailchimp, Microsoft 365, etc., merge every mechanism into that single v=spf1 line rather than publishing a second SPF record (two SPF records is a PermError).

Step by step

In the Admin console

1
Open Authenticate email
Sign in at admin.google.com as a super admin, then go to Menu (☰) → Apps → Google Workspace → Gmail → Authenticate email. This is the DKIM page; SPF and DMARC are added directly at your DNS host, not here.
2
Select the right domain
If you manage more than one domain, pick the sending domain from the dropdown at the top of the Authenticate email page. Each primary domain, secondary domain, and domain alias is authenticated separately.
3
Generate the DKIM key
Click Generate new record. Set the key length to 2048-bit (Google's recommendation; only fall back to 1024-bit if your DNS host can't store a long TXT value) and leave the selector prefix as the default google. Click Generate.
4
Copy the DKIM record
Google displays a TXT record: the host/name is google._domainkey and the value starts with v=DKIM1; k=rsa; p=… followed by a long public key. Copy both. Leave this tab open — you'll come back to click Start authentication.

In your DNS

5
Publish the DKIM TXT record
At your DNS host, add a TXT record with host google._domainkey and the value Google gave you. A 2048-bit key is longer than the 255-character-per-string TXT limit, so some hosts require you to keep it as multiple quoted chunks in one record — most panels handle this automatically; if not, paste the split value exactly as shown.
6
Add or merge the SPF record
Add a TXT record on the root domain (host @ or blank) with v=spf1 include:_spf.google.com ~all. If an SPF record already exists, don't create a second one — merge include:_spf.google.com into the existing v=spf1 line alongside any other senders.
7
Publish the DMARC record
Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start at p=none (monitor-only) so nothing is affected while you confirm alignment; you'll tighten it later.

In the Admin console

8
Click Start authentication
Back on the Authenticate email page, wait until the DKIM TXT has propagated, then click Start authentication. This is the step people miss — generating the key does nothing until you start authentication, after which the status reads 'Authenticating email for this domain.'

Verify

9
Send a test and check the headers
Send a message from a Workspace address, open it in another Gmail account, and use ⋮ → Show original. Confirm SPF: PASS, DKIM: PASS with 'signed-by: yourdomain.com' (selector google), and DMARC: PASS — all aligned to your domain, not to google.com.
10
Repeat for other domains and aliases
DKIM and the Start authentication step must be repeated for every secondary domain and domain alias you send from. SPF and DMARC records must exist on each of those domains too, or their mail won't authenticate.

Records to add

Google Workspace generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
TXT	@	v=spf1 include:_spf.google.com ~allRoot SPF — keep just one SPF record; merge other senders into this line. include:_spf.google.com now costs 1 DNS lookup.
TXT	google._domainkey	v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from the Admin console)Illustrative — the actual key is generated per domain under Apps → Google Workspace → Gmail → Authenticate email. 2048-bit keys may need to be published as split quoted strings.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comOne DMARC record per domain. Start at p=none, then tighten to quarantine/reject.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Google Workspace's setup costs against that budget.

SPF 10-lookup budget1 used · 9 free

Google Workspace adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.

DKIM

DKIM for Google Workspace is generated inside the Admin console, not copied from a fixed value. Go to Apps → Google Workspace → Gmail → Authenticate email, select the domain, click Generate new record, and choose 2048-bit with the default selector prefix google. Google then shows a TXT record whose host is google._domainkey.yourdomain.com and whose value is v=DKIM1; k=rsa; p=<your public key>. You publish that TXT at your DNS host — Google holds the matching private key and signs outgoing mail with it. Two things make Workspace DKIM different from most providers. First, publishing the record is not enough: you must return to the Authenticate email page and click Start authentication, or Google never actually begins signing with your key (this is the single most common reason a correctly-published record still shows no DKIM pass). Second, a 2048-bit public key exceeds the 255-character limit for a single TXT string, so many DNS hosts store it as several quoted chunks inside one record; the Admin console shows the value already formatted, and most panels (GoDaddy, Cloudflare, Namecheap, etc.) reassemble it correctly — if Gmail later reports the key as invalid, a broken concatenation is the usual culprit. The selector google is fine to keep; you'd only change it if that selector is already used by another service on the domain. Rotate away from any legacy 1024-bit key when you can, and remember DKIM is enabled per domain and per alias, not once for the whole account.

DMARC

DMARC is a separate policy record you publish yourself — Google doesn't create it for you. Add a TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery but tells receivers to email you aggregate reports so you can confirm that Google Workspace mail is passing SPF and DKIM aligned to your domain. Because Workspace aligns both mechanisms (SPF via your own envelope domain, DKIM via the google selector on your domain), you should see clean passes quickly. Watch the rua reports for a week or two, make sure every legitimate sender — Workspace plus any third-party tools — is authenticating, then tighten the policy to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole domain regardless of how many senders you use; never add a second DMARC record for Google specifically. Note that Google's own bulk-sender rule only mandates p=none as the floor, but p=reject is what actually protects your domain from spoofing.

Check it actually worked

Don't rely on the Admin console status alone — it can lag and still say "up to 48 hours" after DNS is already live. Confirm on a real message: send from a Workspace address to another mailbox, open it in Gmail, and choose ⋮ → Show original. You want SPF: PASS, DKIM: PASS, and DMARC: PASS, with the DKIM signed-by and SPF domains both showing yourdomain.com (selector google) rather than google.com. Google also publishes its own diagnostic, the Admin Toolbox CheckMX tool (toolbox.googleapps.com/apps/checkmx), which flags missing or malformed SPF/DKIM/DMARC and MX records. You can spot-check the raw records with dig TXT google._domainkey.yourdomain.com and dig TXT _dmarc.yourdomain.com. Finally, run the domain through Qualisend's domain health check to confirm every record resolves and the SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Google should appear as an aligned, fully-passing source.

Domain health check DMARC report analyzer

Common gotchas

Breaks auth
Generating the DKIM key does nothing until you click Start authentication on the Authenticate email page. A published google._domainkey record with signing never started is the #1 reason DKIM still fails a check.
Breaks auth
2048-bit DKIM keys are longer than a single 255-character TXT string, so they're stored as multiple quoted chunks. If Gmail reports the key invalid after publishing, a mangled concatenation (or your panel dropping the split) is almost always the cause.
Breaks auth
The Admin console may keep showing 'not authenticating' or 'up to 48 hours' even after your DNS is correct — the status re-checks on a delay. Trust Show original / Admin Toolbox over the console banner.
Coverage
DKIM must be set up separately for every secondary domain and domain alias, and each of those domains needs its own SPF and DMARC records too. Authenticating the primary domain does not cover the others.
Breaks auth
Keep exactly one SPF TXT record on the root. If you also send via SendGrid, Mailchimp, Microsoft 365, etc., merge include:_spf.google.com into the single v=spf1 line — two SPF records is a PermError.
DNS setup
include:_spf.google.com is now a single flat record (1 lookup), but older guides and some cached SPF checkers still count it as 3–4 — don't over-provision or panic-flatten based on stale numbers.
Coverage
Use ~all, not -all. Google recommends softfail because Workspace users frequently send legitimately through other services; a premature -all can hard-fail mail you forgot to list.
Coverage
Mail sent through a third-party relay, a Gmail 'Send mail as' external SMTP, or a marketing platform is not DKIM-signed by Google — those paths need their own authentication and won't align just because Workspace DKIM is on.

Build your SPF record

Google Workspace is pre-selected below. Add any other platforms you send through, then publish the single merged record.

Sending sources

Search for each platform you send email through and tick it.

Selected

Google Workspaceinclude:_spf.google.comGuide →

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record1/10 DNS lookups

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

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list