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 from a 'nice-to-have' 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 can trip up even seasoned IT administrators. A small misconfiguration can lead 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.
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 'alignment'. For DMARC to pass, it's not enough for SPF or DKIM to simply pass; they must also 'align' with the 'From' address domain that the recipient sees. SPF alignment means the domain in the Return-Path address (the bounce address) must match the 'From' domain. DKIM alignment means the domain specified in the DKIM signature (the d= tag) must match the 'From' domain. Failure to align is a common reason for a DMARC fail, even if the individual checks are technically valid.
This alignment 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 might be authorized in your SPF record and might even sign with DKIM, but if the domains they use don't match your 'From' address domain, DMARC alignment will fail. This is a core challenge you'll need to solve for both Microsoft 365 and Google Workspace environments.
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 align with 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 an aligned signature.
DKIM CNAME Record 1
dns
Host name: selector1._domainkey.yourdomain.com
Points to address or value: selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.comFirst CNAME record for DKIM selector 1.
DKIM CNAME Record 2
dns
Host name: selector2._domainkey.yourdomain.com
Points to address or value: selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.comSecond CNAME record for DKIM selector 2.
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 can quickly become bloated. This can lead 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
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 aligns with your domain.
TXT record value
dns
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...[your public key]...IDAQABThis is an example of the DKIM public key value you'll add to your DNS.
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 may be sent from Google's servers in a way that breaks alignment. These DMARC failures can be tricky to diagnose without DMARC reports.
While both platforms require the same foundational setup (SPF and DKIM records in DNS), their administrative paths and common pain points differ significantly. Understanding these differences can help you anticipate problems before they affect your email delivery.
DKIM setup
Common pitfalls
DKIM setup
Common pitfalls
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
This leads to the final, critical piece of the puzzle: DMARC reporting. The 'R' in DMARC stands for '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.
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 alignment 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 can harness the full power of DMARC to protect your domain, enhance your brand's reputation, and ensure your important emails reach their destination.
What does a DMARC fail mean in my reports?
Why are my emails going to spam even with DMARC set to p=none?
How long does it take for DMARC changes to take effect?
Can I use both Microsoft 365 and Google Workspace to send email from the same domain?
Matthew Whittaker
6 Jul 2025
Discover the essential benefits of implementing DMARC for your email. This article explains how DMARC enhances your security by preventing domain spoofing and phishing, boosts deliverability by improving your sender reputation, and provides invaluable visibility into your email ecosystem. Learn why DMARC is a non-negotiable tool for protecting your brand and ensuring your messages reach the inbox.
Michael Ko
9 Jul 2025
Learn how to find, vet, and hire a DMARC professional to secure your email and improve deliverability. This guide covers what to look for in an expert, where to find them, and the key questions to ask to ensure you're protecting your brand from phishing and spoofing.
Michael Ko
10 Jul 2025
Getting a 'DMARC verification failed' error? This post breaks down what it means, the common causes like alignment issues with SPF and DKIM, and how to fix it. Learn how to diagnose problems using DMARC reports and a step-by-step approach to secure your domain without blocking legitimate emails.
Matthew Whittaker
11 Jul 2025
Seeing a 'DMARC policy not enabled' warning can be confusing. This message doesn't mean something is broken, but rather that your DMARC policy is set to a monitoring-only mode (p=none) and not yet enforcing protection. This guide explains what the warning means, why starting with p=none is a critical first step, and how to methodically analyze your email sources to safely transition to an enforcement policy like p=quarantine or p=reject, ultimately securing your domain and improving deliverability.
Michael Ko
11 Jul 2025
Getting started with DMARC doesn't have to be complicated. This guide explains why a `p=none` policy is the safest first step, providing simple, copy-paste examples to help you start monitoring your email domain. Learn how to gain crucial visibility into who is sending email on your behalf without any risk to your deliverability.
Matthew Whittaker
11 Jul 2025
Ever felt lost in the alphabet soup of email security? This guide breaks down DMARC, SPF, and DKIM into simple concepts. We'll explain how SPF creates a guest list for your emails, DKIM adds a tamper-proof seal, and DMARC acts as the security chief, telling mail servers how to handle unverified messages, ensuring your emails are trusted and secure.
