DMARC for Office 365: The Complete Guide to Microsoft 365 Email Authentication

To set up DMARC for Microsoft 365 (Office 365), you need three DNS records: an SPF record with include:spf.protection.outlook.com, DKIM signing enabled via the Microsoft 365 Defender admin center, and a DMARC TXT record at _dmarc.yourdomain.com. Microsoft began enforcing DMARC for bulk senders in May 2025, following Google and Yahoo’s February 2024 mandate. If you run Exchange Online with a custom domain, proper email authentication is no longer optional.

This hub guide brings together everything you need to configure, troubleshoot, and maintain DMARC for Microsoft 365. Whether you are an Exchange administrator deploying DMARC for the first time, an MSP managing client tenants, or an IT professional investigating delivery failures, this is your starting point.

Compliance is driving a lot of the DMARC adoption we see, says Vasile Diaconu, Operations Lead at DuoCircle. PCI DSS v4.0, Google’s sender requirements, Microsoft’s May 2025 enforcement — our support team fields questions about these mandates daily. The organizations that moved early are already at p=reject. The rest are scrambling.

Microsoft’s DMARC Enforcement Timeline

Microsoft announced DMARC enforcement for Outlook.com, Hotmail.com, and Live.com in May 2025. The key requirements:

• All high-volume senders must authenticate with SPF, DKIM, and DMARC
• Non-compliant messages face rejection or junk folder placement
• The From header must align with the authenticated domain
• Microsoft’s inbound DMARC handling rejects or quarantines failing mail based on the sender’s published DMARC policy

For a complete breakdown of Microsoft’s requirements, see our guide on Microsoft Outlook DMARC requirements for May 2025 and our coverage of Microsoft Outlook’s new email security policies.

Microsoft also announced new DMARC policy handling defaults that affect how Exchange Online processes incoming mail with DMARC failures.

Step 1: Configure SPF for Microsoft 365

Your SPF record must include Microsoft’s sending infrastructure:

yourdomain.com. IN TXT "v=spf1 include:spf.protection.outlook.com -all"

If you send through additional services alongside Exchange Online, chain the includes:

yourdomain.com. IN TXT "v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all"

Key considerations:

• Microsoft’s include:spf.protection.outlook.com uses 2 of your 10 allowed DNS lookups.
• Only one SPF record per domain. Multiple records cause both to fail.
• Use -all (hard fail) rather than ~all (soft fail) for better protection.
• If you use Exchange on-premises hybrid alongside Exchange Online, you may need additional includes.

Validate your record with our SPF checker tool. For detailed instructions, see our guides on configuring Microsoft 365 SPF records and understanding SPF record configuration in Office 365. For domains that also need Outlook-specific SPF configuration, see adding SPF records to your domain for Outlook email authentication.

Our guide on external DNS records required for SPF in Microsoft 365 covers the complete set of DNS entries needed for a properly configured Microsoft 365 tenant.

Step 2: Enable DKIM for Microsoft 365

DKIM is not enabled by default for custom domains in Exchange Online. Microsoft signs outgoing mail with its own onmicrosoft.com domain by default, but this signature will not align with your custom domain for DMARC purposes.

Enable DKIM in the Admin Center

1. Sign in to the Microsoft 365 Defender portal
2. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings
3. Select the DKIM tab
4. Select your custom domain
5. Toggle Sign messages for this domain with DKIM signatures to enabled
6. If prompted, publish the two CNAME records in your DNS

Publish the DKIM CNAME Records

Microsoft requires two CNAME records for DKIM:

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

Replace yourdomain.com and yourtenant with your actual domain and tenant name. After publishing these records, return to the admin center and enable signing.

For the complete walkthrough, see our guide on setting up DKIM for Microsoft 365 domains. Validate your DKIM configuration with our DKIM lookup tool.

Step 3: Publish Your DMARC Record

