Google Workspace Email Authentication: SPF, DKIM & DMARC

Google Workspace handles delivery, but the three authentication protocols are still yours to configure in DNS. Without them, your domain fails the sender requirements Gmail, Yahoo and Outlook enforce for bulk senders — and if you publish records in the wrong order, you can reject your own mail.

This guide gives the exact console paths and records for a Workspace domain, in a safe sequence. New to the protocols? Read the email authentication overview first.

What you need

• Admin access to admin.google.com (Super Admin or a delegated Gmail admin role).
• Write access to your domain's DNS at your registrar or DNS host. On Cloudflare, see the Cloudflare DNS guide first.
• A list of every non-Gmail service that sends as your domain: CRM, marketing platform, help desk, billing. Workspace records cover only mail sent through Gmail.

Step 1: Publish the SPF record

Create one TXT record at the root (host @ or blank):

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

If other services send as your domain, merge them into this same record:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Two constraints: a domain may have exactly one SPF record — a second v=spf1 TXT causes permanent failure — and _spf.google.com costs about four of the ten DNS lookups RFC 7208 allows, so budget the rest. Keep ~all until DMARC reports confirm full coverage, then consider -all. Verify with the SPF Checker, or build the record with the SPF Generator.

Step 2: Enable DKIM in the Admin console

1. In admin.google.com, go to Apps > Google Workspace > Gmail > Authenticate email.
2. Select the domain, click Generate new record, and choose the 2048-bit key length. Google recommends 2048-bit; 1024-bit keys are considered weak.
3. Publish the TXT record at google._domainkey.yourdomain.com (default selector google).
4. Back in the console, click Start authentication.

Gmail signs outbound mail only after the status shows "Successfully authenticated" — generating the record without flipping this switch is a classic no-op. Confirm the key yourself with the DKIM Checker using selector google, and repeat for every alias domain you send from; DKIM does not cascade.

Step 3: Publish DMARC yourself

Google does not manage DMARC for you. Add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

p=none blocks nothing and collects daily aggregate reports listing every source sending as your domain, with its SPF, DKIM and alignment results. Read them with the DMARC Report Analyzer, fix legitimate senders that fail, then escalate — p=quarantine with a low pct first, p=reject last. Never skip the monitoring period. Generate records with the DMARC Generator.

Verify the whole stack

Send from Workspace to a Gmail address and open Show original. You want:

SPF:    PASS with IP 203.0.113.10
DKIM:   'PASS' with domain yourdomain.com
DMARC:  'PASS'

The DKIM line must show your domain — Gmail signs with d=yourdomain.com, which is what alignment requires. For a domain-wide check, run the Email Health Check or the Email Deliverability Test, and inspect raw headers with the header analyzer.

Common mistakes

• Two SPF records. Registrars accept them; receivers do not. Merge every include into one record.
• Double-suffixed host name. Entering google._domainkey.yourdomain.com where the panel appends your domain creates a name ending in .yourdomain.com.yourdomain.com, and DKIM fails silently. Confirm with a TXT lookup.
• Record generated, authentication never started. The key exists in DNS but Gmail still sends unsigned.
• Third-party senders assumed covered. A CRM sending as yourdomain.com is neither authorized by the Google include nor signed by Gmail. See the SendGrid and Mailgun guides for the common cases.
• Alias domains left unsigned. Each alias used in From needs its own DKIM and SPF records.

Frequently asked questions

Do alias domains need their own records?

Yes. Each alias domain needs its own DKIM setup and SPF record, and DMARC evaluates per domain — an unsigned alias fails even when the primary domain is perfect.

When should ~all become -all?

Only after weeks of DMARC reports show every legitimate sender passing SPF. A premature -all hard-fails mail from any service you forgot to include.

Why is the 2048-bit record split into two strings?

Long keys exceed some providers' 255-character limit per TXT string, so they are published as two strings that receivers concatenate. Publish it exactly as the console provides.