Set Up SPF, DKIM and DMARC for Google Workspace (Step by Step)

Step-by-step SPF, DKIM and DMARC setup for Google Workspace domains: the smtp.google.com MX record, include:_spf.google.com, a 2048-bit DKIM key with the google selector, and a safe DMARC rollout from p=none to quarantine and reject.

Quick answer

For a domain that sends mail only through Google Workspace, you publish three DNS records and turn on DKIM signing in the Admin console:

@                   TXT  v=spf1 include:_spf.google.com ~all
google._domainkey   TXT  v=DKIM1; k=rsa; p=<key from the Admin console>
_dmarc              TXT  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

SPF and DMARC are DNS-only: Google says you don't need to do anything in the Admin console for them. DKIM needs both a key generated in the Admin console and a click on Start authentication after the TXT record is live. Once DMARC reports look clean, move from p=none to p=quarantine and then p=reject.

Google's sender guidelines require every sender to personal Gmail accounts to set up SPF or DKIM, and bulk senders (more than 5,000 messages a day) to set up all three. See the bulk sender requirements guide for the full checklist.

Before you start

You need access to the domain's DNS host (usually where you bought the domain). If you bought the domain from a Google partner when you signed up, or your domain host is Squarespace, some of these records may already be set up for you. Check first with the Email Deliverability Checker.
Generating a DKIM key needs a super administrator account in the Google Admin console.
Google says to wait 24 to 72 hours after turning on Gmail for your organization before generating a DKIM key. If you try earlier, you might get an error that the DKIM record was not created.
Make a list of everything else that sends mail as your domain: web servers, on-premises mail servers, outbound gateways, contact forms, CRM, marketing and helpdesk tools. Each one has to be covered by SPF or sign with DKIM for your domain before you enforce DMARC.

Step 1: Check your MX records

MX records control inbound mail, not authentication, but they are the first thing to confirm when you move a domain to Google Workspace. Google's current MX record is a single host:

Type: MX   Name: @   Priority: 1   Value: smtp.google.com

Remove any other MX records. Google warns that leaving old or incorrect MX records can stop mail from working correctly.
If you started using Google Workspace before 2023, your domain may still use the older values that start with aspmx. Google says those are still supported, so if mail works, no change is needed.
Some DNS hosts want a trailing dot (smtp.google.com.); others add it for you.
Google says new MX records can take up to 72 hours to be recognized. Then activate Gmail for the domain in the Admin console under Account > Domains > Manage domains.

See what a domain publishes today with the MX Record Lookup, and confirm changes worldwide with the DNS Propagation Checker.

Step 2: Publish SPF

If Google Workspace is the only service that sends as your domain, add this TXT record at the root of the domain (host @):

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

If other services send as you, put them all in the same record. Examples from Google's own table:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all   (Google Workspace + Microsoft 365)
v=spf1 include:_spf.google.com include:amazonses.com ~all             (Google Workspace + Amazon SES)
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all          (Google Workspace + Mailchimp)
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all       (Google Workspace + Salesforce)

One SPF record per domain. Two records starting with v=spf1 is a permanent error and SPF fails.
Stay under 10 DNS lookups, counting the lookups inside every include (nested lookups count too). When we checked on 17 October 2026, _spf.google.com listed Google's IP ranges directly, so it cost one lookup. Google can change that, so recount after every edit with the SPF Record Checker.
~all or -all: Google recommends ~all (soft fail). With -all, receivers are more likely to reject mail from unlisted servers, which also makes problems harder to troubleshoot; Google suggests using DMARC reports to find every sender if you go that way. Either way, your DMARC policy is what really decides what happens to spoofed mail.
Subdomains: SPF isn't inherited. Every subdomain that sends mail needs its own SPF record, and each domain in your Workspace account needs its own record.
Some DNS hosts want the value in quotes. Check your host's help.

Combine senders with the SPF Record Builder. Google says SPF can take up to 48 hours to start working.

Step 3: Generate a DKIM key in the Admin console

Sign in to the Google Admin console as a super administrator and go to Menu > Apps > Google Workspace > Gmail, then click Authenticate email.
In Selected domain, choose the domain.
Click Generate New Record.
Key bit length: choose 2048 if your DNS host supports 2048-bit keys (longer keys are more secure). Choose 1024 only if it doesn't. If you used a 1024-bit key before, you can switch to 2048.
Prefix selector: leave the default, google, which Google recommends. Only enter a different prefix if your domain already has a DKIM key named google (for example from an older setup).
Click Generate. The page shows a DNS Host name (for example google._domainkey) and a TXT record value in the form v=DKIM1; k=rsa; p=....
Copy both values. Don't click Start authentication yet.

If you have more than one domain in the Workspace account, repeat this for each one. Google says every domain needs its own unique DKIM key from the Admin console.

Step 4: Publish the DKIM TXT record

