DMARC Implementation Guide for Microsoft 365

Introduction

For MSPs and small-to-medium businesses using Microsoft 365 and Exchange Online, implementing DMARC can seem daunting. While Microsoft provides basic email security, proper DMARC implementation is crucial for protecting against email spoofing and maintaining deliverability. This guide provides practical steps for MSPs and IT teams to implement DMARC across Microsoft 365 tenants.

What You Actually Need to Protect

Start by checking the Microsoft 365 Admin Center under Domains and your domain registrar - these are the domains you need to protect:

1. All domains configured for email sending
2. onmicrosoft.com domains
3. Any parked or unused domains (these are often overlooked but can be used for spoofing)

Common misconception: While you might not need to protect every subdomain immediately, any domain capable of sending email needs protection - even if you think it's not being used. Attackers often exploit forgotten or parked domains.

Prerequisites Checklist

Before starting DMARC implementation, ensure you have:

• Global Admin or Security Admin access to the Microsoft 365 tenant (to enable DKIM)
• Access to domain DNS management (or contact information for who does)
• List of any third-party email senders (e.g., marketing platforms, CRM systems)
• VerifyDMARC account for monitoring reports

Step 1: Email Source Audit

For SMEs, common email sources typically include:

1. Microsoft 365 Exchange Online (primary email)
2. Line-of-business applications sending email
3. Multi-Function Devices (i.e. photocopiers) with scan-to-email (sending directly or via an SMTP relay service like SMTP2GO or Mailgun)
4. Marketing platforms (e.g., Mailchimp, SendGrid)
5. Cloud services (e.g., accounting software, CRM)

Tip: Let DMARC reports do the work for you! Collect reports using VerifyDMARC over a month with a safe p=none policy then review the reports before moving to enforce DMARC (p=quarantine or p=reject). This way it is less likely an email source is overlooked if it hasn't been documented or has been implemented as shadow IT.

Step 2: Configure SPF for Microsoft 365

An SPF TXT record for Microsoft 365-only should look like this:

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

If the domain has other mail senders that support or require SPF authentication, they should be added to the record while taking care to not exceed the SPF lookup limit.

Tip: If you are enforcing DMARC, the domain's SPF record should end in ~all to ensure mail is not prematurely rejected before checks are complete.

Step 3: Enable DKIM in Microsoft 365

Quick steps for enabling DKIM for a custom domain:

‍

1. Open the Microsoft Defender portal
2. Go to: Email & collaboration > Policies & rules > Threat policies > Email authentication settings
3. On the Email authentication settings page, select the DKIM tab
4. Select a custom domain that currently shows "Disabled" to open the flyout (if it says "Enabled", DKIM is already setup)
   • If the Status says "No DKIM keys saved for this domain." select "Create DKIM keys" then refresh the page, open the domain's flyout again and proceed
5. Select the "Sign messages for this domain with DKIM signatures" toggle that's currently set to Disabled
6. From the error dialog, copy the two CNAME records Microsoft provides
7. Add these to the domain's DNS manager and wait for DNS to propagate (often this is at least an hour)
8. Repeat step 5 until the domain shows Status: "Signing DKIM signatures for this domain." and Status: "Valid" and "Enabled" in the DKIM tab domain list

‍

Tip: Emails from your onmicrosoft.com domain are automatically signed even if the domain shows as "Disabled" in the Defender Portal DKIM tab, to make the portal consistent you can follow the steps above, just skip step 6 & 7 as Microsoft manage these DNS records.

‍

‍

‍Common Issue: DKIM validation can take up to 48 hours. Don't panic if it won't enable immediately.

Step 4: Start DMARC Implementation

If you have no existing DMARC record, begin with a monitoring policy using p=none:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

MSP Best Practice: Use VerifyDMARC to aggregate reports across all your clients' domains. This saves hours of manual report processing.

Step 5: Monitor Initial Results

Key things to watch for in your first month:

1. Non-Compliant mail sent from legitimate sources
2. Unexpected email sending sources, these could be shadow IT services
3. Volume of spoofing attempts (illegitimate sources)
4. Microsoft 365 services authentication and alignment (SPF Align and DKIM Align)

Tip: If you are using a service like VerifyDMARC, ensure legitimate sources (if they support DKIM) have a high 'DKIM Align' %. SPF Align is good too, but not all services can or do support it. DKIM Align is more important when using a strict p=reject DMARC policy as it more frequently survives forwarding.

‍

‍

Common Microsoft 365 Authentication Issues

Issue 1: DKIM not properly enabled

• Follow steps to Enable DKIM in Microsoft 365
• Wait for DMARC reports to show 'DKIM Align' to confirm it is fully enabled

Issue 2: Third-Party Marketing Platforms

• Add their SPF record to your existing record, if they suggest to
• Enable DKIM if the platform supports it

Issue 3: Legacy Applications

• Review DMARC reports to identify applications using direct SMTP
• Consider migrating to an SMTP relay service, like Microsoft 365 SMTP Relay or SMTP2GO

Progressive Policy Implementation

For most SMEs, follow this timeline:

1. Month 1: p=none (monitor only)
2. Month 2: p=quarantine
3. Month 3+: p=reject

Tip: Create a calendar reminder to check reports a week after each policy change.

Microsoft 365 Specific Considerations

Protecting onmicrosoft.com Domains

• Always implement DMARC on onmicrosoft.com domains
• Use the same reporting address as your primary domain
• Start with p=none policy then move to p=quarantine and p=reject
• Review our post on how to protect your onmicrosoft.com domain

Quick Troubleshooting Guide

Common issues and fixes:

1. SPF Failures
   • A small proportion of mail will always fail DMARC SPF Align checks
   • Some services do not support SPF Align, like Mailchimp so these services must have DKIM setup
   • If SPF Align is 0% or very low check the SPF record syntax and ensure it does not exceed the lookup limit
2. DKIM Failures
   • Not all mail senders support DKIM, if this is the case ensure mail is passing DMARC SPF Align
   • Check DKIM is enabled for the service
   • Verify the DKIM DNS records are correct, refer to the mail sender's documentation
   • Wait full 48 hours after DNS changes to enable, then review DMARC reports after a week
3. Missing Reports
   • Verify report address (in the rua tag of the DMARC record) is valid
   • Confirm DMARC DNS record syntax
   • Use a service like VerifyDMARC to provide feedback on potential configuration issues

Next Steps

1. Use VerifyDMARC's dashboard to monitor results
2. Document what works for your first implementation
3. Replicate across other domains/clients
4. Regularly monitor DMARC reports for changes

MSP Implementation Checklist

• Safely audit email sources using a DMARC reporting service with a p=none policy
• Configure SPF and/or DKIM authentication for senders to pass DMARC alignment
• Review reports to ensure legitimate sources are DMARC compliant
• Wait a month to ensure reports capture infrequent legitimate senders
• Upgrade DMARC policy to p=quarantine
• Review reports and monitor for user feedback over a month
• If all critical sources have high DKIM alignment, upgrade DMARC policy to p=reject for maximum protection

Conclusion

For MSPs and SMEs, implementing DMARC on Microsoft 365 doesn't have to be complex. Start with monitoring, focus on actively used domains, and progress gradually to enforcement. Use tools like VerifyDMARC to simplify monitoring and management across multiple tenants.

Ready to secure your Microsoft 365 email? Start your free trial with VerifyDMARC today and get expert support for your DMARC implementation.