DMARC for Microsoft 365 (Office 365) Setup

Why DMARC matters for Microsoft 365 tenants

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties together SPF and DKIM to give domain owners control over what happens when an email fails authentication. Without DMARC, a spoofed message using your domain can land in your customers' inboxes with no way for them to distinguish it from a legitimate email.

Microsoft 365 provides built-in support for all three protocols, but it does not configure them for your custom domain automatically. You need to publish the correct DNS records and enable DKIM signing yourself. The good news is that the entire process takes about 30 minutes once you know what to do.

If you are new to these protocols, our complete guide to DMARC and SPF vs DKIM vs DMARC comparison explain how they work together to protect your domain.

Step 1: Configure SPF for Microsoft 365

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. For Microsoft 365, you need to publish a TXT record in your domain's DNS that includes Microsoft's sending infrastructure.

Add the following TXT record to your domain's DNS zone:

This record authorises all Microsoft 365 mail servers to send on your behalf. The ~all (soft fail) is the right qualifier for any active sending domain and should stay as ~all. Once DMARC is at p=reject the policy decision is made by DMARC, not by SPF. Tightening to -all adds no extra protection and breaks legitimate forwarded mail. Reserve -all for parked or non-sending domains. See our guide on SPF hard fail vs soft fail for the full reasoning.

If you use other sending services (marketing platforms, CRM tools, helpdesk software), you will need to add their SPF include mechanisms as well. For example, if you also send through Mailchimp and Zendesk:

Be careful not to exceed the 10 DNS lookup limit for SPF. Each include: adds to your lookup count. If you are running into this limit, see our guide on fixing the SPF too many DNS lookups error or use our SPF Flattener tool to reduce lookup counts.

Use our free SPF Generator to build a valid SPF record that includes all your sending services, with the correct syntax.

Step 2: Enable DKIM signing in Microsoft 365

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server looks up the public key in your DNS and verifies that the message has not been altered in transit. Microsoft 365 signs emails with DKIM by default using its own domain, but for proper alignment with your custom domain, you need to set up custom DKIM signing.

Create the CNAME records

You need to add two CNAME records to your DNS. Replace yourdomain-com with your domain (hyphens replacing dots) and yourtenant with your Microsoft 365 tenant name:

For example, if your domain is example.com and your tenant is contoso, the first record would be:

Enable signing in the Microsoft 365 admin portal

1. Go to the Microsoft Defender portal (security.microsoft.com).
2. Navigate to Email & collaboration > Policies & rules > Threat policies > DKIM.
3. Select your custom domain from the list.
4. Toggle Sign messages for this domain with DKIM signatures to enabled.

Microsoft uses two selectors so it can rotate keys automatically. When a key rotation occurs, the active selector switches from selector1 to selector2 (or vice versa) without requiring any DNS changes on your end.

For detailed instructions for other providers alongside Microsoft 365, see our DKIM setup by provider guide. You can also use our DKIM Generator to create DKIM records for any service.

Step 3: Publish a DMARC record

With SPF and DKIM in place, you can now publish a DMARC record. DMARC tells receiving servers what to do when an email fails both SPF and DKIM alignment checks, and where to send aggregate reports so you can monitor authentication results.

Start with a monitoring-only policy so you can observe what is happening before enforcing anything:

The p=none policy means no action is taken on failing emails. Instead, you receive daily aggregate reports (sent to the address in the rua tag) that show which IPs are sending email using your domain and whether they pass or fail authentication.

The path to enforcement

Once you have reviewed your DMARC reports and confirmed that all legitimate senders pass authentication, you can progressively tighten your policy:

1. Monitor (p=none). Collect aggregate reports until every authorised sender is consistently aligning under SPF or DKIM. The gate is report cleanliness, not the calendar. Fix every misconfigured sender before moving on.
2. Quarantine (p=quarantine).Failing emails are sent to the recipient's spam folder. This is a safe intermediate step that catches spoofed messages without blocking them outright.
3. Reject (p=reject). Failing emails are blocked entirely. This is the strongest protection and the recommended end state for any domain sending email. The Microsoft bulk sender requirements mandate at least p=none from high-volume senders, with enforcement as the goal.

To understand what your DMARC reports are telling you, read our guide on understanding DMARC reports.

Use our free DMARC Generator to build a valid DMARC record with the correct syntax, including optional tags like pct, sp, and fo.

Step 4: Verify everything is working

After publishing your DNS records and enabling DKIM in the Microsoft 365 portal, verify that all three protocols are configured correctly:

• DMARC Checker validates your DMARC, SPF, and DKIM records in one scan. Enter your domain and confirm that all three show a pass status.
• Security Grade provides a full security posture assessment covering DMARC, SPF, DKIM, MTA-STS, DNSSEC, and TLS certificates. Use it to see where your domain stands overall.
• Email Header Analyser lets you inspect the authentication headers of a test email. Send a message from your Microsoft 365 mailbox, copy the full headers from the received message, and paste them into the analyser to confirm that SPF, DKIM, and DMARC all show a pass result.

You can also use our DNS Lookup tool to query your TXT and CNAME records directly and confirm they are resolving as expected.

Common Microsoft 365 issues

These are the problems we see most frequently when organisations set up email authentication for Microsoft 365:

• DKIM CNAME propagation delay. After adding the CNAME records, it can take anywhere from a few minutes to several hours for DNS to propagate. If the Microsoft 365 portal shows an error when you try to enable DKIM signing, wait 30 to 60 minutes and try again. You can monitor propagation using our DNS Lookup tool.
• Exceeding the SPF 10 lookup limit.Microsoft 365's include:spf.protection.outlook.com alone uses several of your 10 permitted DNS lookups. Add a few more third-party services and you can easily exceed the limit, causing SPF to return a PermError. Use our SPF Flattener to reduce your lookup count, and read our guide on fixing the SPF lookup limit for a full walkthrough.
• Third-party services breaking alignment. If you use services like Mailchimp, HubSpot, or Salesforce to send email on your behalf, they may send from their own domains rather than yours. This breaks DMARC alignment even if SPF and DKIM individually pass. You need to configure custom return-path domains and DKIM signing for each service to ensure alignment. Check our SPF vs DKIM vs DMARC guide for a detailed explanation of how alignment works.
• Subdomain policy considerations. By default, a DMARC record at the organisational domain applies to all subdomains. If you send email from subdomains (e.g. marketing.yourdomain.com), consider adding a sp= tag to your DMARC record to set an explicit subdomain policy, or publish separate DMARC records on subdomains that need different treatment.
• Shared or multi-tenant environments. If multiple organisations share a single Microsoft 365 tenant (common in managed service provider setups), ensure each domain has its own SPF, DKIM, and DMARC records. DKIM signing must be enabled per domain in the Defender portal.

Next steps

With SPF, DKIM, and DMARC configured for your Microsoft 365 tenant, here is what to do next:

• Monitor your DMARC reports. Review aggregate reports regularly to catch unauthorised senders and identify legitimate services that need configuration fixes. Our guide to understanding DMARC reports explains how to read them.
• Progress to p=reject. Do not stay on p=none indefinitely. The goal is to reach p=reject so that spoofed emails are blocked outright.
• Aim for a strong Security Grade. A Security Grade of Level 3 means your domain has full email authentication with enforcement, MTA-STS, DNSSEC, and valid TLS certificates. It is the benchmark for a fully protected domain.
• Read our complete guide to DMARC for a deeper understanding of the protocol and its tags.
• Learn about DKIM setup for other providers if you send email from additional services beyond Microsoft 365.