Google Workspace DMARC and DKIM Setup Guide
To set up DMARC on Google Workspace: enable DKIM in Admin Console under Apps > Gmail > Authenticate email, add the generated TXT record to DNS at google._domainkey.yourdomain.com, add include:_spf.google.com to your SPF record, and create a DMARC record at _dmarc.yourdomain.com starting with p=none and an rua= address to collect reports. Google generates the DKIM key for you; your job is to copy it into DNS and let alignment do the rest.
If you're starting from scratch with email authentication, see DMARC for indie developers for an overview of how SPF, DKIM, and DMARC work together, or the broader email setup guide for a new SaaS for the full picture. On Microsoft 365 instead? Follow the Microsoft 365 DMARC setup guide for that provider's specifics.
Step 1: Enable DKIM in Google Admin Console
DKIM is off by default in Workspace. Enabling it generates a public key that lives in Google's DNS servers.
In Google Admin Console:
- Go to Apps → Google Workspace → Gmail → Authenticate email.
- You'll see your domain listed. Click Generate new record if you haven't done this before.
- Google generates a DKIM key and displays it in one of two formats: a simple record starting with
v=DKIM1or a multi-line format. Copy the full value. - The DNS selector is almost always
google, so your DNS record goes atgoogle._domainkey.yourdomain.com.
Google sometimes uses different selectors if you have multiple Workspace instances or if you've previously set up DKIM and rotated keys. Check the exact selector shown in your Admin Console; it will be part of the record description.
Once you've copied the key, enable DKIM for the domain by toggling the switch in the Admin Console if it's not already on.
Step 2: Add the DKIM record to DNS
Add the DKIM record as a TXT record at google._domainkey.yourdomain.com with the value Google provided.
It typically looks like:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
This is a long single line. DNS will handle wrapping it if needed.
Allow 24–48 hours for DNS propagation, though most providers serve it immediately. After that, you can verify it's live using the email auth checker.
Step 3: Configure SPF
Google Workspace adds its own sending infrastructure, so you need to include Google's SPF mechanism.
Your SPF record should include:
v=spf1 include:_spf.google.com ~all
If you have other sending sources (a transactional ESP like Resend, SendGrid, or Mailchimp), add their SPF includes as well:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Important: SPF uses DNS lookups, and there's a hard limit of 10 include mechanisms per record. If you exceed this, mail delivery fails for everyone. If you're juggling multiple senders, you may need to flatten your SPF. See SPF flattening guide if you hit that limit.
The ~all at the end is a soft fail: messages that don't pass SPF are still delivered, but marked as soft-failed. Many developers stay here for safety. If you're confident in your sender list, you can move to -all (hard fail), but be careful: a misconfigured sender will bounce.
Step 4: Understand SPF alignment and multiple senders
If you send from Workspace and also use a transactional ESP (like Resend for transactional emails and Workspace for team communications), both senders need to be in your SPF record. But here's the catch: they may not align with your DMARC policy.
SPF alignment requires two conditions:
- The sending server's SPF record includes your domain.
- The message's
From:address domain matches your domain (or your domain is the organizational domain).
If your ESP sends from noreply@mail.sendgrid.net but the From: header shows noreply@yourdomain.com, SPF doesn't align, even though both are listed in your SPF record. You'd need DKIM alignment instead.
This is why DKIM is crucial: Google Workspace signs with your domain's key, so if the From: header is yourdomain.com, DKIM will align. Transactional ESPs may also sign with your domain if you've set up sender authentication.
Step 5: Create your DMARC record
DMARC is your enforcement policy. It tells receiving servers what to do with mail that fails authentication, and it's where you point rua= to collect aggregate reports.
Create a TXT record at _dmarc.yourdomain.com. Use the DMARC Record Checker to verify it's live once you've added it:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
Start with p=none (monitor only). This tells receiving servers to pass mail even if it fails DMARC, but still send you reports about what's happening. You'll live here for a few weeks while you understand your sending patterns and fix any alignment issues.
Replace reports@yourdomain.com with an address you check regularly, or better yet, point it at dmarcdrift:
v=DMARC1; p=none; rua=mailto:d-{domain_id}@in.dmarcdrift.com
(You'll get the domain ID from DMARCdrift once you sign up and add your domain.)
Step 6: Verify alignment
Once DKIM, SPF, and DMARC are live, verify alignment using the email auth checker. It will check:
- DKIM signature validity
- SPF record syntax and mechanisms
- DMARC policy syntax
- Whether your domain aligns under the DMARC policy
The checker also confirms that aggregate reports would be accepted at your rua= address.
If DKIM or SPF fails, check:
- DKIM: Is the selector correct? Google might use something other than
googleif you've rotated keys. Check Admin Console again. - SPF: Do you have more than 10 include mechanisms? If so, you need flattening.
- DMARC: Is the TXT record at exactly
_dmarc.yourdomain.com? A typo will break the whole policy.
Step 7: Monitor and gradually enforce
For the first 1–2 weeks, send mail as usual and let reports arrive at your rua= address. Look for:
- Messages from your Workspace domain that are aligning (both DKIM and SPF)
- Any legitimate senders that are failing (transactional ESPs, forwarding services, shared mailboxes)
- Legitimate failures you can't fix (e.g., forwarded email often breaks SPF due to the extra hop, but DKIM usually survives)
Once you're confident that all your regular senders align, or you've fixed the ones that don't, move to p=quarantine:
v=DMARC1; p=quarantine; rua=mailto:d-{domain_id}@in.dmarcdrift.com
This quarantines failing mail (sends it to spam). Still keep monitoring; watch the reports to catch surprises. After another week with no legitimate bounces, move to p=reject:
v=DMARC1; p=reject; rua=mailto:d-{domain_id}@in.dmarcdrift.com
This rejects failing mail outright. This is the strongest policy and where you want to be long-term.
FAQ
Each domain gets its own DKIM configuration in Admin Console and its own DMARC record. Set them up one at a time. The process is the same for each.
Google usually sets it to google, but if you're rotating keys or have a legacy setup, check your Admin Console for the exact selector shown. Always use what Google displays.
It means DMARC will align if the sending domain or its parent aligns. For example, if your domain is mail.yourdomain.com and your organizational domain is yourdomain.com, alignment still works. Most indie developers don't need to worry about this; your organizational domain is your primary domain.
If you're pointing rua= to an external address (not your Workspace domain), that address must exist and must have a mailbox configured to receive mail. Some email providers reject mail to nonexistent addresses. DMARCdrift handles this automatically; reports route correctly as long as the domain ID in the address matches a domain you've added to dmarcdrift.
Once your DMARC record is live, aggregate reports will start arriving within 24–48 hours. DMARCdrift turns the XML into a readable digest and alerts you when something matters, free for one domain.