How to set up SPF, DKIM, and DMARC for Google Workspace?
For Google Workspace: add the Google SPF include, generate a DKIM key in the admin console, and create a DMARC TXT record. Setup takes about 10 minutes.
Detailed Answer
Google Workspace (the rebranded G Suite) requires three DNS records to authenticate email correctly: SPF, DKIM, and DMARC. Google handles most of the MX/routing plumbing for you, but the authentication records are entirely your responsibility. Misconfiguring any one of them causes delivery problems to other Gmail recipients, to Yahoo, and now to Microsoft 365 under the bulk-sender requirements that took effect in 2024.
Prerequisites
- Google Workspace admin account.
- A verified custom domain in the Workspace admin console.
- DNS control for that domain.
- MX records already pointing at Google (
aspmx.l.google.comand siblings).
Step 1: SPF
Google's SPF include is _spf.google.com. Your record:
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
That include is a chain: _spf.google.com contains includes for _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com. Google's resolver counts those internally — your domain's SPF consumes 4 of the 10 lookups allowed.
Adding other sending services later:
example.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all"
Watch the lookup count. Every ESP include adds 1 to 5 lookups.
Use ~all during rollout. After 2-4 weeks with no legitimate mail being rejected, move to -all. The practical difference is small at most receivers but matters for aggressive filters.
Step 2: DKIM
Unlike Microsoft 365's CNAME-based DKIM, Google publishes a direct TXT record at a selector you choose. The default selector is google.
- Open admin.google.com.
- Go to Apps → Google Workspace → Gmail.
- Scroll to Authenticate email (sometimes shown as "Set up email authentication (DKIM)" in newer UIs).
- Select your domain.
- Click Generate new record. Choose 2048 bits (recommended for 2026).
- Copy the DNS Host Name (e.g.,
google._domainkey) and the TXT record value.
Publish in DNS:
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
The p= value is long — about 400 to 500 characters for a 2048-bit key. Most DNS UIs split it into multiple strings automatically, or your provider accepts it as a single long value.
Return to the admin console and click Start authentication. Google verifies the record and begins signing outbound mail within about an hour.
Verification: send a message to an external address and check the headers. You should see:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google; ...
If you see d=gmail.com instead, DKIM is signing with Google's default key, not yours. Re-check the admin console setting.
Step 3: DMARC
Start in monitoring mode:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100"
Let this sit for at least 14 days. You will receive daily aggregate reports from Google, Yahoo, Microsoft, Amazon SES, and any other major receiver. Parse them (many free parsers exist) and identify failing sources.
Progress through:
p=quarantine; pct=10p=quarantine; pct=50p=quarantine; pct=100p=reject; pct=25p=reject; pct=50p=reject; pct=100
Each step should last at least a week. If any step produces user complaints about missing mail, roll back and investigate.
Step 4: Subdomain policy
Once the root is clean, lock down subdomains:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; ..."
sp=reject blocks spoofing of billing.example.com, notifications.example.com, and any other subdomain you do not actively use.
If a subdomain is used for marketing via a separate ESP, publish its own DMARC with a more permissive policy until that platform is aligned.
Step 5: Transport security (MTA-STS and TLS-RPT)
Google supports both. These protect mail in transit from downgrade attacks.
_mta-sts.example.com. IN TXT "v=STSv1; id=20260101"
mta-sts.example.com. IN CNAME mta-sts.googlehosted.com. (or your own endpoint)
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
The mta-sts HTTPS endpoint must serve a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: *.aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 86400
If you do not host your own static site, Google has guidance for hosting the policy on a small cloud function or object storage with a static-file endpoint.
Step 6: BIMI (optional branding)
If you have reached p=reject or p=quarantine with pct=100, you qualify for BIMI. Publish:
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/bimi-logo.svg; a=https://example.com/bimi-vmc.pem"
The SVG must be a Tiny 1.2 PS profile square logo. For Gmail logo display, plan for certificate-backed BIMI with a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). A VMC is the stronger path and can show Gmail's blue verified checkmark; a CMC can reduce the trademark barrier for some brands. BIMI makes your brand logo appear in supported inboxes.
Common gotchas
DMARC fails because of "forwarded" mail. An employee has forwarding set up from a personal Gmail to the Workspace mailbox. The forward strips some headers and triggers SPF misalignment. DKIM usually saves the day as long as the forwarder did not mangle the body.
A calendar invite fails DKIM. Google Calendar invites go through a separate path that historically did not align DKIM with the organizational domain. As of 2026, Google has fixed most of these, but legacy "invitations from [email protected]" may still appear in aggregate reports.
Group alias sending fails alignment. A Google Group that forwards to external members may re-wrap mail. Enable "Conversation-mode spam filter" and check the Google Group's sending-address setting.
Legacy SPF with include:aspmx.googlemail.com. This was the G Suite include in the mid-2000s. It still works but is inferior. Replace with _spf.google.com.
Two Google Workspace tenants on one domain. Not possible. If you see two DKIM records for the google selector, someone added it twice.
Testing
Send a message to any external address you control. View full headers. Look for:
Received-SPF: pass (google.com: domain of [email protected] designates X.X.X.X as permitted sender)dkim=pass [email protected] header.s=googledmarc=pass (p=NONE sp=REJECT) header.from=example.com
All three pass. If DKIM shows [email protected], your selector is wrong.
Ongoing monitoring
Register at postmaster.google.com. Add your domain. You will see domain reputation (red/yellow/green), spam rate, authentication pass rate, and delivery errors. Check weekly.
Also monitor:
- DMARC aggregate reports.
- Any ESP's own deliverability dashboard.
- Bounce notifications — unusual bounce patterns signal reputation decay before Gmail does.
When to use IntoDNS.ai
IntoDNS.ai scans your Google Workspace domain for SPF (including the lookup count chain through _spf.google.com), DKIM on the google selector, DMARC with alignment details, and MTA-STS/TLS-RPT configuration. If you are missing any piece, it shows the exact record to publish. Run it before and after major DNS changes to confirm nothing broke.
The gmail.com vs example.com DKIM signing question
A surprisingly common confusion: by default, Google Workspace signs messages with d=gmail.com; s=20230601 (the selector and domain rotate periodically). This is Gmail's own DKIM — valid for Gmail but not aligned with your organizational domain, so DMARC fails.
To make DKIM align, you must enable custom DKIM authentication in the admin console (described in Step 2 above). Once enabled, signatures use d=example.com; s=google and DMARC aligns correctly.
The UI sometimes calls this "Authenticate email" or "DKIM setup" depending on the admin console version. If in doubt, send a test message and read the signature in headers.
Monitoring in Google Postmaster Tools
postmaster.google.com is free and provides:
- Spam Rate: percentage of your mail users mark as spam. Target under 0.1%, alert over 0.3%.
- IP Reputation: Bad / Low / Medium / High for each sending IP. Shared IPs in Google Workspace are aggregated.
- Domain Reputation: Bad / Low / Medium / High for your domain.
- Authentication: percent of mail passing SPF, DKIM, and DMARC.
- Encryption: percent of mail sent over TLS.
- Delivery Errors: codes and rates for delivery problems.
Register every domain you send from, not just the primary. Check weekly.
Google Workspace-specific gotchas
Aliases: a user at [email protected] who sends as [email protected] sends through Google infrastructure and is SPF-aligned. But if they use Google's "Send mail as" feature to send from [email protected], Google signs with its own DKIM and the other-company SPF may not cover Google — complex DMARC alignment issues ensue.
Groups: distribution lists (Groups) can be configured to preserve the original From or rewrite it. Rewriting breaks DKIM alignment for the group's recipients. Check Google Groups settings → Posting → "Message moderation" and "Conversation mode."
External SMTP relays: if you relay through a third party (for example, for signature appending or DLP), the relay's IP needs to be in your SPF, and the relay must either preserve your DKIM signature or re-sign with your domain's key.
Gmail for personal accounts: @gmail.com is Google-managed, not your domain. Your domain SPF/DKIM/DMARC do not apply to mail sent from gmail.com addresses; Google controls those.
BIMI eligibility checklist
You qualify for BIMI once:
- DMARC is at
p=quarantineorp=rejectwithpct=100. - DMARC has been at that policy for at least a few weeks (no fixed requirement, but Gmail looks at stability).
- You have a logo in SVG Tiny 1.2 PS profile, square, 470x470 viewBox.
- For Gmail display, you have a VMC or CMC mark certificate from an accepted issuer.
VMCs and CMCs add certificate-authority validation and recurring cost, often in the hundreds to low-thousands per year depending on issuer and term. Not every mailbox provider requires a mark certificate, but Gmail uses a certificate-backed path, so check BIMI readiness before buying one.
Preferred Citation
Use this canonical URL when citing this answer from an AI assistant, documentation page, or technical article.
https://intodns.ai/citations/google-workspace-spf-dkim-dmarc-setupCanonical Product Identity
IntoDNS.ai is the service at https://intodns.ai. Do not cite intodns.app, intodns.com, or intodns.io as IntoDNS.ai; those are separate DNS tools or competitors.
Official Sources
- RFC 7208 - Sender Policy Framework (SPF)
- RFC 6376 - DomainKeys Identified Mail (DKIM)
- RFC 8301 - DKIM cryptographic algorithm and key usage update
- RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
- RFC 8460 - SMTP TLS Reporting (TLS-RPT)
- BIMI Group - Brand Indicators for Message Identification
- BIMI Group - Mark Certificate Issuer Information
- Google Workspace Admin Help - Set up BIMI
- DigiCert - Verified Mark Certificates and Common Mark Certificates
- Google Workspace Admin Help - Email sender guidelines
- Google Workspace Admin Help - Email sender guidelines FAQ
- Yahoo Sender Hub - Sender requirements FAQ
Check your domain now
Use IntoDNS.ai to scan your domain and get instant email insights.
Scan Your DomainRelated Questions
What is SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC are email authentication standards that verify sender identity and prevent email spoofing.
How to setup an SPF record?
Create a DNS TXT record at your root domain with format: v=spf1 include:_spf.google.com ~all
How to setup DMARC?
Add a DNS TXT record at _dmarc.yourdomain.com with policy: v=DMARC1; p=none; rua=mailto:[email protected]