DMARC for Google Workspace and Microsoft 365

Default DMARC Status

Neither Google Workspace nor Microsoft 365 publishes a DMARC record for your domain by default. Moving your MX records to Google or Microsoft does not give you DMARC. You get their mail routing infrastructure; you still own the DNS configuration for your domain.

Check your current status with the mxio DMARC Checker. If you see "No DMARC record found," you need to publish one. If you see p=none, you have monitoring in place but no enforcement.

Before publishing a DMARC record, you need DKIM and SPF configured correctly. Both platforms require manual steps to enable DKIM — it is not on by default.

DKIM for Google Workspace

Google Workspace can sign outbound email with DKIM, but you have to turn it on.

Enable DKIM signing

1. Log in to the Google Admin Console
2. Go to Apps → Google Workspace → Gmail → Authenticate email
3. Select your domain
4. Click Generate new record
5. Copy the TXT record value Google provides
6. Publish it in your DNS as a TXT record at google._domainkey.yourdomain.com
7. Return to the Admin Console and click Start authentication

The DNS record format looks like this:

google._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Google uses the selector google by default. After publishing, allow a few minutes for DNS propagation, then click Start authentication in the Admin Console.

Why Google aligns by default

Once DKIM is enabled, Google signs messages with d=yourdomain.com — your domain, not Google's. This means DKIM alignment passes for DMARC purposes without any special configuration. SPF alignment also passes because Google includes your domain in the envelope sender.

This is why Google Workspace is one of the simpler platforms to get to DMARC compliance: enable DKIM once and your primary sending source is clean.

Verify the configuration

Run the mxio DKIM Checker with selector google and your domain. Confirm that the result shows d=yourdomain.com in the signature and that the check passes.

DKIM for Microsoft 365

Microsoft 365 requires DKIM to be explicitly enabled per domain through the Security & Compliance center.

Enable DKIM signing

1. Go to the Microsoft Defender portal (formerly Security & Compliance center)
2. Navigate to Email & Collaboration → Policies & Rules → Threat Policies → Email authentication settings
3. Select the DKIM tab
4. Select your domain and click Enable
5. Microsoft will show you two CNAME records to publish in DNS

The CNAME records look like this:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.onmicrosoft.com

The exact values depend on your domain. Copy them from the Defender portal — do not guess the format.

Microsoft uses two selectors (selector1 and selector2) and rotates between them. Both must be published. After publishing the DNS records, return to the Defender portal and enable DKIM for the domain.

Why Microsoft aligns by default

When DKIM is enabled, Microsoft 365 signs messages with d=yourdomain.com. Same as Google: once you publish the DNS records and enable signing, your primary mail source aligns for DMARC without further configuration.

Verify the configuration

Run the mxio DKIM Checker with selector selector1 and your domain. After Microsoft activates DKIM (which can take a few minutes to a few hours), confirm the check passes and the d= value is your domain.

SPF for Google Workspace and Microsoft 365

Both platforms publish SPF include records. Your SPF record needs to include the appropriate mechanism for whichever platform you use.

Google Workspace:

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

Microsoft 365:

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

If you use both (rare, but possible during migrations):

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

Run the mxio SPF Checker to confirm your record is valid, resolves without errors, and stays under the 10-lookup limit. Each include: consumes at least one lookup — once you add several third-party senders, the lookup limit becomes the primary constraint.

The Real Complexity: Third-Party Senders

Getting Google Workspace or Microsoft 365 aligned for DMARC is straightforward. The harder problem is every other service that sends email as your domain.

Most organizations sending business email are actually sending from many sources at once:

Each of these needs to be handled before you can move DMARC to enforcement. A service that is not configured correctly will fail DMARC alignment. At p=quarantine or p=reject, those failures mean email goes to spam or gets bounced.

For each third-party sender, you have two options:

Option 1: Add to SPF and configure DKIM. Add the provider's SPF include: to your record and configure DKIM signing so the service signs with d=yourdomain.com. Most modern ESPs support this — SendGrid calls it "sender authentication," Mailchimp calls it "domain authentication," Amazon SES calls it "custom MAIL FROM domain." This is the recommended approach.

Option 2: Configure SPF only. If the provider does not support DKIM with your domain, add their SPF include so SPF aligns. This works but is less resilient — forwarding can break SPF, and DKIM is the mechanism that survives it.

Adding multiple third-party senders to SPF can push you over the 10-lookup limit quickly. If that happens, mxio's Managed SPF handles the flattening automatically — it resolves all the include chains to a static IP list and keeps it updated.

Common Alignment Failures

Forwarded mail

When email forwarded through a third party — a mailing list, an .forward rule, or a university alumni forwarder — the forwarding server's IP is not in your SPF record. SPF fails at the forwarding hop.

If your DKIM signature is intact, DMARC can still pass. This is why DKIM is more important than SPF for DMARC resilience. But some forwarding services modify message bodies (adding footers, rewriting links), which breaks DKIM signatures.

What to do: Do not try to fix forwarding failures by modifying your SPF record — adding forwarding servers' IPs is not feasible. Ensure DKIM is configured for all senders. Accept that some forwarded mail will fail SPF; if DKIM survives, DMARC still passes.

Shared hosting and legacy mail relays

Older infrastructure — shared hosting mail relays, legacy on-premises mail servers, or print-to-email systems — often sends using your domain's From: address without proper authentication. These will appear in your DMARC reports as unknown sources failing alignment.

For each one: either configure authentication (add to SPF, set up DKIM if the platform supports it) or migrate to a modern sending service that supports full authentication.

Marketing tools without DKIM configuration

A common pattern: a marketing team signs up for Mailchimp and starts sending campaigns using @yourdomain.com as the From address, but nobody configures DKIM domain authentication. Mailchimp signs messages with d=mcsv.net — its own domain, not yours. SPF may pass for Mailchimp's servers, but DKIM alignment fails.

The fix: configure domain authentication in the marketing tool so it signs with d=yourdomain.com. Every major ESP has a process for this. It involves publishing DNS records they provide and verifying the configuration in their admin interface.

How mxio DMARC Reporting Helps

Once you have DMARC monitoring in place, the DMARC Reporting dashboard shows you every source sending as your domain — not just Google and Microsoft, but every ESP, internal tool, and forwarding chain.

Sources are identified by provider where possible. If Mailchimp is sending without DKIM alignment, it appears as "Mailchimp — Misconfigured" rather than as an anonymous IP address. You know immediately what to fix.

The Enforcement advisor tracks whether you are ready to move from p=none to p=quarantine or p=reject. It shows your current alignment rate, flags sources that would be affected by tightening policy, and identifies any significant unclassified traffic. You get the analysis without reading XML.

Use the free DMARC Checker to verify your current DMARC record and SPF Checker to confirm your SPF configuration is valid before you start.

Related Articles

• DMARC Deployment Guide: From p=none to p=reject — the full deployment process
• Moving from p=none to p=reject — when you are ready to tighten policy
• Understanding DMARC Aggregate Reports — what the XML reports contain
• DMARC Alignment Failure: Why SPF/DKIM Pass But DMARC Fails — fixing alignment issues in detail
• Why Is DMARC Failing? — diagnosing failures
• SPF Too Many Lookups — what to do when you hit the 10-lookup limit
• No DMARC Record Found — how to start if DMARC is missing