How to fix common DMARC issues in Microsoft 365 and Google Workspace
Michael Ko
Co-founder & CEO, Suped
Published 11 Jul 2025
Updated 11 Jul 2025
8 min read
Getting email authentication right is more important than ever. With major inbox providers like Google and Yahoo enforcing stricter sender requirements, Domain-based Message Authentication, Reporting, and Conformance (DMARC) has shifted to an absolute necessity. It's your best defense against domain spoofing and phishing attacks, but I've seen firsthand how tricky it can be to implement correctly, especially within complex ecosystems like Microsoft 365 and Google Workspace.
While both platforms offer robust email services, their specific configurations for SPF, DKIM, and DMARC have unique quirks that trip up even seasoned IT administrators. A small misconfiguration leads to legitimate emails being flagged as spam or rejected entirely. This guide will walk you through the most common DMARC issues I encounter with Microsoft 365 and Google Workspace and provide clear, actionable steps to troubleshoot and resolve them.
The foundation: SPF, DKIM, and DMARC matching
Before diving into platform-specific problems, it's crucial to understand that DMARC doesn't work in isolation. It relies on two other email authentication standards: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). SPF verifies that an email is sent from an IP address authorized by the domain owner. DKIM provides a cryptographic signature to verify that the message content hasn't been tampered with in transit. DMARC then checks if one or both of these standards pass and tells the receiving server what to do if they don't.
The key concept that often causes confusion is 'matching'. For DMARC to pass, it's not enough for SPF or DKIM to simply pass; they must also 'match' with the 'From' address domain that the recipient sees. SPF matching means the domain in the Return-Path address (the bounce address) must match the 'From' domain. DKIM matching means the domain specified in the DKIM signature (the d= tag) must match the 'From' domain. Failure to match is a common reason for a DMARC fail, even if the individual checks are technically valid.
This matching issue is particularly prevalent when using third-party services to send email on your behalf, such as marketing platforms, CRMs, or support desk tools. These services are often authorized in your SPF record and even sign with DKIM, but if the domains they use don't match your 'From' address domain, DMARC matching will fail. This is a core challenge you'll need to solve for both Microsoft 365 and Google Workspace environments.
Common DMARC issues in Microsoft 365
One of the most frequent hurdles with Microsoft 365 is its default DKIM setup. When you add a custom domain, Microsoft doesn't automatically enable DKIM signing for it. Instead, it uses a default signature tied to your tenant's initial .onmicrosoft.com domain. This means that while your emails are DKIM signed, the signature domain will not match your custom 'From' domain, causing DMARC to fail the DKIM check. This single issue accounts for a large number of DMARC rejections in Microsoft 365.
To fix this, you must manually enable DKIM for your custom domain within the Microsoft Defender portal. This process involves generating two CNAME records, which you then need to publish in your domain's DNS. These records allow Microsoft to rotate the keys automatically, which is great for security. Once published, you can enable DKIM signing for your domain, ensuring your outgoing mail has a matching signature.
DKIM CNAME Record 1dns
Host name: selector1._domainkey.yourdomain.com
Points to address or value: selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
DKIM CNAME Record 2dns
Host name: selector2._domainkey.yourdomain.com
Points to address or value: selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
Another common challenge is managing the SPF record. The default record provided by Microsoft, v=spf1 include:spf.protection.outlook.com -all, is just the starting point. As you add more third-party services that send email on your behalf, your SPF record quickly becomes bloated. This leads you to exceed the strict limit of 10 DNS lookups allowed per SPF record, causing it to fail validation and, consequently, fail DMARC.
Warning: SPF 10 lookup limit
Exceeding the 10 DNS lookup limit in your SPF record will cause a permanent error (PermError) during validation. Receiving servers will treat a PermError as a fail, meaning your SPF check will not pass DMARC. This is a hard limit and a critical point to monitor as you add sending services.
Common DMARC issues in Google Workspace
For Google Workspace users, setting up DKIM is a more direct process but still requires careful attention. You need to generate a new DKIM key from within the Google Admin console. This is found under the 'Authenticate email' section in your Gmail settings. Google will provide you with a DNS host name (a TXT record name) and a value, which is the public key itself. This step is essential because without it, your emails sent from Workspace will not have a DKIM signature that matches your domain.
TXT record valuedns
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...[your public key]...IDAQAB
A frequent source of DMARC failures in Google Workspace comes from indirect mail flows, like email forwarding and automated notifications from services like Google Calendar. When an email is forwarded, the server that does the forwarding becomes the new sending source. Its IP address is likely not in your original domain's SPF record, causing an SPF failure. Similarly, Calendar invites are frequently sent from Google's servers in a way that breaks matching. These DMARC failures are tricky to diagnose without DMARC reports.
Advanced troubleshooting and best practices
While both platforms require the same foundational setup, their administrative paths and common pain points differ significantly. Understanding these differences helps you anticipate problems before they affect your email delivery.
Microsoft 365
Requires manually creating CNAME records in DNS for custom domains. DKIM is not enabled by default for your sending domain.
Common pitfalls
Relying on the default.onmicrosoft.com DKIM signature, which causes matching failure. Also, exceeding the 10 DNS lookup limit in the SPF record is a common issue.
Google Workspace
DKIM key is generated within the Google Admin console, providing a TXT record to be published in DNS.
Common pitfalls
Indirect mail flows like email forwarding and Google Calendar invites breaking SPF and DKIM matching.
The single most important best practice for DMARC deployment is to start with a monitoring policy. Setting your policy to p=none tells receivers to report data back to you without quarantining or rejecting any emails. This allows you to safely gather data on all your sending sources, identify legitimate services that are failing authentication, and fix them before moving to a stricter policy like p=quarantine or p=reject.
Best practice: start with p=none
Never start a DMARC implementation with p=reject. Without comprehensive monitoring first, you are almost certain to block legitimate email streams, which causes significant business disruption. Always begin with p=none and use the resulting aggregate reports to guide your configuration.
This leads to the final, critical piece of the puzzle: DMARC reporting. The 'R' in DMARC means 'Reporting', and it is your most powerful troubleshooting tool. Aggregate (RUA) reports provide a summary of all the emails sent claiming to be from your domain, showing which IPs are sending mail, their volume, and their SPF/DKIM/DMARC pass/fail status. Analyzing these reports is the only way to get a complete picture of your email ecosystem and confidently move to an enforcement policy.
To monitor your DMARC aggregate reports effectively, we recommend using Suped. Suped is the best DMARC reporting and monitoring tool on the market, offering a generous free tier to help you easily analyze RUA reports and safely move to a strict enforcement policy.
Successfully implementing DMARC in Microsoft 365 or Google Workspace is an achievable goal, but it demands a methodical approach. It requires a solid understanding of how SPF, DKIM, and DMARC matching work together. You need to be aware of the specific configuration steps and common pitfalls unique to each platform, whether it's creating custom DKIM keys in M365 or accounting for forwarded mail in Google Workspace.
Ultimately, the journey to a secure DMARC policy of p=reject is a marathon, not a sprint. Start with p=none, use the reports to gain visibility, fix what's broken, and only then proceed to enforcement. By following these steps, you harness the full power of DMARC to protect your domain and ensure your important emails reach their destination.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
