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

Why Google Workspace requires proper authentication

Since February 2024, Google requires all senders to have SPF or DKIM configured. Bulk senders (over 5,000 messages per day) must have both, plus DMARC. Without proper authentication, your emails risk landing in spam or being rejected outright.

This guide walks you through setting up all three protocols for Google Workspace — SPF, DKIM, and DMARC — step by step.

Before you start

You will need:

• Access to Google Admin console (admin.google.com) with super administrator privileges
• Access to your domain's DNS manager (registrar or a service like Cloudflare)
• A list of all services that send email from your domain — besides Google Workspace, this may include marketing platforms, helpdesk tools, billing systems, or CRMs

If you are not sure which services send email from your domain, run a full domain analysis — it will show you all sending sources.

Step 1: Set up SPF

SPF (Sender Policy Framework) tells receiving servers which servers are authorized to send email from your domain. For Google Workspace, you add a single TXT record to your DNS.

SPF record for Google Workspace

If you send email only through Google Workspace, add this TXT record to your domain's root (@):

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

The include:_spf.google.com mechanism authorizes all Google IP addresses used for sending Workspace email.

SPF record with additional services

If you also send email through other services besides Google Workspace, add their include mechanisms to the same record. Example with Mailgun and a dedicated server:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

Important: A domain may only have one SPF record. Two separate TXT records starting with v=spf1 cause SPF checks to fail with a PermError (RFC 7208, Section 4.5). All sending sources must be in a single record.

Adding the DNS record

1. Sign in to your domain's DNS manager
2. Navigate to the DNS records section
3. Create a new TXT record:
   • Host/Name: @ (root domain)
   • Type: TXT
   • Value: your SPF record
4. Save changes

DNS propagation typically takes minutes, but may take up to 48 hours. Verify your record with the SPF analyzer.

~all versus -all

Google's documentation recommends ~all (softfail). In practice, the difference between ~all and -all (hardfail) is minimal — major providers like Google and Microsoft primarily follow the DMARC policy rather than the SPF qualifier. We recommend ~all during initial setup and switching to -all only after confirming all legitimate sources are included in the record.

Step 2: Set up DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email. The recipient verifies the signature using a public key in DNS, confirming the message was not altered in transit and originated from your domain.

Generate a DKIM key in the Admin console

1. Sign in to Google Admin console
2. Go to Apps → Google Workspace → Gmail → Authenticate email
3. Select the domain you are configuring from the Selected domain menu
4. Click Generate New Record
5. Select 2048-bit key length (recommended) — if your DNS provider does not support long TXT records, choose 1024-bit
6. Leave the prefix selector at the default google unless you have a reason to change it
7. Click Generate

The Admin console will display a TXT record to add to your DNS.

Add the DKIM record to DNS

1. Go to your domain's DNS manager
2. Create a new TXT record:
   • Host/Name: google._domainkey (or a different prefix if you changed it)
   • Type: TXT
   • Value: the complete string starting with v=DKIM1; k=rsa; p=... copied from the Admin console
3. Save changes

Activate DKIM signing

Adding the DNS record alone is not enough — you must return to the Admin console and explicitly enable signing:

1. Go back to Apps → Google Workspace → Gmail → Authenticate email
2. Click Start authentication

If the button is not active, the DNS record has not propagated yet. Wait and try again — propagation typically takes minutes but can take up to 48 hours.

Verify DKIM is working

After activation, send a test email to an address outside your domain (e.g., a personal Gmail account) and check the received message headers:

Authentication-Results: mx.google.com;
    dkim=pass header.d=example.com header.s=google

If you see dkim=pass, signing is working. You can also verify the DNS record with our DKIM analyzer.

Step 3: Set up DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM to the sender address in the From header. It tells receiving servers what to do with emails that fail authentication, and sends you reports about the results.

Wait at least 48 hours after setting up SPF and DKIM before deploying DMARC. Receiving servers need time to recognize your new records.

