DKIM, SPF and DMARC for Google Workspace: the complete setup

Turn on DKIM in the Google Admin console, publish the right SPF and DMARC records, check that mail really passes, and avoid the usual errors.

6 min read

A new Google Workspace domain sends mail that is not signed in your name. Until you turn DKIM on, Google signs with a domain of its own, and DMARC cannot rely on that signature. The setup takes fifteen minutes of work and up to two days of waiting. This guide follows Google’s own procedure, read on its help pages on 14 November 2026.

Before you start

You need a super administrator account, and access to the DNS of your domain. One thing surprises people: after Gmail is turned on for a new organisation, Google asks you to wait 24 to 72 hours before a DKIM key can be generated. Trying earlier gives an error saying the record was not created.

1. SPF

Publish one TXT record on the domain itself:

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

If other services send mail in your name (a newsletter tool, an invoicing tool), their include: goes in the same record: a domain must have one SPF record only. The free SPF record generator builds it and counts the DNS lookups, limited to ten.

2. Generate the DKIM key

In the Google Admin console, open Menu → Apps → Google Workspace → Gmail, then Authenticate email. Choose the domain in Selected domain and press Generate New Record.

  • Key length: choose 2048 if your DNS provider accepts it, 1024 otherwise. Google requires at least 1024 bits to deliver to personal Gmail accounts and recommends 2048.
  • Prefix selector: keep google unless a key with that name already exists on the domain.

The console shows a host name, google._domainkey, and a value that starts with v=DKIM1; k=rsa; p=.

3. Publish the key

Create a TXT record at your DNS provider with that host name and that value. A 2048-bit key is longer than 255 characters, the limit of a single TXT string: most providers split it for you, a few truncate it. If the key is cut, signatures fail. The DKIM record checker reads the published key and tells you its length.

Each domain and each alias domain needs its own key.

4. Start signing

Go back to Authenticate email and press Start authentication. It can take up to 48 hours after the DNS change. When it works, the status reads Authenticating email with DKIM.

Until you press that button, nothing is signed with your domain, even if the record is published. This is the most common oversight.

5. Check a real message

Send a message to a Gmail address that is not yours (a test to yourself proves nothing), open it, choose Show original, and look for dkim=pass with your domain in the Authentication-Results header. Or paste the headers into the e-mail header analyzer.

6. DMARC

Start by watching:

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.example"

Google asks bulk senders, those sending more than 5,000 messages a day to Gmail accounts, to have SPF, DKIM and DMARC; every sender needs SPF or DKIM. A policy of p=none satisfies the requirement but stops no forgery: read the reports for two weeks, then follow From p=none to p=reject.

What goes wrong

  • “Not authenticating” in the console: the record is published but Start authentication was never pressed, or the DNS change has not spread yet.
  • A truncated key: the provider cut the value at 255 characters. Publish it as several quoted strings, or use a 1024-bit key.
  • DKIM passes, DMARC fails: the message was sent by another service using your address. Each service must sign with your domain: see SPF, DKIM and DMARC explained.

Once the records are in place, the full e-mail authentication check reads all three at once.