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

Google Workspace sends mail on behalf of your domain using Google's infrastructure, and without SPF, DKIM, and DMARC in place, those messages are vulnerable to spoofing and deliverability problems. This guide gives you the exact DNS records to publish, the steps to retrieve your DKIM key from the Google Admin console, and a working DMARC record — so you leave with a fully authenticated domain.

Before you begin

• Write access to your domain's DNS zone (via your registrar or DNS provider — Cloudflare, Route 53, GoDaddy, etc.)
• Super Admin access to the Google Admin console for your Workspace account
• At least one mailbox on the domain you are authenticating, so you can send a test message after setup
• An understanding of your domain's existing SPF record, if one already exists — you will be modifying it, not replacing it blindly

Step 1: Identify what's sending from Google Workspace

Google Workspace routes outbound mail through Google's shared mail servers, but your domain may also send through other services — transactional email platforms, CRMs, marketing tools, or on-premise relays. SPF authorizes specific infrastructure, so before touching any records, list every service that injects mail with your domain in the From: or Return-Path: header. Each one needs its own SPF mechanism. Adding Google's include without accounting for the others will fix Google-sent mail while leaving everything else unauthenticated — or, worse, pushing you over the SPF 10-lookup limit.

Step 2: Add the SPF include

Google Workspace's authorized sending infrastructure is declared via a single include mechanism. Add it to your domain's TXT record at the apex (@ / root). If you already have an SPF record, merge the Google mechanism into it — do not create a second SPF TXT record on the same hostname.

The SPF include string for Google Workspace is include:_spf.google.com. Verify this against Google's current SPF documentation before publishing.

Before — existing SPF record with no Google mechanism:

your-domain.com. 3600 IN TXT "v=spf1 include:_spf.example-esp.com ~all"

After — Google Workspace mechanism added:

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

SPF 10-lookup limit warning: Every include:, a:, and mx: mechanism triggers DNS lookups at evaluation time, and the SPF specification hard-caps these at 10. Google Workspace's include:_spf.google.com itself resolves through several nested lookups. If your record already contains multiple includes for other services, adding Google may push you over the limit, causing permerror and an automatic SPF fail. Audit your lookup count with a tool like MXToolbox SPF Analyzer before and after the change. DMARC Busta's SPF Auto-Repair feature is designed to handle this automatically — see the last section.

Step 3: Enable DKIM in Google Workspace

Google Workspace generates a 2048-bit RSA DKIM key pair per domain. You generate the key in the Admin console, then publish the public key as a DNS TXT record. Google will not begin signing outbound mail until it can confirm the DNS record is live.

1. Sign in to admin.google.com as a Super Admin.
2. Navigate to Apps → Google Workspace → Gmail → Authenticate email.
3. Select the domain you are configuring from the domain selector if your account has multiple domains.
4. Click Generate new record. Choose a key length of 2048 bits if given the option (preferred over 1024-bit).
5. Google displays a selector name (typically google) and the full TXT record value — a long base64 string beginning with v=DKIM1; k=rsa; p=.... Copy both values exactly.
6. In your DNS provider, create a new TXT record using the following structure:

The published record will look like this (truncated for readability):

google._domainkey.your-domain.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

After publishing, return to the Admin console and click Start authentication. Google polls for the DNS record and activates DKIM signing once it resolves. DNS propagation can take anywhere from a few minutes to 48 hours depending on your provider and TTL.

Long DKIM keys and DNS string limits: Some DNS providers split TXT record values at 255 characters. If your provider requires multiple quoted strings within the same record, ensure they are concatenated correctly without spaces inside the key data. A malformed split will cause DKIM verification failures even if the record appears to publish correctly. Check the raw DNS output with dig google._domainkey.your-domain.com TXT to confirm the full value resolves as a single logical string.

Step 4: Publish your DMARC record

Start with p=none. This puts DMARC into monitoring mode — it collects reports and logs failures without affecting mail delivery. Run it for a minimum of 14 days before moving to p=quarantine or p=reject. Skipping this step and jumping straight to enforcement is the single most common cause of legitimate mail being blocked.

Create a TXT record at _dmarc.your-domain.com:

_dmarc.your-domain.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro; ruf=mailto:dmarc-rua@dmarcbusta.pro; fo=1; adkim=r; aspf=r"

