Google Workspace SPF record, DKIM and DMARC: the complete setup

The Google Workspace SPF record is one TXT record at your domain's root: v=spf1 include:_spf.google.com ~all. Add Google Workspace DKIM by generating a key in the Admin console, publishing it as a TXT record at google._domainkey, and clicking Start authentication. Then publish a DMARC record at _dmarc. All three go in your DNS, wherever your domain is hosted, not in Google's settings, and together they take about half an hour plus waiting time.

This guide is for Google Workspace administrators, including the owner of a small business who set Workspace up once and never touched DNS again. It covers each record with its exact value, where to click in the Admin console, and how to confirm it works. For how the three standards fit together, see the SPF, DKIM and DMARC setup guide.

Quick answer

• MX: smtp.google.com, priority 1. Older domains with the five ASPMX records keep working.
• SPF: v=spf1 include:_spf.google.com ~all at the root, with an extra include: for each other service that sends as you. One SPF record only.
• DKIM: Admin console → Apps → Google Workspace → Gmail → Authenticate email → generate a 2048-bit key → publish the TXT record at google._domainkey → Start authentication.
• DMARC: TXT at _dmarc with v=DMARC1; p=none; rua=mailto:[email protected]. Move to quarantine and reject once reports are clean.
• Check it with the free email and DNS health check, and in Gmail with Show original.

Before you start

You need two things: a super administrator account in the Google Admin console, and access to the place where your domain's DNS is managed. That is often your domain registrar, Cloudflare, or your web host, and it is not necessarily where you bought Workspace. If you are not sure, look up your domain's name servers: dig +short NS example.com shows them, and their names usually reveal the provider.

Check the MX records while you are there. New Workspace domains use one record, smtp.google.com with priority 1. Older domains often have five records (ASPMX.L.GOOGLE.COM and the ALT hosts), which still work; there is no need to change them. MX records control incoming mail, so an error there stops mail arriving rather than hurting authentication.

Step 1: the Google Workspace SPF record

SPF lists the servers allowed to send mail for your domain. For a domain that sends only through Google Workspace, the record is:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

In your DNS panel, that is a TXT record with the host @ (or left blank, depending on the panel) and the value v=spf1 include:_spf.google.com ~all.

If you already have an SPF record, do not add a second one. Two TXT records starting with v=spf1 make SPF fail for every message. Add Google's include to the existing record instead:

example.com.  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"

Mind the lookup limit. SPF allows 10 DNS lookups in total. Google's include costs 1 of them when we checked in September 2026, because _spf.google.com now lists its IP ranges directly; it used to cost 4. Other services' includes can cost several each, so a newsletter tool, a helpdesk and a CRM can still use up the rest. The guide to multiple SPF records and the 10-lookup limit explains how to merge records and stay under the limit.

~all or -all? Google's own example ends with ~all (softfail). Keep it while you are adding senders; -all gives little extra protection once DMARC is at reject. The SPF record guide explains the difference.

Step 2: turn on Google Workspace DKIM

Until you set up DKIM, Google signs your outgoing mail with a key for a shared Google domain ending in gappssmtp.com. That signature is valid, but it is not your domain, so it does not count for DMARC. Your mail then relies on SPF alone, which breaks as soon as a message is forwarded.

To sign with your own domain:

1. Sign in to the Google Admin console as a super administrator.
2. Go to Menu → Apps → Google Workspace → Gmail → Authenticate email.
3. Choose your domain and click Generate new record.
4. Pick the key length: 2048 unless your DNS provider cannot store long TXT records, then 1024. Leave the selector prefix as google unless that name is already in use.
5. Copy the DNS Host name (google._domainkey) and the TXT record value, which starts with v=DKIM1; k=rsa; p=.
6. Publish them as a TXT record at your DNS provider.
7. Wait until the record is visible, then return to the same page and click Start authentication. The status changes to "Authenticating email with DKIM".

The record looks like this, with a much longer key:

google._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

A 2048-bit key is about 400 characters, more than the 255 characters one DNS text string can hold. Most DNS panels split it automatically. If yours refuses the value, enter it as two quoted strings in the same record, never as two separate records. If the Admin console shows a warning on a brand-new account, Gmail may not be fully activated yet; wait a day and try again.

The guide to DKIM, selectors and the DKIM record explains what the key and the selector do.

Step 3: set up DMARC for Google Workspace

