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

This guide walks through how to set up SPF, DKIM and DMARC in Google Workspace end to end: the exact DNS value to publish for SPF, the Admin console path that turns on DKIM signing, and a first DMARC record that is safe to start with. It is implementation only. If you want the definitions of each protocol, the glossary posts cover that; here the goal is a domain that authenticates correctly.

Two of the three records live in your DNS host; only DKIM is generated inside the Google Admin console. Every value and console path below was checked against Google's own Workspace admin help in August 2026. A wrong TXT value here does not just fail — it can quietly break mail you thought was working, so copy the exact strings.

The short answer, record by record#

You are publishing three DNS records. SPF and DMARC are TXT records you add at your domain host by hand. DKIM is a key pair Google generates for you in the Admin console — you copy the record it hands you into your DNS, then click a button in the console to switch signing on.

The table below is the whole job at a glance. Do them in order: SPF and DKIM first, then DMARC last, because a DMARC record with nothing to check under it does no good.

Before you start#

Gather a few things first so you are not hunting for access mid-task. Authentication touches DNS and the Admin console, so you need to be able to reach both.

• Super administrator access to the Google Admin console — the DKIM controls under Authenticate email are admin-only.
• Sign-in access to your domain's DNS host (where you registered the domain, or wherever its nameservers point), because SPF, DKIM and DMARC all live there as TXT records.
• A list of every other service that sends mail as your domain — a marketing platform, a CRM, an invoicing tool. Each one has to be authorised, or its mail will fail once you turn DMARC on.
• Patience for propagation. Google says DNS changes and DKIM can take up to 48 hours to take effect, and it asks you to wait 48 hours after SPF and DKIM before you add DMARC.

Step 1: Publish your SPF record#

SPF tells receiving servers which systems are allowed to send mail for your domain. For a domain that sends only through Google Workspace, Google's recommended record is a single line.

1. 1

   Sign in to your DNS host

   Go to wherever you manage DNS for the domain — your registrar or DNS provider — and open the TXT record section. This is not done in the Google Admin console.

2. 2

   Add one TXT record at the root

   Create a TXT record with the host or name set to @ (the root domain) and the value v=spf1 include:_spf.google.com ~all. That include tells the world Google's servers are authorised to send as you.

3. 3

   Keep it to a single SPF record

   A domain must publish only one SPF record. If one already exists, edit it rather than adding a second — two v=spf1 records cause a permanent SPF failure. If you send through other services too, merge their include entries into this one line.

4. 4

   Save and allow time to propagate

   Save the record. Google notes changes can take up to 48 hours to activate, though many DNS hosts update in minutes. You can check the record has published with any public DNS lookup tool.

Step 2: Turn on DKIM in the Google Admin console#

DKIM adds a cryptographic signature to every message so a receiver can confirm it really came from your domain and was not altered in transit. Unlike SPF, the key is generated for you inside Google, then published to DNS.

1. 1

   Open the email authentication settings

   In the Google Admin console, go to Menu, then Apps, then Google Workspace, then Gmail, and click Authenticate email. You must be signed in as a super administrator.

2. 2

   Select the domain and generate a key

   Choose your domain from the Selected domain menu, then click Generate new record. Choose 2048-bit if your DNS host supports it (Google's recommendation), or 1024-bit if it does not. Leave the default prefix selector, google, in place and click Generate.

3. 3

   Publish the record it gives you

   The console shows a DNS Host name — normally google._domainkey — and a long TXT value that begins v=DKIM1;. Copy both into a new TXT record at your DNS host exactly as shown.

4. 4

   Return and start authentication

   Once the record has propagated, go back to Authenticate email and click Start authentication. Google says DKIM can take up to 48 hours to begin signing, and the console may keep showing a 'not authenticating' notice during that window.

Step 3: Add your first DMARC record#

DMARC ties SPF and DKIM together: it tells receivers what to do with mail that fails authentication, and asks them to send you reports. Google requires SPF and/or DKIM to be working first, and asks you to wait 48 hours after setting them up before you publish DMARC.

1. 1

   Confirm SPF and DKIM are live

   Check that SPF resolves and that the Admin console shows DKIM authenticating. Google states that without SPF and/or DKIM in place, adding DMARC will likely cause delivery issues, so do not skip this.

2. 2

   Add a TXT record at _dmarc

   At your DNS host, create a TXT record with the host or name set to _dmarc and the value v=DMARC1; p=none; rua=mailto:[email protected]. Replace the address with a real mailbox you can read.

3. 3

   Start at p=none and read the reports

   p=none is monitor-only: it enforces nothing but starts the aggregate reports flowing to your rua address. Watch them for a few weeks to confirm all your legitimate senders pass alignment before you tighten.

4. 4

   Tighten to quarantine, then reject

   Once your reports show only mail you actually send passing, move the policy to p=quarantine, and later p=reject, to actively block spoofed mail. Move one step at a time and keep watching the reports after each change.

How the records differ by your sending setup#

The values above assume mail leaves only through Google Workspace. The moment another service sends as your domain — a newsletter platform, a support tool, a billing system — the records change. SPF gains an include for each sender, and each sender needs its own DKIM signature aligned to your domain.

Get the exact include string from each sender's own documentation — do not guess it, because a wrong include silently breaks that sender's SPF. The 10-lookup limit is a hard SPF rule: cross it and the whole record returns a permanent error, so consolidate includes rather than chaining them.

What to do when it doesn't work#

Most setup failures come down to a record that has not propagated, a value that was pasted wrong, or a sender you forgot to authorise. Read the specific symptom rather than assuming the worst — the fix is usually small.

The most common trap is alignment: a message can pass SPF or DKIM and still fail DMARC if the passing domain does not match your visible From address. When in doubt, start from the DMARC aggregate reports — they name every source sending as you and show which check each one passes or fails.

A faster way to handle what lands after you authenticate#

Authentication is a one-time DNS job that protects your outbound mail's reputation — it is not something an email client sets up for you, and we would not pretend otherwise. If you want ongoing DMARC report parsing, that is the job of a dedicated DMARC monitoring service, which we are not.

What SPF, DKIM and DMARC do nothing about is the flood that reaches your own inbox once your domain is trusted. That is the continuous side of the problem, and it is the one we work on. AI Emaily connects to your Google Workspace mailbox and handles the inbound side — triaging what arrives, catching spoofed and phishing mail that slips past a receiver's own checks, and drafting replies you approve before they send. It touches your inbox, never your DNS. We build AI Emaily.