With SPF and DKIM configured, publish your DMARC record:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Always start with p=none. This enables monitoring without affecting delivery. You will move to enforcement after analyzing reports for at least 90 days.

For Microsoft 365-specific DMARC setup, see our dedicated DMARC for Office 365: Complete Setup Guide. For guidance on the recommended record syntax specifically for Office 365 environments, see recommended DMARC DNS record syntax for Office 365.

Validate your record with our DMARC checker tool.

Step 4: Configure Transport Rules for Inbound DMARC Handling

Microsoft 365 allows you to create mail flow rules (transport rules) that take action on inbound messages based on their DMARC results. This is useful for organizations that want to enforce DMARC on incoming mail before Microsoft’s default handling takes effect.

Our guide on creating Microsoft 365 transport rules to quarantine unauthorized inbound emails covers how to configure these rules in the Exchange admin center.

For broader context on how Microsoft handles DMARC on inbound mail, see configuring DMARC for validating the From address domain in Microsoft 365.

Step 5: Monitor Aggregate Reports

Within 24-48 hours of publishing your DMARC record, aggregate reports (RUA) will begin arriving. These XML files contain data about every message claiming to be from your domain, including authentication results.

DMARC Report parses these automatically and presents the data in a visual dashboard. For Microsoft 365 domains, pay special attention to:

• Messages sent through Exchange Online — these should consistently pass SPF and DKIM if properly configured
• Messages from third-party services — marketing platforms, CRM systems, and other tools that send email on your behalf
• Messages from legacy on-premises servers — hybrid Exchange environments often have authentication gaps

For general report reading guidance, see our complete guide to DMARC aggregate reports.

Step 6: Progress Through Policy Enforcement

The typical enforcement timeline for Microsoft 365 domains:

Phase 1: p=none (Minimum 90 Days)

Monitor only. Identify all legitimate senders. Fix authentication failures for third-party services. Use the DMARC Report dashboard to track progress.

Phase 2: p=quarantine (Minimum 90 Days)

Start with pct=25 to apply the policy to 25% of failing mail. Gradually increase to 100%. Messages that fail DMARC are routed to the recipient’s junk folder.

Phase 3: p=reject

Full enforcement. Messages that fail DMARC are rejected at the SMTP level. The sending server receives a bounce notification.

For the complete enforcement journey, see our DMARC policy guide: from none to reject and our enforcement timeline roadmap.

Troubleshooting Office 365 DMARC Issues

Email Delivery Failures After DMARC Implementation

The most common post-implementation issue is legitimate email being blocked or quarantined. This happens when third-party services are not authenticated before moving to enforcement. Our guide on troubleshooting email delivery failures after implementing DMARC in Office 365 walks through the diagnostic process.

DMARC Impact on Office 365 Deliverability

DMARC affects both inbound and outbound email in Microsoft 365. Outbound messages from your domain need to pass DMARC for delivery to receivers that enforce it. Inbound messages to your tenant are evaluated against the sender’s DMARC policy. Our guide on the impact of DMARC on email deliverability for Office 365 users covers both directions.

Protecting Your Office 365 Infrastructure

Beyond DMARC for outbound authentication, you should also protect your Exchange Online environment from incoming spoofed mail. Our guide on protecting your email infrastructure with DMARC for Office 365 covers the defensive configuration.

SPF Authentication for Outlook

If you use Outlook.com accounts (consumer or business) alongside Microsoft 365, SPF configuration has specific requirements. See our guide on enhancing email authentication using SPF for Outlook.

Common Office 365 DMARC Mistakes

DKIM not enabled for custom domains. This is the single most common mistake. Microsoft signs mail with its onmicrosoft.com domain by default. Unless you enable DKIM for your custom domain, DKIM alignment fails. Messages may still deliver because SPF passes, but you lose the DKIM safety net for forwarded mail.

Missing the second DKIM CNAME record. Microsoft requires two CNAME records (selector1 and selector2) for key rotation. Publishing only one causes intermittent DKIM failures during key rotation.