Google's Admin Help describes DMARC setup as a DNS task: there is no DMARC switch in the Admin console. Add a TXT record with the host _dmarc:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Google recommends starting with p=none, which changes nothing about delivery and asks receivers to send you daily reports. Create the dmarc@ mailbox or a group for it in Workspace first, or point rua at a report service. After two to four weeks, when the DMARC reports show every service you use passing, move to p=quarantine and later to p=reject. The DMARC policy guide has the full path.

Other senders on a Workspace domain

Google Workspace is rarely the only thing sending as your domain. Each of these needs its own setup:

• Newsletter, CRM, helpdesk and shop tools. Turn on domain authentication in each tool, and add its SPF include only if its setup page asks for one. Many use their own bounce domain and need only DKIM records.
• Your website. WordPress sends through the web server by default. An SMTP plugin can send through Google's SMTP relay service or the Gmail API instead, which gives it your SPF and DKIM.
• Printers, scanners and on-premises apps that send through smtp-relay.gmail.com are covered by Google's include and DKIM, as long as they send through the relay and not directly.
• "Send mail as" from another address. Adding an external address in Gmail and sending through Google's servers fails that other domain's DMARC unless that domain's own SPF and DKIM cover Google.

Secondary domains and domain aliases

Every domain in Workspace that sends mail needs its own records. For each secondary domain or domain alias:

• publish an SPF record on that domain, usually the same v=spf1 include:_spf.google.com ~all;
• generate a separate DKIM key for it on the Authenticate email page (choose the domain in the list) and publish it on that domain;
• publish a _dmarc record for it.

Domains that never send, such as a spelling-mistake domain that only redirects, should get v=spf1 -all and v=DMARC1; p=reject so nobody can send as them.

Verify each record

Run the check on your domain. It reads the MX records and recognises Google Workspace, so any record it suggests is written for Google. SPF should show "valid" with the number of lookups used, DMARC should name your policy, and DKIM should show a key for selector google.

Then test real mail. Send a message from Workspace to a personal Gmail address, open it, choose the three dots and Show original. You want:

• SPF: PASS with your domain;
• DKIM: 'PASS' with domain example.com, not a gappssmtp.com domain;
• DMARC: PASS.

Google's free Admin Toolbox also has a Check MX tool that reviews a Workspace domain's DNS.

Common mistakes

• Adding a second SPF record for Google next to one from the old host. Merge them.
• Publishing the DKIM record and never clicking Start authentication. DNS alone does nothing; Google keeps signing with its shared domain.
• Proxied records on Cloudflare. TXT records are never proxied, but CNAMEs for other tools' DKIM must be set to DNS only.
• The record at the wrong name, such as google._domainkey.example.com.example.com, when the panel appends the domain automatically.
• Forgetting secondary domains. Each one needs its own SPF, DKIM key and DMARC record.
• Jumping straight to p=reject before checking that your newsletter tool and website pass.

Questions people ask

What is the SPF record for Google Workspace?

It is a TXT record at your domain's root with the value v=spf1 include:_spf.google.com ~all. If you already have an SPF record for other services, add include:_spf.google.com to it instead of creating a second one, because two SPF records make both invalid. Google's include used 1 of the 10 DNS lookups SPF allows when we checked in September 2026.

How do I turn on DKIM in Google Workspace?

In the Admin console, go to Apps, Google Workspace, Gmail, Authenticate email. Choose the domain, generate a 2048-bit key, and publish the TXT record it shows at google._domainkey with your DNS provider. When the record is live, return to the same page and click Start authentication. Until then Google signs with a shared domain that does not help DMARC.

Why does Google Workspace say DKIM is not authenticating?

Usually because the TXT record is not visible yet, or does not match. Check it with dig +short TXT google._domainkey.example.com: the value must match the Admin console exactly, as one record. Common faults are a key cut off by the DNS panel, a record at the wrong host name, or a newly generated key that replaced the one you published.

Does Google Workspace need a DMARC record?

Workspace works without one, but you should publish one. Gmail, Yahoo and Outlook require a DMARC record from domains sending around 5,000 or more messages a day, and without it anyone can forge your domain. Google's Admin Help recommends starting with p=none and a report address, then tightening the policy once all your mail passes.

Do domain aliases in Google Workspace need their own SPF and DKIM?

Yes. SPF, DKIM and DMARC are published per domain, so every domain alias or secondary domain that sends mail needs its own SPF record, its own DKIM key generated for it in the Authenticate email page, and its own DMARC record. A domain alias that never sends should get records that say so: v=spf1 -all and p=reject.