Type: TXT. Host/Name: google._domainkey (most DNS hosts add your domain automatically, so don't type google._domainkey.example.com or you may end up with the domain twice). Value: the full v=DKIM1; k=rsa; p=... string.
2048-bit keys are longer than 255 characters, and many DNS hosts limit a single TXT string to 255 characters. Google's fix: split the key into several strings, put each one in quotes, and enter them one after another in the same Value field. The receiver joins them back together. If your host can't do that, generate a 1024-bit key instead.
For a subdomain, ask your DNS host how to add a TXT record under that subdomain.

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...first part..."
"...second part...IDAQAB"

Check that the record is live and complete with the DKIM Checker (it tries the google selector along with other common ones) and paste the value into the DKIM Record Explainer to confirm it is a 2048-bit RSA key. Google says it can take up to 48 hours for DKIM to start working after you add the key.

Step 5: Turn on DKIM signing and verify

Back in Apps > Google Workspace > Gmail > Authenticate email, select the domain and click Start authentication. When it works, the status changes to Authenticating email with DKIM.
The page may keep showing "You must update the DNS records for this domain" for up to 48 hours. If you have added the record correctly, Google says you can ignore it.
Send a message to someone who uses Gmail or Google Workspace. Google notes you can't verify DKIM by sending yourself a test message.
In Gmail, open the message, click More > Show original and copy the headers into the Email Header Analyzer. In Authentication-Results you want dkim=pass with header.d= your domain, plus spf=pass.

If the header has no DKIM line at all, messages aren't being signed: re-check the Admin console status and the TXT record.

Step 6: Publish DMARC at p=none

Google says to have SPF and DKIM authenticating mail for at least 48 hours before you turn on DMARC. Then create a dedicated group or mailbox for reports (you can get many each day) and publish a TXT record at host _dmarc:

Host:  _dmarc
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The v and p tags must come first.
rua needs the mailto: prefix. For several addresses, separate them with commas and put mailto: before each one.
If the report address is in a different domain, that domain must publish an authorization TXT record. For example, reports for example.com sent to reports.example.net need TXT example.com._report._dmarc.reports.example.net with value v=DMARC1;. Third-party DMARC report services already do this.
Gmail doesn't send failure (forensic) reports, so a ruf tag has no effect there.
Alignment is relaxed by default (adkim=r, aspf=r). Google says relaxed typically gives enough spoofing protection, and strict alignment can send mail from your own subdomains to spam or get it rejected.

Build the record with the DMARC Record Generator and check what's live with the DMARC Record Checker.

Step 7: Move to quarantine, then reject

Google's recommended rollout:

Stay at p=none for about one week and read the reports daily. Google says a week is usually enough for the reports to show all your mail streams. Fix any legitimate sender that fails SPF and DKIM alignment.
Move to p=quarantine for a small percentage of mail with pct. Google's example is v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com. It suggests a small organization might start at 10% and a large one at 1%.
Raise pct over time until the policy covers 100% (leaving pct out means 100%).
Finish at v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com, where receivers refuse mail that fails DMARC.

The newer DMARC standard (RFC 9989) drops pct, so some receivers may apply your full policy even while you publish a percentage. Only raise the policy when your reports are clean. The DMARC rollout guide covers pct, t=y and np= in more detail. If you plan to use BIMI, Google requires p=quarantine or p=reject with pct=100; the BIMI Record Generator builds the record.

Subdomains, extra domains and third-party senders

Subdomains: without an sp= tag, subdomains inherit the parent domain's DMARC policy. SPF and DKIM are different: each sending subdomain needs its own SPF record and its own DKIM key.
Extra domains in the same account: each domain needs its own SPF record, its own DKIM key from the Admin console and its own DMARC record. Each can have a different policy.
Third-party senders: Google's advice is to confirm with each provider that SPF and DKIM are set up, make sure the provider's envelope sender domain matches your domain, add its sending servers to your SPF record, or route its mail through Google with the SMTP relay service.
Outbound gateways: a gateway that changes messages after Google signs them (adding a footer, for example) breaks DKIM. Google says to check gateway settings so they don't interfere.

Common mistakes

Adding a second SPF record for a new tool instead of merging it into the existing one.
Copying the Microsoft 365 include (spf.protection.outlook.com) when the domain actually sends through Google, or the reverse.
Pasting a 2048-bit DKIM key into a host that silently truncates it at 255 characters. Split it into quoted strings, then confirm the full key with the DKIM Checker.
Publishing the DKIM TXT record but never clicking Start authentication, so Gmail never signs with your domain.
Keeping the google prefix when another service already publishes a DKIM key at google._domainkey for your domain. Google says to enter a different prefix in that case.
Testing DKIM by mailing yourself, which Google says doesn't verify anything.
Publishing DMARC at the root (@) instead of _dmarc, or leaving out mailto: in rua.
Jumping straight to p=reject before reports show every legitimate sender passing.

Related tools and guides

Check the whole domain with the Email Deliverability Checker, look up MX records with MX Record Lookup, build and test SPF with the SPF Record Builder and SPF Record Checker, find and grade DKIM keys with the DKIM Checker, and create and verify DMARC with the DMARC Record Generator and DMARC Record Checker. Read test messages in the Email Header Analyzer. Related guides: Gmail, Yahoo and Outlook bulk sender requirements and, for Microsoft 365 domains, SPF, DKIM and DMARC.

FAQ

What is the SPF record for Google Workspace?

If Google Workspace is your only sender, publish v=spf1 include:_spf.google.com ~all as a TXT record at the domain root. Add other senders to the same record, for example include:spf.protection.outlook.com for Microsoft 365, and keep the whole record under 10 DNS lookups.

What is the default DKIM selector for Google Workspace?

The default prefix selector is google, so the DKIM key is published as a TXT record at google._domainkey.yourdomain. Google recommends keeping the default unless your domain already has a DKIM key with that name.

Should I use a 2048-bit or 1024-bit DKIM key in Google Workspace?

Use 2048-bit if your DNS host supports it, because longer keys are more secure. A 2048-bit key is longer than 255 characters, so split it into several quoted strings in one TXT record. Choose 1024-bit only if your DNS host cannot store the longer key.

Why can I not generate a DKIM key in the Google Admin console?

You must be signed in as a super administrator, and Google says to wait 24 to 72 hours after turning on Gmail for your organization. Generating a key earlier can fail with an error that the DKIM record was not created.

What DMARC record should I start with for Google Workspace?

After SPF and DKIM have been working for at least 48 hours, publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain at host _dmarc. Watch reports for about a week, then move to p=quarantine with a small pct value, raise it to 100 and finish at p=reject.

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