SPF record not including Microsoft’s servers. If include:spf.protection.outlook.com is missing, every message sent through Exchange Online fails SPF.

Hybrid Exchange misconfigurations. Organizations with on-premises Exchange servers connected to Exchange Online often have authentication gaps. The on-premises server sends mail with the correct From domain but from an IP not covered by the cloud SPF record.

Forgetting to authenticate third-party senders. Marketing platforms, CRM tools, ticketing systems, and other services that send email using your domain need to be added to your SPF record and/or configured with DKIM signing.

Third-Party Sender Authentication in Office 365

Most organizations use third-party services alongside Exchange Online. Each service needs proper authentication:

Marketing and Transactional Email

• Add the service’s SPF include to your record (e.g., include:sendgrid.net, include:servers.mcsv.net)
• Configure DKIM signing with your domain through the service’s admin panel
• Verify alignment by checking DMARC reports after deployment

HubSpot Integration

For HubSpot users, see our guide on how to add HubSpot SPF, DMARC, and DKIM for email authentication.

Multiple Domains and Subdomains

Organizations with complex domain structures should review our guide on how to implement DMARC for multiple domains and subdomains. The sp tag in your DMARC record controls subdomain policy. See the DMARC subdomain policy tag explained for details.

Secure Email Practices in Microsoft 365

DMARC is one component of a broader email security strategy in Microsoft 365. Related topics include:

• Sending secure encrypted emails in Outlook covers encryption alongside authentication
• How to recall an email in Outlook addresses message management in Exchange

For organizations dealing with broader Microsoft 365 threats, our coverage of Microsoft 365 security developments provides context on the evolving threat landscape.

Office 365 and Multi-Provider Environments

Many organizations use Microsoft 365 for core email but other providers for specific functions. Common combinations include:

• Microsoft 365 + SendGrid for transactional email
• Microsoft 365 + Mailchimp for marketing email
• Microsoft 365 + Salesforce for CRM-generated email
• Microsoft 365 + Zendesk for support tickets

Each additional sender must be included in your SPF record and ideally configured with DKIM. Monitor your 10-lookup SPF limit carefully when chaining multiple includes. Our SPF checker tool shows your current lookup count.

For guidance on managing high-volume email authentication with complex sending infrastructure, see best practices for generating DMARC records for high-volume mailers.

DMARC Record Generator for Office 365

If you want a tool-assisted approach to creating your DMARC record, our DMARC record generator for Gmail and Office 365 walks through the process with pre-configured settings for Microsoft environments.

Why Microsoft’s Enforcement Matters

Microsoft’s May 2025 enforcement represents a significant shift. Before this date, Outlook.com would honor the sender’s DMARC policy but was relatively lenient about edge cases. The new defaults mean:

• p=reject is enforced strictly. Messages failing DMARC from domains with p=reject are rejected, not just marked as spam.
• Spoofed mail lands in junk. Even with p=none, Microsoft now provides safety tips in the message header when DMARC fails.
• Aggregate reporting is more consistent. Microsoft’s reporting infrastructure has improved, delivering more reliable RUA data.

This enforcement, combined with Google’s and Yahoo’s earlier mandates, means the three largest consumer email providers now enforce DMARC. Domains without DMARC authentication face delivery problems across the board. For the broader context of multi-provider enforcement, see why Google, Yahoo, Microsoft, and iCloud enforce stricter email authentication standards.

Next Steps

Once your Microsoft 365 DMARC setup is complete and enforced at p=reject:

1. Enable ongoing monitoring with DMARC Report to catch authentication regressions when third-party vendors change their infrastructure.
2. Review subdomain policies using the sp tag or individual subdomain DMARC records.
3. Consider BIMI to display your brand logo in supporting email clients.
4. Train your team so new services are authenticated before they start sending.

For the complete DMARC setup process across all platforms, see our DMARC setup complete guide.