Lookproof Browse tools

DMARC, SPF and DKIM for Google Workspace

Updated 2026-11-06 ยท Published 2026-11-05

This guide is for a domain admin whose mail is sent by Google Workspace (Gmail with your own domain). The goal is a DMARC policy of p=reject for example.com, with all legitimate mail still passing. Background on each protocol is in SPF explained, DKIM explained and DMARC explained.

All values below come from Google's own Workspace admin help, as of November 2026.

What Google Workspace sends from

Your users send from addresses at your domain, so the header From is [email protected]. Google sends the mail from its own servers, which you authorise in SPF with Google's include.

Google's help pages do not state which domain Workspace puts in the envelope sender (Return-Path), and they do not state which d= domain Workspace uses to sign mail before you turn on DKIM for your own domain. Check both in a real message: open it in Gmail, choose More and then Show original, and read the Return-Path and DKIM-Signature headers. Google's DKIM page says that if the header has no DKIM line, "messages sent from your domain aren't signed with DKIM".

The key is published in DNS under your own domain (google._domainkey.example.com), so once you turn on DKIM, receivers verify the signature against example.com.

SPF

You do not change anything in the Admin console for SPF. You publish one TXT record at your DNS host. As of November 2026, Google documents this record for a domain that only sends through Workspace:

example.com TXT "v=spf1 include:_spf.google.com ~all"

The quotes mark the TXT string. Google notes that some DNS hosts require the quotes, so check your host's help. The host name is the domain itself (many DNS hosts want @). The record type is TXT. Google states: "Each domain must have its own SPF record", and subdomains that send mail need their own record too.

A domain can only have one SPF record. If another service sends mail for you, add its include to the same record. Here include:_spf.example.net stands for another service:

example.com TXT "v=spf1 include:_spf.google.com include:_spf.example.net ~all"

This record uses 2 DNS lookups itself, one per include. Each included record can contain further includes, and those count too. Google does not document a number of lookups for _spf.google.com. When we counted it with real DNS on 6 November 2026, it held only IP ranges, so it cost 1 lookup in total (the include itself) and nothing further. Google can change that record, so use the SPF lookup counter to count your own tree. The limit is 10 (RFC 7208). Google's troubleshooting page says the same: "The SPF specification allows for a maximum of 10 DNS lookups".

Google recommends ~all. That is fine on the way to p=reject: DMARC decides what happens to mail that fails, not the SPF qualifier. Google says SPF can take up to 48 hours to start working.

DKIM

DKIM needs a super administrator. As of November 2026, the documented steps are:

  1. In the Google Admin console, go to Menu, then Apps, then Google Workspace, then Gmail.
  2. Click Authenticate email.
  3. In the Selected domain menu, pick example.com.
  4. Click Generate New Record.
  5. Choose the key length: 2048 or 1024. Google says to select 2048 if your domain provider supports 2048-bit keys.
  6. Keep the prefix selector google (the default) unless your domain already has a DKIM key with that prefix.
  7. Click Generate, then copy the DNS host name and the TXT record value.
  8. Publish the TXT record at your DNS host.
  9. Back on the Authenticate email page, click Start authentication.

The record has this shape, with your own key after p=:

google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Google warns that after you turn on Gmail for your organisation, you must wait 24 to 72 hours before the Admin console can generate a key. Do not click Start authentication before the TXT record is published. Google says DKIM can take up to 48 hours to start working after you add the key. In that time the Authenticate email page may keep showing "You must update the DNS records for this domain"; Google says you can ignore it if the key is published correctly. When it works, the status reads "Authenticating email with DKIM".

Many DNS hosts limit a TXT string to 255 characters. Google says a 2048-bit key cannot be entered as one string under that limit, so split it into several quoted strings in the same record. If your host cannot do that, use a 1024-bit key. As of November 2026, Google's sender guidelines require at least 1024 bits for mail to personal Gmail accounts. Each domain needs its own key from the Admin console.

DMARC alignment

DMARC passes when SPF or DKIM passes and that check is aligned with the header From domain:

  • SPF alignment compares the RFC5321.MailFrom (Return-Path) domain with the From domain.
  • DKIM alignment compares the d= domain in the signature with the From domain.
  • Relaxed alignment (the default, aspf=r and adkim=r) accepts the same organisational domain. Strict alignment (s) needs an exact match.

Google's DMARC page states the rule: "To pass DMARC, a message must pass at least one of these checks". The two checks are SPF that passes and aligns, or DKIM that passes and aligns.

After you turn on DKIM, Workspace signs with your key under example.com, so DKIM aligns with a From address at example.com. Confirm d=example.com in the DKIM-Signature header of a test message (Show original). This is the check to rely on. Because Google does not document the Return-Path that Workspace uses, confirm SPF alignment in your DMARC reports rather than assuming it.

