What SPF record do I use for Google Workspace?

For a domain that sends only through Google Workspace, publish a single TXT record at your domain root containing v=spf1 include:_spf.google.com ~all. That one include covers all of Google's sending servers. Start with the ~all softfail while you confirm every legitimate sender is accounted for, then tighten to -all for a hard fail. Two rules matter: you may have only one SPF record per domain, so if you use other services, merge their includes into this single record rather than publishing a second one. And SPF permits at most ten DNS lookups during evaluation — each include consumes one or more, so adding many vendors can push you over the limit and return permerror, which receivers treat as a failure. Keep the includes minimal.

Why is my Google Workspace DKIM not signing?

The most common reason is that the DNS record was published but the final switch was never flipped. After you generate the key and create the google._domainkey TXT record, you must return to the Admin console under Apps → Google Workspace → Gmail → Authenticate email and click Start authentication — publishing DNS alone does not enable signing. A second cause is timing: after generating a key, Google can take up to 48 to 72 hours before it will let you start authentication, so a greyed-out or failing button often just means you need to wait. Also confirm the record is at the right host: Google's default selector is google, so the record must live at google._domainkey, and the published value should match exactly what the console generated, with no truncation.

Do I still need DMARC if I use Google Workspace?

Yes. SPF and DKIM tell receivers which servers and signatures are valid for your domain, but neither tells them what to do when a message fails, and neither protects the visible From address on its own. DMARC fills both gaps: it sets an enforcement policy and requires that the authenticated domain align with the From header, which is what actually stops spoofing. DMARC also delivers aggregate reports that show every source sending as your domain — invaluable for finding forgotten services and misconfigured tools. Major mailbox providers increasingly expect bulk senders to publish DMARC, and without it your legitimate mail is more likely to be filtered. Turning on Google's SPF and DKIM is only two-thirds of the job; DMARC is what ties them together and gives you visibility.

How do I move to p=reject safely?

Move in stages and let your DMARC reports guide each step. Begin at p=none so receivers take no action but still send aggregate reports to your rua address. Read those reports until every legitimate source — Google plus any third-party senders — passes with proper alignment. Next advance to p=quarantine, optionally using the pct tag to apply the policy to a sample first, for example pct=25, then raise it toward 100 as you confirm nothing legitimate is being quarantined. Only when quarantine has run cleanly for a while should you set p=reject, which tells receivers to drop failing mail outright. The whole point of ramping slowly is to avoid blocking real mail; never jump straight from no policy to reject, because any unaligned legitimate sender you missed will simply stop being delivered.

How to Set Up SPF, DKIM and DMARC for Google Workspace

Google Workspace sends your mail through Google's servers, but it does not authenticate that mail on your behalf until you configure three DNS-backed standards: SPF, DKIM and DMARC. Without them, receiving servers have no reliable way to confirm that a message claiming to come from your domain genuinely originated from your tenant. The result is mail that lands in spam, gets rejected outright, or — worse — leaves your domain open to spoofing.

This guide walks through each record in the order you should deploy it, explains the Admin console steps that catch most people out, and shows you how to verify the whole chain.

For the site owner (plain English)

This is routine setup, not a fire to put out. You are telling the rest of the internet that Google is allowed to send mail for your domain, and that forgeries should be refused. There are three records. SPF and DMARC are short text lines you add wherever your domain's DNS lives (GoDaddy, Cloudflare, wherever your nameservers point); DKIM is generated for you inside the Google Admin console, and you paste the value it produces into DNS. The one step people miss is purely inside Google: after publishing the DKIM record you must click Start authentication, or Google never actually signs your mail. If a checker flagged your domain as spoofable, the record that fixes it is DMARC — start it at p=none, then tighten it once you have watched a week of reports.

What SPF record do I publish for Google Workspace?

SPF (Sender Policy Framework) tells the world which servers are allowed to send mail for your domain. For Google Workspace, the only include you strictly need is Google's own sending infrastructure. Publish a single TXT record at the root of your domain (the host is typically @ or the bare domain name):

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

The ~all at the end is a softfail — it tells receivers that mail from anywhere else is suspicious but should still be accepted. Start here. Once you are confident every legitimate sender (Google plus any third-party tools that send as your domain) is listed, tighten the policy to a hard fail:

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

