SPF, DKIM and DMARC Setup for Google Workspace

If your business email runs on Google Workspace, three DNS records help other mail servers check that a message really comes from you: SPF, DKIM and DMARC. This guide is for owners and whoever looks after their domain. It walks through all three in the right order, with the exact records to publish and the checks to run.

For background on what each record does, see SPF, DKIM and DMARC explained. This article is the hands-on version.

In short: Publish one SPF record, switch on DKIM signing in the Admin console, then add a DMARC record set to p=none and read the reports. Move to quarantine and then reject only once every legitimate sender passes with alignment. Correct records make your domain harder to impersonate. They do not control inbox placement, and receivers make the final decision.

Before you start

You need three things:

• Admin access to Google Workspace (admin.google.com).
• DNS access for your domain, usually at your registrar or host.
• A list of every service that sends email as your domain. Think of the website contact form, invoicing tool, CRM, newsletter platform, help desk and booking system. Include occasional senders such as annual statements.

Save a copy of your current DNS records before editing, so you can roll back. DNS changes can take a while to show up everywhere, because of caching, so allow time before concluding something is broken.

Why alignment matters

DMARC passes when SPF or DKIM passes and the domain it authenticated matches the visible From address (this match is called alignment). One aligned pass is enough.

• SPF checks the hidden envelope sender (the Return-Path), not the From address people see.
• DKIM checks a signature made by a domain named in the signature (d=).

That is why a third-party tool can pass its own checks yet fail DMARC for your domain: it signed or sent as its domain. The usual fix is to set up domain authentication inside that tool, so it signs as yours.

Step 1: Set up SPF

SPF is a TXT record listing which servers may send mail for your domain.

Check what you have

Run this in a terminal (or use any online SPF lookup):

nslookup -type=txt yourbusiness.com

Look for a TXT record starting v=spf1. You must have exactly one at that name. Two SPF records cause a permerror and SPF fails (RFC 7208). Other TXT records are fine.

The record if Google is your only sender

Create one TXT record on the root domain (@):

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

include:_spf.google.com authorises Google's servers. ~all is a soft fail for anything else, a sensible starting point while DMARC reports reveal forgotten senders.

Adding other senders

For each extra service, either add the provider's include: to your single SPF record, or set up DKIM for your domain inside that provider so it passes DMARC through DKIM. The second route keeps SPF short. Follow each provider's current instructions, then send a test.

The 10-lookup limit

SPF allows at most 10 DNS-querying terms, counting those inside nested include: entries. Go over and you get a permerror. Use an SPF checker that follows nested lookups instead of counting by eye. If you are close, remove services you no longer use. Be careful with "SPF flattening" tools, since a flattened record goes stale if a provider changes its servers.

Step 2: Turn on DKIM

DKIM adds a cryptographic signature to each message. Receivers fetch your public key from DNS and verify it. Google generates the key, but signing may not be active until you start it, so check your status rather than assuming.

Generate the key

1. In the Admin console go to Apps → Google Workspace → Gmail → Authenticate email.
2. Choose your domain at the top.
3. Click Generate new record.
4. Pick a 2048-bit key if your DNS provider accepts long TXT values. Keep the default selector prefix, google, unless another system already uses it.
5. Click Generate.

Google shows a hostname (typically google._domainkey) and a long TXT value starting v=DKIM1; k=rsa; p=....

If you have only just turned on Gmail for the domain and Generate new record is unavailable, Google says the key may not be ready for 24 to 72 hours. Wait and try again.

Publish it

Add a TXT record in your DNS panel:

• Name: google._domainkey (most panels add the domain for you; if yours wants the full name, use google._domainkey.yourbusiness.com).
• Value: the entire string from Google. Some panels split long values into several quoted pieces, which is fine as long as it joins back to the exact original.

Watch out: a very common mistake is a doubled domain, such as google._domainkey.yourbusiness.com.yourbusiness.com. If DKIM will not validate, look here first.

Start signing and test

Return to Authenticate email and click Start authentication. If it fails, check the hostname, the full value and whether the record has propagated yet.

Then send a message to a different Gmail or Google Workspace address, not your own, because Google notes you cannot verify the setup by emailing yourself. Open the message, choose the three-dot menu and Show original. You should see PASS beside DKIM and SPF, and beside DMARC once Step 3 is done.

Step 3: Add DMARC

DMARC tells receivers what to do when a message using your domain in the From address fails to produce an aligned SPF or DKIM pass. It also sends you aggregate reports showing who is sending as your domain. The current specification is RFC 9989, which supersedes the older RFC 7489 that many guides still cite.

Google recommends allowing about 48 hours after setting up SPF and DKIM before adding DMARC, so authentication has time to take effect.

Decide where reports go first. They are XML files from many receivers, so most people send them to a DMARC reporting service that makes them readable. If the report address is on a different domain, that domain may need to publish an authorisation record, so check your provider's documentation.

Stage 1: monitor

Add a TXT record named _dmarc:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com

p=none asks receivers to take no action; rua is the report address. Not every receiver sends reports, and they arrive on the receiver's own schedule.

Leave it long enough to cover a full sending cycle, such as monthly invoices and newsletters. Reports list sending IP addresses, counts and results, not business names, so match the IPs to your sender list. Fix any legitimate sender that fails alignment before tightening.

Stage 2: quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourbusiness.com

Older guides, and Google's own, mention an optional pct tag to apply the policy to only a share of failing mail. Newer DMARC specifications have dropped it, and some receivers may ignore it, so do not rely on it. Your protection is the Stage 1 groundwork: move to quarantine only when reports show that legitimate mail passes, then keep reading reports afterwards.

Stage 3: reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourbusiness.com

Move here only after clean reports under quarantine. Forwarding and some mailing lists can break SPF, and sometimes DKIM, for legitimate mail, so investigate those flows first.

Tip: do not set a calendar for these stages. Move when your reports say you are ready, not when a week has passed.

Common problems and fixes

For website contact forms, send from an authenticated address on your domain and put the visitor's email in Reply-To. Either route mail through Google Workspace SMTP using a dedicated account, or set up DKIM in whichever service the form uses. Never put SMTP passwords or API keys in browser-side code.

Check your own setup

After publishing, run your domain through the free DMARC & SPF checker at lordevo.com/tools. For the website side of your security, the free Safe Scan runs passive checks on a public URL, and the security headers guide covers a useful next step. When you are ready to enforce, moving from p=none to p=reject goes deeper on reading reports.

Key takeaways

• Keep exactly one SPF record, and stay within 10 lookups.
• Use include:_spf.google.com for Google, with ~all to start.
• Generate a 2048-bit DKIM key, publish it exactly, then click Start authentication.
• Test from a different address, not your own.
• Start DMARC at p=none with an rua address you actually read.
• Fix alignment for every third-party sender before enforcing.
• Review your sender list whenever you add a new tool.

FAQ

Do I need all three records?

DMARC needs at least one of SPF or DKIM to pass with alignment, so strictly one is enough to get a pass. Setting up both is best practice, because forwarding often breaks SPF while DKIM can survive it. Google says to turn on SPF and/or DKIM before adding DMARC.

Will these records stop all spoofing?

No. They make exact-domain impersonation harder and help receivers decide what to do with it. They do not stop look-alike domains or compromised accounts.

Can I go straight to p=reject?

You can, but you risk blocking your own legitimate mail from tools you forgot. Monitoring first shows you what is actually sending.

How long do changes take to appear?

It depends on your DNS provider and cached values. If a check fails right after a change, wait and test again, ideally from a different network.