Google's example record uses adkim=s; aspf=s, but the same page says "Relaxed alignment typically provides sufficient spoofing protection" and that strict alignment can reject mail from your own subdomains. Start with relaxed.

Step by step to p=reject

  1. Publish SPF. As of November 2026, Google documents the include _spf.google.com. Publish one TXT record at example.com with v=spf1 include:_spf.google.com ~all, adding the includes of any other services that send as your domain. Keep the total under 10 DNS lookups and remove any second SPF record.
  2. Turn on DKIM. In the Admin console, go to Apps, Google Workspace, Gmail, Authenticate email, generate a 2048-bit key with the default selector google (as of November 2026), publish the TXT record at google._domainkey.example.com, and click Start authentication once DNS has it.
  3. Publish DMARC with p=none and rua. Google says to let SPF and DKIM work for at least 48 hours first. Then publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected]. Use a group or dedicated mailbox, because reports can be numerous. Gmail does not support the ruf tag for failure reports.
  4. Read reports and fix other senders. Google suggests at least a week at p=none. Find every source that sends as example.com: newsletters, CRM, invoicing, web forms. Give each one DKIM with your domain or an aligned envelope sender, or route it through Google's SMTP relay.
  5. Move to quarantine. When the reports show only legitimate mail passing, publish v=DMARC1; p=quarantine; rua=mailto:[email protected]. Failing mail is usually placed in spam (Gmail does this), so a sender you missed is still recoverable. Watch the reports for another period.
  6. Reject. When the reports stay clean at quarantine, publish v=DMARC1; p=reject; rua=mailto:[email protected] and keep reading reports, because new sending services appear over time.

Some receivers support a test flag: t=y in RFC 9989 (DMARCbis), which obsoletes RFC 7489, or pct in RFC 7489. Neither is a safety net. RFC 7489 says unknown tags must be ignored, so a receiver that implements only RFC 7489 can treat p=reject; t=y as a full reject, and receivers that follow RFC 9989 no longer use pct. Move from p=none to p=quarantine to p=reject and let the reports decide each step.

The final record:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Common mistakes

  • Two SPF records. Google says "each domain can have only one SPF record". Merge them into one. See multiple SPF records.

  • Too many lookups. Every service adds includes, and nested ones count. Over 10 lookups, SPF fails with a PermError. See too many SPF lookups.

  • Generated key, not started. The DKIM record is in DNS, but nobody clicked Start authentication, so the Admin console reports "Not authenticating", and mail is not signed with your domain's key.

  • Truncated 2048-bit key. The DNS host cut the key at 255 characters. Split it into quoted strings, as Google describes.

  • Staying at p=none. A p=none policy only reports; it protects nothing. See DMARC policy none.

  • No rua. Without reports you cannot see which senders fail. Google recommends you "always include" rua. See no DMARC reports.

  • Reports to another domain without permission. If the rua address is at a different domain, that domain must publish a TXT record, as Google's DMARC reports page explains. For reports about example.com sent to a mailbox at example.net, the record is:

    example.com._report._dmarc.example.net TXT "v=DMARC1;"

  • An outbound gateway that changes mail. Google warns that a gateway that adds a footer can break DKIM.

How to check it

Run the email security check on example.com. It reads SPF, DMARC and common DKIM selectors in one pass. Use the SPF lookup counter to see how many lookups _spf.google.com and your other includes cost together. In the DKIM selector finder, look for the selector google (the Workspace default as of November 2026), or the custom prefix you chose in the Admin console. Build each DMARC stage with the DMARC record generator.

Sources

Frequently asked questions

What is the SPF include for Google Workspace?

As of November 2026, Google documents include:_spf.google.com. If Google Workspace is your only sender, Google gives the full record as v=spf1 include:_spf.google.com ~all. Put it in the one TXT record at your domain; do not publish a second SPF record.

What DKIM selector does Google Workspace use?

As of November 2026, the default prefix selector is google, so the TXT record name is google._domainkey. You can enter a different prefix in the Admin console if google is already used by another key on your domain.

Should I pick a 1024-bit or a 2048-bit DKIM key?

Google offers both and recommends 2048 if your DNS host supports it. Pick 1024 only if your DNS host cannot store the longer key. A 2048-bit key does not fit in one 255-character string, so split it into several quoted strings in the same TXT record.

Google's DMARC pages use pct. Should I?

No. Google's rollout page still shows pct from RFC 7489, and RFC 9989 (DMARCbis) removed it. Its replacement t=y is no safety net either: a receiver that implements only RFC 7489 ignores unknown tags and can apply the full policy. Step from p=none to p=quarantine to p=reject instead. See DMARC testing mode.