Google Workspace & Microsoft 365 SPF, DKIM, and DMARC Setup and Troubleshooting

Nearly every business domain runs its primary corporate email on either Google Workspace or Microsoft 365 (Exchange Online)—and during mergers, migrations, or departmental split setups, many organizations temporarily run both.

While both suites automatically sign outbound mail with a default provider domain out of the box (.gappssmtp.com or .onmicrosoft.com), neither platform enables custom-domain DKIM signing or publishes a DMARC record for you automatically. If you only configure MX records when setting up your workspace, your domain will fail DMARC alignment.

Here is the complete, copy-paste engineering reference for configuring SPF, 2048-bit DKIM, and DMARC on Google Workspace and Microsoft 365—plus how to fix the four errors we see most often in production scans.

Test your current workspace DNS configuration anytime with the MailPosture Domain Scanner.

Quick reference: Google Workspace vs Microsoft 365 DNS values

Part 1: Google Workspace SPF, DKIM, and DMARC setup

1. Google Workspace SPF record

If Google Workspace is the only service sending mail for your domain, publish this single TXT record at your root (@):

v=spf1 include:_spf.google.com -all

(If you also send via third-party tools like SendGrid, HubSpot, or Zendesk, add their include: mechanisms before -all, or use ~all while auditing—just make sure your total lookup count stays below the 10-DNS-lookup limit.)

2. Google Workspace 2048-bit DKIM setup

Even after you add include:_spf.google.com, Google Workspace does not sign mail with your domain's DKIM key until you generate one and click Start authentication:

1. Sign in to the Google Admin Console (admin.google.com) and navigate to Apps → Google Workspace → Gmail → Authenticate email.
2. Select your primary domain from the dropdown and click Generate new record.
3. Choose 2048-bit key length (unless your legacy DNS host cannot concatenate TXT strings over 255 characters) and keep the default prefix selector google (or set a custom selector like gws1).
4. Copy the generated TXT value starting with v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A... and publish it in your DNS provider at:

- Host / Name: google._domainkey

- Type: TXT

1. Wait 5–15 minutes for DNS propagation, verify the key is live with the Free DKIM Checker, and click Start authentication inside the Google Admin Console.

3. Common Google Workspace mistake: Generating the key but never clicking "Start authentication"

We frequently scan domains where google._domainkey.yourdomain.com publishes a valid 2048-bit public key in DNS, yet every email sent from Gmail still fails DKIM alignment. Why? Because an admin pasted the TXT record into Cloudflare or Route 53 while DNS was still propagating, closed the Google Admin tab, and never clicked "Start authentication". Always verify the status in Google Admin reads "Authenticating email with DKIM."

Part 2: Microsoft 365 SPF, DKIM, and DMARC setup

1. Microsoft 365 SPF record

For a standalone Microsoft 365 tenant, publish this TXT record at your root domain (@):

v=spf1 include:spf.protection.outlook.com -all

2. Microsoft 365 DKIM setup (selector1 and selector2 CNAMEs)

Unlike Google Workspace (which uses a direct TXT record containing the public key), Microsoft 365 uses two CNAME records (selector1._domainkey and selector2._domainkey) pointing to your tenant's .onmicrosoft.com signing hosts. This allows Microsoft to rotate your 2048-bit keys automatically without requiring you to edit DNS again.

1. Open the Microsoft Defender Portal (security.microsoft.com) and go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
2. Click your custom domain (yourdomain.com).
3. Toggle Sign messages for this domain with DKIM signatures. A dialog will display the exact CNAME targets for your tenant, which follow this pattern (where yourdomain-com uses hyphens instead of dots, and initialtenant is your M365 tenant prefix):

Host: selector1._domainkey.yourdomain.com
Type: CNAME
Points to: selector1-yourdomain-com._domainkey.initialtenant.onmicrosoft.com

Host: selector2._domainkey.yourdomain.com
Type: CNAME
Points to: selector2-yourdomain-com._domainkey.initialtenant.onmicrosoft.com

1. Publish both CNAME records in your DNS provider. Important for Cloudflare users: Set Proxy Status to DNS Only (grey cloud)—if Cloudflare proxies the CNAME, Microsoft 365 cannot validate the DKIM delegation.
2. Return to the Microsoft Defender DKIM blade and toggle Sign messages for this domain with DKIM signatures to Enabled.

3. Common Microsoft 365 mistake: Duplicate SPF records when adding a new domain

The Microsoft 365 domain setup wizard checks whether include:spf.protection.outlook.com is present. If you already have an existing SPF record (for example, v=spf1 include:sendgrid.net ~all) and paste Microsoft's suggested TXT record as a second TXT record instead of merging them into one string, both SPF records become invalid (PermError).

A domain may only ever publish one v=spf1 TXT record at the root. Merge both includes into a single record:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Part 3: Hybrid / Migration Coexistence (Google Workspace + Microsoft 365)

If your organization is migrating between Google Workspace and Microsoft 365, or runs split delivery across both environments:

1. Combined SPF Record (6 DNS lookups total):

   v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

1. Independent DKIM Selectors: Because Google uses google._domainkey and Microsoft uses selector1._domainkey / selector2._domainkey, both DKIM configurations coexist in DNS with zero conflict.
2. Unified DMARC Policy: Publish a single _dmarc.yourdomain.com TXT record to monitor both environments simultaneously:

   v=DMARC1; p=none; rua=mailto:reports@rua.getmailposture.com; fo=1;

Once your DMARC RUA reports confirm both Google Workspace and Microsoft 365 mail pass alignment, follow our safe rollout guide to p=quarantine and p=reject.

Beyond DNS: Auditing Tenant-Level Security Posture

SPF, DKIM, and DMARC protect your domain's outbound identity in DNS, but attackers also target workspace tenants directly through missing admin MFA, legacy IMAP/POP authentication, permissive external mail-forwarding rules, and over-privileged OAuth apps. You can review how MailPosture evaluates tenant posture using strictly read-only scopes in our Workspace Security & OAuth Compliance Note, or start by auditing your DNS records with the Free SPF Checker, Free DKIM Checker, and Free DMARC Checker.