Authenticating Google Workspace (Gmail) Email Records

Why this matters

Google Workspace does not require you to publish SPF/DKIM DNS records during initial setup. Mail still flows through Google’s servers, but receivers may see SPF as softfail or neutral (your domain’s SPF does not authorize Google’s IPs) and DKIM may sign with Google’s default SMTP host instead of your domain. When SPF and DKIM don’t align with your From domain, DMARC can fail even when individual checks look “okay,” which hurts deliverability and reporting.

What a default setup often looks like

SPF may show as NEUTRAL or SOFTFAIL for Google’s IP. DKIM can still PASS while signing with a Google-hosted selector (e.g. *.gappssmtp.com) rather than your domain — that is alignment risk for DMARC. Below are example Gmail “Show original” snippets (your exact wording may vary slightly).

What you’re aiming for

After DNS and Admin Console setup, SPF should PASS for Google’s sending IP, and DKIM should PASS with your domain aligned to the From address. DMARC can then PASS when policy and alignment are satisfied. You’ll confirm the same way — with a new send and full headers.

In your DNS provider, open the TXT record(s) for your root domain (or the subdomain you use in the envelope, if you send from a subdomain). Look for an existing SPF record starting with v=spf1. Note every include and mechanism — you can only have one valid SPF TXT per DNS name; multiple SPFs must be merged into a single record. If there is no SPF yet, you’ll add one. If another system already sends mail (e.g. ESP, marketing tool), you must combine their includes with Google’s in one string.

Publish (or edit) a single TXT record for the appropriate hostname. Google’s documented sender SPF include is include:_spf.google.com. A common baseline is: v=spf1 include:_spf.google.com ~all (use -all only if you are sure no other senders use this domain). Save the record, wait for DNS propagation (often minutes, sometimes hours), then re-check with your DNS tool or a public SPF lookup. Avoid duplicate SPF TXT records on the same name.

Before generating keys in Admin, search DNS for TXT records that look like Google DKIM selectors: selector._domainkey.yourdomain.com. If you find old or unused selectors, document them so you don’t duplicate conflicting policies. If nothing exists yet, you’ll add the new selector Google gives you in the next steps.

In admin.google.com, go to Apps → Google Workspace → Gmail → Authenticate email (wording may vary slightly by version). Select your domain, start authentication for DKIM, and generate a new record. Google will show a DNS record: typically a TXT name like google._domainkey (or the selector they assign) and a long public key value. Keep this page open until the record is live.

At your DNS host, create a TXT record exactly as Google specifies (hostname and value). TTL can stay at your provider default or 300–3600 seconds. Do not truncate the key. If your host splits long TXT values into multiple strings, that is usually fine — follow their UI for long records. Save and wait for propagation.

Return to Gmail → Authenticate email in Admin. Use the console’s verification/validation control to confirm Google can see the DKIM record and that authentication is active. Resolve any errors (wrong host, typo in key, record on wrong domain) before moving on.

Send a new message from a user on your domain to an inbox where you can view full headers. In Gmail: open the message → More (three dots) → Show original. Confirm SPF passes with Google’s IP and DKIM passes with your domain (aligned with From), and that DMARC aligns with your policy. If anything still fails, recheck DNS propagation and that only one SPF exists and DKIM matches exactly what Admin generated.