SPF and DKIM by provider

SPF record for Google Workspace

Last updated 2026-08-26

Google Workspace sends mail for your users, plus anything relayed through its SMTP relay. Here is what to publish so it can do that as your domain, and what has to line up before DMARC will pass.

The SPF record

Add one mechanism to the SPF record on your sending domain:

In a complete record, alongside Google Workspace, that looks like:

This is the only Google include you need. When I last checked on 2026-08-20, _spf.google.com was flat, with only ip4: and ip6: terms, so the include cost one of your ten DNS lookups. Google can change the terms inside it without notice, so run the checker for the live number.

If you still have include:aspmx.googlemail.com in there from an older setup, delete it. It is a legacy alias and it is spending lookups you need.

Then count your lookups. SPF allows ten DNS-querying mechanisms across the entire nested chain, and the eleventh turns the record into a permerror that authorises nothing. The record still reads correctly to a human while every check fails. Run the domain through the SPF checker after every change, because the number moves when your providers change their own records, not just when you change yours.

DKIM

Generate the key in the Admin console under Apps, Google Workspace, Gmail, Authenticate email. Choose 2048-bit, publish the TXT record it gives you at google._domainkey.example.com, then come back and press Start authentication.

That last step is the one people miss. The key can sit correctly in DNS for months while Google signs nothing, because generating the key and turning on signing are two separate buttons.

DMARC alignment with Google Workspace

DMARC passes when SPF or DKIM passes and the domain it authenticated matches the domain in your visible From address. A provider can pass both checks for its own domain and leave you failing. These are the Google Workspace specifics:

• Mail your users send aligns on both SPF and DKIM out of the box, because the envelope sender is your domain and the signature uses it too. Google Workspace is the easy case.
• The SMTP relay service is not. An application relaying through Google needs its From domain registered in the relay settings, and mail from an unregistered domain either gets rejected or goes out unaligned.
• Aliases and secondary domains each need their own DKIM key. One key on the primary domain does not cover the others.
• Routing rules that modify outbound content run after signing in some configurations, which produces a body hash failure at the receiver.

The general case is covered in alignment, explained, and the header you read to prove it is on the dmarc=fail page.

Verify it

Substitute your domain, and run these after the TTL on anything you replaced has expired:

Then send one message through Google Workspace to a Gmail address you control, open Show original, and look for dkim=pass with your domain in header.i. That single check is worth more than any number of DNS lookups, because it tests the thing receivers actually do.

Our SPF checker gives you the lookup count, the DKIM checker confirms a selector resolves and the key is long enough, and the DMARC checker reads your policy back to you. All three are free and none of them ask for an account.

Values here were checked against Google Workspace's own documentation, at Google Workspace admin help. Providers change DNS requirements without much announcement, so if their screen disagrees with this page, believe their screen and tell us.

A record can read correctly and still fail alignment once real mail moves through it. Receivers write that verdict into the reports they send. We read them for you, and paid plans email you the same day one names a new sender that failed, instead of holding it for Monday. See whether this sender passes. Your first domain is free.