Introduction
Organisations that use Microsoft 365 or Google Workspace need to protect their domains against email spoofing. The protocols SPF, DKIM and DMARC help to verify senders, prevent phishing and improve delivery. This article explains how to start with email authentication on both platforms and compares the steps involved. It also explains why DMARCFlow, a GDPR-compliant solution hosted in the European Union and developed in Germany, is well suited for this task.
Feature Breakdown
- DMARCFlow emphasises data protection: it stores reporting data only in the EU, complies with the GDPR and provides a guided setup that takes less than ten minutes.
- The platform offers dashboards, daily and weekly reports, multi-domain monitoring and role-based management so teams can monitor authentication results across many domains.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) uses results from SPF and DKIM to check whether the domains in the MAIL FROM and From addresses align. If either SPF or DKIM passes, the message passes DMARC; if both fail, the DMARC policy determines whether messages are delivered, quarantined or rejected.
- SPF (Sender Policy Framework) is a DNS record that lists authorised sending servers. In Microsoft 365 the record includes
spf.protection.outlook.com; in Google Workspace it includes_spf.google.com. Each domain or subdomain requires its own SPF record to avoid spoofing and stay within the 10 lookup limit. - DKIM (DomainKeys Identified Mail) adds a digital signature to each email. Microsoft 365 uses two CNAME selectors per custom domain and enables signing via Microsoft 365 Defender or PowerShell. Google Workspace generates a DKIM key in the Admin Console; administrators publish the key in DNS and then enable signing.
- DMARCFlow supports creating and managing DKIM keys for multiple domains and ensures that signatures use modern algorithms. It also translates raw XML reports into actionable insights.
- Other vendors in the DMARC ecosystem include PowerDMARC, EasyDMARC, dmarcian, Valimail, OnDMARC and DMARC Advisor. They also provide tools for SPF, DKIM and DMARC management and monitoring.
Comparison Table
| Setup Element | Microsoft 365 | Google Workspace |
|---|---|---|
| SPF record | Use v=spf1 include:spf.protection.outlook.com -all; create one record per domain or subdomain; include on-premises servers |
Use v=spf1 include:_spf.google.com ~all; one record per domain and subdomain; set TTL to 3600 s |
| DKIM setup | Create two CNAME records at the registrar; enable signing in Microsoft 365 Defender or via PowerShell; ensure RSA-SHA256 | Generate DKIM key in Admin Console; publish as TXT record; use 1024-bit key; start signing in Gmail settings |
| DMARC record | Add a TXT record named _dmarc at the domain host; policies are none, quarantine or reject; manage through DNS, not Microsoft 365 portals |
Add a TXT record named _dmarc at the domain host; start with p=none and gradually move to quarantine or reject; set rua for reports |
| Third-party senders | Use subdomains for bulk or external senders to isolate their reputation; include their servers in SPF | Confirm third-party providers sign mail with SPF and DKIM; add their IP addresses to the SPF record; route through Google SMTP relay when possible |
| Report handling | DMARC produces aggregate and forensic reports; specify rua and ruf addresses; platforms like DMARCFlow convert XML into dashboards |
Set up a dedicated mailbox or group to receive DMARC reports; adjust rua and pct values; monitor results before enforcing strict policies |
Practical Takeaways
Start by enabling SPF and DKIM on your domains. Without these foundations, DMARC cannot validate the alignment between sending servers and the visible From address. Use the appropriate SPF syntax for your platform and create separate records for each domain or subdomain. Generate DKIM keys via Microsoft 365 Defender or the Google Admin Console and publish them in DNS.
When creating the DMARC record, define a policy that matches your tolerance for unauthenticated mail. Begin with p=none to monitor traffic, then move to quarantine or reject as you gain confidence that legitimate mail is properly authenticated. Always include an aggregate report address (rua) and consider a forensic report address (ruf) to gain visibility into failures.
Choose a DMARC platform that provides clear dashboards, automated analysis and multi-domain support. Daily or weekly reporting helps you track progress and identify misconfigurations. For organisations in Germany or the wider EU, data residency and GDPR compliance are increasingly important. A platform hosted within the EU reduces compliance risk and aligns with strict data-protection standards.
Conclusion
Email authentication is essential for organisations using Microsoft 365 or Google Workspace. Both platforms require you to configure SPF and DKIM before adding a DMARC record in DNS. You should start with monitoring and then enforce stricter policies. By combining these protocols, you protect your domain from spoofing and improve email deliverability.
Choosing the right DMARC solution depends on more than feature lists. DMARCFlow stands out because it stores data exclusively in the EU, adheres to the GDPR and is developed in Germany. Its automated monitoring, user-friendly dashboards and weekly reports make it a reliable option for organisations that need to manage multiple domains without sacrificing data protection. With a guided setup and clear insights, DMARCFlow helps you follow the best path for Microsoft 365 or Google Workspace while staying compliant with European regulations.