Tag-by-tag breakdown:

• v=DMARC1 — required version identifier
• p=none — monitor only; no enforcement action on failing mail
• rua=mailto:dmarc-rua@dmarcbusta.pro — aggregate report destination (where ISPs send XML summary reports)
• ruf=mailto:dmarc-rua@dmarcbusta.pro — forensic report destination (individual failure reports; not all receivers send these)
• fo=1 — request a forensic report if any underlying authentication check fails, not just full DMARC failure
• adkim=r — relaxed DKIM alignment; the signing domain must share the organizational domain with the From: header, but does not need to match exactly
• aspf=r — relaxed SPF alignment; same logic applied to the Return-Path: domain

Once your aggregate reports show consistent pass rates across all legitimate sending sources, update the policy tag to p=quarantine, monitor for another cycle, then move to p=reject.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

Send a test message from a mailbox on your domain to a Gmail or Yahoo address you control. Open the message, view the full headers (in Gmail: the three-dot menu → Show original), and look for the Authentication-Results header near the top of the raw message.

A fully passing result looks like this:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of sender@your-domain.com designates 209.85.x.x as permitted sender)
           smtp.mailfrom=sender@your-domain.com;
       dkim=pass header.i=@your-domain.com header.s=google header.b=AbCdEfGh;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

• spf=pass — the sending IP is listed in your SPF record and the Return-Path: domain matches
• dkim=pass — Google's signature on the message was verified against the public key in DNS; header.s=google confirms the selector used
• dmarc=pass — at least one of SPF or DKIM passed and the passing domain aligns with the From: header domain

If any result shows fail, permerror, or softfail, work backwards: check that the DNS records have propagated, that no typos exist in the SPF include or DKIM value, and that Google Workspace DKIM signing is active (not just the key published).

Common errors with Google Workspace

• DKIM not activated after DNS publication. Publishing the DNS record alone does not start signing. You must return to the Admin console and click Start authentication. Mail sent before this step carries no DKIM signature regardless of what is in DNS.
• Duplicate SPF TXT records. Some DNS providers silently allow two TXT records at the root. SPF processors will return permerror if they find more than one v=spf1 record on the same hostname. Merge all mechanisms into a single record.
• SPF lookup overflow from chained includes. include:_spf.google.com resolves through several nested DNS queries. Combined with includes for other platforms, it is easy to exceed 10 lookups. Use an SPF analyzer to count before and after adding Google's include.
• DKIM key value split incorrectly in DNS. DNS providers with a 255-character TXT limit require the key to be split into multiple quoted strings. If concatenation is wrong — extra spaces, missing quotes, or characters dropped — the key will not verify even though a dig query appears to return something. Always validate with dig google._domainkey.your-domain.com TXT +short and confirm the output matches what Google displayed in the Admin console.
• DMARC failure despite SPF and DKIM passing. DMARC requires alignment — the domain in SPF's Return-Path: or DKIM's d= tag must match the organizational domain in the visible From: header. If your mail platform rewrites the Return-Path: to a subdomain or a third-party domain, SPF will pass but DMARC alignment will fail. Check the header.from versus smtp.mailfrom values in the Authentication-Results header.

How DMARC Busta helps

The steps above cover a single domain with Google Workspace as the only sender. In practice, most organizations discover additional sending sources in their DMARC aggregate reports — forgotten newsletter tools, third-party CRMs, ticketing systems — and managing SPF, DKIM, and policy progression manually across those sources becomes error-prone at scale. DMARC Busta's Autopilot mode is designed to handle policy progression automatically, advancing from p=none to p=reject as report data confirms it is safe to do so. SPF Auto-Repair is designed to manage SPF delegation and source authorization without requiring manual record edits each time a new sender is onboarded, and to handle the 10-lookup constraint without human intervention. The managed DMARC reporting dashboard aggregates XML reports across all your domains in a single view — built to support multi-domain MSP deployments at scale, with the architecture to manage 10,000+ domains.

If you followed this guide and your reports are already showing unexpected sources or SPF lookup warnings, DMARC Busta's Autopilot is designed to take over from exactly this point — parsing your aggregate data, identifying unauthorized senders, and progressing your policy on a schedule your delivery reputation can support.

Start your free trial and put your email authentication on autopilot.