Starting DMARC record

Start with a none policy — DMARC will only monitor and send reports without affecting delivery:

v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com,mailto:dmarc@example.com

• p=none — monitoring mode, emails are delivered normally
• rua= — addresses for receiving aggregate reports

If you include the SPF Monitor address (example.com@rua.spfmonitor.com), reports are automatically processed, visualized, and you get alerted when issues arise — no need to manually parse XML files.

Adding to DNS

1. Go to your domain's DNS manager
2. Create a new TXT record:
   • Host/Name: _dmarc
   • Type: TXT
   • Value: your DMARC record
3. Save changes

Verify your record with the DMARC analyzer.

Gradually tightening the policy

After 2–4 weeks of monitoring, analyze your DMARC reports. If legitimate emails pass authentication consistently, tighten the policy step by step:

1. p=none — monitoring (2–4 weeks)
2. p=quarantine; pct=10 — 10% of unauthenticated messages quarantined
3. p=quarantine; pct=100 — all unauthenticated messages quarantined
4. p=reject — full rejection of unauthenticated messages

The pct parameter enables a gradual rollout — start at 10% and increase over time. For details on reading and evaluating reports, see our guide on how to read DMARC reports.

Additional sending services

Google Workspace is not the only source of email from your domain. Marketing platforms (Mailchimp, Brevo), transactional services (SendGrid, Mailgun, Amazon SES), helpdesks (Zendesk, Freshdesk), or billing systems — each of these services needs its own authentication.

SPF for additional services

Add the include mechanism for each service to your SPF record. Every service publishes its include address in their documentation. Example with three services:

v=spf1 include:_spf.google.com include:mailgun.org include:sendgrid.net ~all

Watch for the 10 DNS lookup limit in SPF records. Each include consumes at least one lookup. Exceeding the limit causes SPF checks to fail with a PermError. Check your lookup count with the SPF analyzer.

DKIM for additional services

Each service has a domain authentication section in its admin panel (Domain Authentication / Domain Verification). The service generates DNS records (TXT or CNAME) that you add to your domain. Once verified, the service signs emails with your domain's DKIM key instead of its own default.

Without DKIM verification, a service signs emails with its own domain — recipients see "signed by: sendgrid.net" instead of your domain. This hurts credibility and breaks DMARC alignment.

Common mistakes and how to fix them

Two SPF records on the domain

A common mistake when adding Google Workspace to an existing email setup: the administrator creates a new SPF record instead of editing the existing one. Two v=spf1 records on the same domain cause automatic SPF failure.

Fix: Check your domain's DNS records. If an SPF record already exists, edit it — do not add a new one.

Forgotten DKIM activation

The DKIM DNS record with the public key exists, but Start authentication was never clicked in the Google Admin console. Emails are not being signed even though the key is correctly published in DNS.

Fix: Return to Admin console → Gmail → Authenticate email and click Start authentication.

DMARC deployed too aggressively

Skipping the monitoring phase (p=none) and deploying p=reject directly can block legitimate emails from services that do not have SPF or DKIM configured properly.

Fix: Always start with p=none and tighten only after analyzing DMARC reports.

Missing third-party authentication

DMARC reports show failures for emails sent from a marketing platform or helpdesk. The service sends from your domain but lacks authentication.

Fix: Map all sending services and configure SPF (include) and DKIM for each one. A full domain analysis will show you all email sources.

Checklist

• SPF record added to DNS (include:_spf.google.com)
• SPF record verified with analyzer — syntax, lookup count
• DKIM key generated in Admin console (2048-bit)
• DKIM TXT record added to DNS (google._domainkey)
• DKIM signing activated in Admin console (Start authentication)
• Test email confirmed — spf=pass and dkim=pass
• DMARC record deployed with p=none and reporting address
• DMARC record verified with analyzer
• All additional sending services authenticated (SPF + DKIM)
• Plan for gradual DMARC policy tightening established