Two rules trip people up constantly. First, you may only have one SPF record per domain. If you already publish SPF for another service, merge the includes into a single record rather than adding a second TXT — multiple SPF records are an automatic failure under the specification.

Second, RFC 7208 allows a maximum of ten DNS lookups while a record is being evaluated. Each include: consumes at least one lookup, and some includes expand into several. If you stack many vendors, you can blow past the limit and the record returns permerror, which most receivers treat as a failure — so keep your includes lean.

How do I turn on DKIM in the Admin console?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound message. Receivers fetch your public key from DNS and use it to confirm the message was signed by your domain and was not altered in transit. Unlike SPF, you cannot simply paste a value you already know — Google generates the key pair for you.

Generate the key

In the Google Admin console, navigate to Apps → Google Workspace → Gmail → Authenticate email. Select the domain you want to sign, then generate a new record. Choose the 2048-bit key length (Google offers 1024-bit for legacy compatibility, but 2048-bit is the modern, recommended choice). Google's default selector is google, which is why the DNS host you publish to is google._domainkey.

Publish the public key

Google will show you a TXT record. Create it in your DNS with the host google._domainkey (your provider may append the domain automatically) and the long value beginning v=DKIM1; k=rsa; p=.... Because the key is 2048 bits, the value is long; some DNS providers require you to split it across multiple quoted strings, but most modern panels handle that for you.

Start authentication

After the DNS record has propagated, return to the same Admin console page and click Start authentication. This is the step that actually switches signing on.

Generating the DKIM key and publishing the DNS record is not enough on its own — signing stays off until you return to the Admin console and click Start authentication. Plenty of admins publish the record, see DNS resolve correctly, and assume they are done, then wonder why messages still are not signed. Also note that after you generate a key, Google can take up to 48–72 hours before it will let you start authentication — if the button is greyed out or errors, wait and try again rather than regenerating. And remember Google's default selector is google, so the record always lives at google._domainkey, not at a custom name.

How do I publish DMARC and ramp it up safely?

DMARC ties SPF and DKIM together. It tells receivers what to do when a message fails authentication and where to send reports so you can see who is sending mail as your domain. Publish a single TXT record at the host _dmarc (so the full name is _dmarc.yourdomain.com). Begin in monitoring mode:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

With p=none, receivers take no action against failing mail but still send you aggregate reports at the rua address. Those reports are the whole point of this phase: they reveal every source sending as your domain, including services you forgot about, so you can fix their SPF and DKIM alignment before you start enforcing.

DMARC also depends on alignment — the domain in the visible From header must match the domain validated by SPF or DKIM. A message can pass raw SPF yet still fail DMARC if the envelope domain does not align with the From domain. Reading your aggregate reports is how you catch alignment problems.

Once the reports show your legitimate sources passing cleanly, ramp the policy. Move to partial quarantine, then full quarantine, then rejection:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com

The pct tag applies the policy to a sample of failing mail (25% here), letting you watch the effect before going all in. Raise it toward 100, then advance to p=reject when you are confident nothing legitimate is failing.

How do I verify the whole chain works?

Before you trust the setup, confirm all three records resolve and that real mail passes. A few quick checks:

Query your TXT records directly — for example a DNS lookup of yourdomain.com for SPF, google._domainkey.yourdomain.com for DKIM, and _dmarc.yourdomain.com for DMARC.
Send a test message to an account you control on a different provider, then open the message headers and look for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results line.
Wait for your first DMARC aggregate reports to arrive and confirm Google's sources are aligned and passing.

Remember that DNS changes and Google's authentication switch can take time to take effect, so if a check fails on the first try, give it a few hours before troubleshooting.

Confirm all three records resolve and align before you enforce.

Check your SPF, DKIM and DMARC →

Where to go next

This page is the Google Workspace walkthrough within our broader email authentication material. For the concepts behind SPF, DKIM and DMARC — how alignment works and why each record matters — read the email authentication guide. If you also run Microsoft 365, the steps differ slightly; see how to set up DMARC for Office 365. And if your reports show failures once you enforce, see why DMARC fails and how to fix it or why a p=none policy leaves you unprotected.