SPF, DKIM and DMARC for Google Workspace: The Complete Setup Guide

Three DNS records decide whether your mail reaches the inbox or disappears. They take about twenty minutes to publish and they are the single highest-return thing you can do for deliverability — yet most domains I audit have at least one of them missing, duplicated or quietly misconfigured.

This guide covers all three for Google Workspace: what each one does, the exact records to publish, how to confirm they work, and the specific mistakes that fail silently.

What each record actually does

SPF — who may send

Sender Policy Framework is a published list of the mail servers authorised to send on your domain’s behalf. A receiving server compares the sending IP against that list. If an unlisted server sends as you, SPF fails.

SPF has a notable weakness: it validates the envelope sender, not the From address a human reads, and it breaks when mail is forwarded. On its own it is not enough, which is why DKIM and DMARC exist.

DKIM — proof it is genuinely yours

DomainKeys Identified Mail attaches a cryptographic signature to every outgoing message. The private key lives with Google; the matching public key sits in your DNS. A receiver fetches the public key, checks the signature, and knows both that the message came from you and that nobody altered it in transit.

Unlike SPF, a DKIM signature survives forwarding. That makes it the more durable of the two.

DMARC — the policy and the reports

DMARC ties the other two together. It tells receivers what to do with mail that fails — nothing, quarantine, or reject — and, crucially, it asks them to send you reports on everything sent using your domain.

Those reports are the real prize. They show you every system sending as you, including the ones you have forgotten about, before you start enforcing anything.

Before you start: see what you already have

Never publish over the top of an existing configuration without reading it first. Check from the command line:

dig +short TXT yourdomain.com
dig +short TXT google._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX yourdomain.com

What you are looking for: exactly one line beginning v=spf1, a DKIM key at the selector Google is using, a v=DMARC1 record, and MX records pointing where you expect. If the first command returns two SPF lines, that alone is breaking your authentication right now.

MX records for Google Workspace

Worth confirming while you are in DNS. Google now uses a single MX record in place of the five it needed historically:

Older five-record setups using ASPMX.L.GOOGLE.COM and friends still work, so there is no urgency to change a configuration that is delivering. If you are setting up fresh, use the single record. Remove any MX pointing at your old host once the migration is finished — not before.

Setting up SPF

The record

For a domain where Google Workspace is the only sender:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com ~all

The one-record rule

A domain may publish exactly one SPF record. Two is not additive — it is invalid, and receivers fail the check rather than picking one. This is the most common SPF fault I find, and it usually happens when someone adds Google’s include as a new record instead of editing the existing one.

If you have other senders, merge them into a single record:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

The ten-lookup limit

SPF allows a maximum of ten DNS lookups while evaluating your record. Each include costs at least one, and some includes chain into several more. Exceed ten and the result is permerror — treated as a failure.

Three or four marketing tools is all it takes. If you are close to the limit, drop includes for services you no longer use and consider SPF flattening.

Should you use ~all or -all?

Start at ~all. With DMARC doing the enforcement, hardfail buys you very little extra and risks a lot.

Setting up DKIM

DKIM is the step most often skipped, because unlike SPF it is not enabled by default — you have to generate the key yourself.

1. Generate the key. In the Workspace admin console, go to Apps → Google Workspace → Gmail → Authenticate email, pick your domain, and generate a new record. Choose 2048-bit unless your DNS provider genuinely cannot handle it.
2. Copy the selector and the value. Google defaults to the selector google, which means the record goes at google._domainkey.yourdomain.com.
3. Publish the TXT record in your DNS, exactly as given.
4. Wait for propagation, then return to the console and click Start authentication. This is the step people miss — publishing the record is not enough; Google does not begin signing until you turn it on.

If your domain sends through other services as well, each needs its own DKIM key on its own selector. They coexist without conflict, which is the advantage DKIM has over SPF.

Setting up DMARC

Start at p=none, always

Your first DMARC record should enforce nothing:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r

This asks for reports without changing how anything is handled. Publishing p=reject on day one is the fastest way to destroy legitimate mail from a system you did not know existed — and because it is rejected rather than filed in junk, nobody discovers it until a customer asks why they never got their invoice.

Reading the reports

Within a day or two you will start receiving XML aggregate reports from major receivers. They are unpleasant to read raw; a free DMARC reporting service will parse them into something human.

What you are looking for: every source sending as your domain, and whether each passes SPF and DKIM. Expect surprises. Invoicing software, a CRM, a scheduling tool, an old contact form, a newsletter platform someone set up years ago.

Tightening safely

1. Weeks 1–2: p=none. Collect reports, identify every sender, authorise the legitimate ones.
2. Weeks 3–4: p=quarantine; pct=25. Apply to a quarter of failing mail and watch for complaints.
3. Week 5: raise to pct=100 if nothing has broken.
4. Week 6 onwards: p=reject, once you are confident every legitimate sender passes.

Alignment: relaxed or strict

adkim and aspf control how closely the authenticated domain must match your From address. Relaxed (r) permits subdomains; strict (s) demands an exact match. Relaxed is correct for almost everyone — strict alignment breaks the moment a legitimate service sends from a subdomain.

Verifying all three

Do not trust a checker that only reads your DNS. Test a real message.

1. Send a message from Workspace to an address on a different provider.
2. Open the original message there. In Gmail that is the three-dot menu → Show original.
3. You want to see SPF: PASS, DKIM: PASS and DMARC: PASS. Any other result means more work.
4. Repeat for every system that sends as your domain — your contact form, invoicing tool and CRM each authenticate independently of your mail client.

Mistakes that fail silently

Google and Yahoo’s sender requirements

Since 2024 both enforce minimum standards, and the bar is higher for bulk senders. In practice:

• Everyone should have SPF or DKIM at minimum, valid forward and reverse DNS, and TLS on connections.
• Bulk senders (roughly 5,000+ messages a day to Gmail) must have SPF and DKIM and DMARC, one-click unsubscribe on marketing mail, and must keep spam complaints below 0.3%.

Even well under those volumes, the three records are the difference between landing in the inbox and landing in junk. There is no reason to run without them.

Frequently asked questions

How long do the records take to work?

DNS changes propagate according to the record’s TTL — often within minutes, occasionally up to 48 hours. DKIM is the one to be patient with: wait for the record to resolve before clicking Start authentication, or the check will fail and you will need to retry.

Do I need all three, or will one do?

All three. SPF breaks on forwarding, DKIM says nothing about what to do with a failure, and DMARC is useless without the other two to evaluate. They are designed to work as a set.

Will this fix mail already going to spam?

It removes authentication as a cause, which is a large part of it. If you are sending from a shared cPanel server, IP reputation is likely the bigger factor — that one is covered in why cPanel email keeps going to spam.

What if I use a separate marketing platform?

Add its SPF include to your single record and publish its DKIM key on its own selector. Then confirm it appears as passing in your DMARC reports before you tighten the policy.

Can I set this up during a migration?

Yes, and you should — but keep both the old and new senders authorised in SPF until the move is finished, then remove the old one. The sequence is in the 45-mailbox migration walkthrough.