DMARC setup for Microsoft 365: the complete guide for 2026

Microsoft 365 is the most popular business email platform. It’s also one of the most commonly misconfigured for email authentication.

The assumption is reasonable: you’re paying Microsoft, they handle security. But that’s not how it works. Microsoft provides the tools. You have to use them.

This guide walks through DMARC setup for Microsoft 365, based on Microsoft’s official documentation. By the end, you’ll have SPF, DKIM, and DMARC configured correctly, and you’ll know what’s actually happening with your email.

The problem: Microsoft 365 doesn’t do this for you

Here’s what Microsoft 365 does by default:

• Does not enable DKIM signing for your custom domain (you must publish CNAMEs and turn it on)
• Does not publish an SPF record for your custom domain
• Creates no DMARC record whatsoever

Without DKIM enabled for your custom domain, mail sent as [email protected] has no aligned DKIM signature. DMARC can still pass via SPF alignment, but you’re relying on SPF alone, which is brittle with forwarding and third-party senders.

Most admins don’t realize this until they check their domain with a DMARC checker and see the gaps. Or worse, until their emails start landing in spam because receiving servers no longer trust unauthenticated senders.

Before you start: prerequisites

You’ll need:

1. Admin access to Microsoft 365 (Global Admin or Exchange Admin)
2. DNS access for your domain (wherever you manage DNS records)
3. A verified custom domain in Microsoft 365 (not the default onmicrosoft.com)

Setup order matters. Configure SPF first, then DKIM, then DMARC. Each layer builds on the previous one.

Step 1: configure SPF

SPF tells receiving servers which IP addresses are authorized to send email for your domain. For Microsoft 365, you need a TXT record that includes Microsoft’s sending infrastructure.

The DNS record

Create a TXT record at your domain’s root:

Type	Host	Value
TXT	@	v=spf1 include:spf.protection.outlook.com -all

That include:spf.protection.outlook.com covers all of Microsoft’s sending servers. The -all at the end tells receivers to reject email from any other source. Make sure you’re not using other tools that send email as your domain. Our product helps you map all your sources.

If you have other senders

Most companies use more than just Microsoft 365. Marketing tools, CRM systems, helpdesk software. Each one that sends email as your domain needs to be in your SPF record. Build a proper SPF record with our free SPF generator.

Example with multiple senders:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:sendgrid.net -all

SPF has a 10 DNS lookup limit. Microsoft’s include uses 2-3 lookups. Add too many services and you’ll hit a PermError, breaking SPF entirely. Check your SPF with our free domain checker to see your current lookup count.

Step 2: configure DKIM

DKIM adds a cryptographic signature to your outgoing emails. This is where most Microsoft 365 setups fail.

Why the default doesn’t work

Microsoft automatically signs email with DKIM, but using your onmicrosoft.com domain. When you send as [email protected], the DKIM signature says company.onmicrosoft.com. The domains don’t align.

To fix this, you need to:

1. Publish CNAME records in your DNS
2. Enable DKIM signing in Microsoft Defender

The CNAME records

Microsoft uses two selectors for DKIM rotation. You need to create two CNAME records:

Type	Host	Value
CNAME	selector1._domainkey	selector1-company-com._domainkey.company.onmicrosoft.com
CNAME	selector2._domainkey	selector2-company-com._domainkey.company.onmicrosoft.com

Replace company-com with your domain (using dashes instead of dots) and company.onmicrosoft.com with your Microsoft 365 tenant domain.

Finding your exact CNAME values

If you’re unsure of the exact values, use Exchange Online PowerShell:

Connect-ExchangeOnline
Get-DkimSigningConfig -Identity company.com | Format-List Selector1CNAME,Selector2CNAME

This returns the exact CNAME values you need to publish.

Enabling DKIM signing

Publishing the CNAMEs isn’t enough. You must enable signing in the Microsoft 365 Defender portal:

1. Go to security.microsoft.com
2. Navigate to Email & collaboration then Policies & rules then Threat policies
3. Select Email authentication settings then DKIM
4. Click on your domain
5. Toggle Sign messages for this domain with DKIM signatures to Enabled

If the toggle fails, your CNAME records haven’t propagated yet. DNS changes can take up to 48 hours, though usually it’s faster.

Step 3: configure DMARC

Now that SPF and DKIM are working, DMARC ties them together with a policy and reporting.

The DNS record

Create a TXT record at _dmarc.yourdomain.com:

Type	Host	Value
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:[email protected];

Replace [email protected] with your DMARCTrust reporting address (you’ll get this when you add your domain).

Starting with p=none

The p=none policy means “monitor but don’t enforce.” You need to see what’s happening before you block anything.

With p=none:

• Receiving servers still check SPF, DKIM, and DMARC alignment
• They send you aggregate reports about pass/fail rates
• They deliver the email regardless of the result

This monitoring phase reveals third-party services sending as your domain that you forgot about, misconfigured systems that fail authentication, shadow IT that marketing or sales set up without telling you, and actual spoofing attempts against your domain.

Why you can’t skip monitoring

Every week, we see companies jump straight to p=reject because they’re confident their setup is correct. Then they discover their invoicing system, their event platform, or their CEO’s personal newsletter tool all fail DMARC. That’s the Shadow IT problem we talk about often.

Blocking legitimate email is worse than having no DMARC at all. Start with p=none, monitor for 2-4 weeks, fix what’s broken, then move toward enforcement.

The monitoring problem

Here’s the thing about DMARC: the reports are useless without a parser.

DMARC aggregate reports arrive as XML files, gzipped, attached to emails. They look like this:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1706140800</begin><end>1706227199</end></date_range>
  </report_metadata>
  <record>
    <row>
      <source_ip>192.0.2.1</source_ip>
      <count>127</count>
      <policy_evaluated>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

Now imagine receiving dozens of these daily, from every major email provider. Gmail, Microsoft, Yahoo, Apple, corporate mail servers. Each with different formats, different compression, different reporting intervals.

You’re not going to read them manually. Nobody does.

This is why monitoring tools exist. DMARCTrust parses every report automatically, identifies sending sources, shows you alignment rates, and alerts you when something breaks.

Without monitoring, you’re flying blind. You’ve configured DMARC, but you have no idea if it’s working.

Common Microsoft 365 mistakes

Mistake 1: assuming DKIM is enabled

Publishing CNAME records isn’t enough. You must toggle DKIM on in the Defender portal. We see this constantly: the DNS is perfect, but Microsoft never starts signing because nobody flipped the switch.

Mistake 2: mail flow rules that break DKIM

Disclaimers, footer modifications, header rewrites. If your Microsoft 365 tenant modifies messages after DKIM signing, the signature becomes invalid.

Check your mail flow rules. If you’re adding disclaimers, apply them before signing or accept that those messages will fail DKIM.

Mistake 3: third-party senders with wrong alignment

Your marketing platform sends as [email protected], but their DKIM signature says d=sendgrid.net. The domains don’t align. DMARC fails. This is explained in detail in our article on DMARC alignment.

The fix varies by provider. SendGrid, Mailchimp, and HubSpot let you configure custom DKIM with your domain. Salesforce requires Organization-Wide Email Addresses with proper authentication. Zendesk and Freshdesk have custom DKIM options in their settings.

Each third-party sender needs its own DKIM configuration. Your DMARC reports will show you which ones are failing.

Mistake 4: connectors stripping headers

If you route mail through security gateways or third-party filters, connectors can strip authentication headers. This breaks both SPF and DKIM.

In Exchange Online PowerShell:

Set-InboundConnector -Identity "Your Connector" -RestrictDomainsToCertificate $true -RequireTls $true

Make sure ARC-Seal and DKIM-Signature headers survive each hop.

Mistake 5: forgetting subdomains

DMARC policy on company.com applies to all subdomains by default. But SPF and DKIM don’t inherit. If you send from mail.company.com or marketing.company.com, each subdomain needs its own SPF and DKIM records.

The enforcement path

Once you’ve monitored for 2-4 weeks and fixed any issues, you can move toward enforcement:

Phase 1: partial quarantine

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected];

This quarantines (spam folders) 10% of failing messages. The other 90% still get delivered while you watch for problems.

Phase 2: full quarantine

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];

All failing messages go to spam. Watch your support tickets for complaints.

Phase 3: reject

v=DMARC1; p=reject; rua=mailto:[email protected];

Failing messages are blocked entirely. This is the goal. Attackers can’t spoof your domain anymore.

Don’t rush this. The path from p=none to p=reject typically takes 4-8 weeks, depending on your sending complexity.

Check your setup

Run your domain through our free DMARC checker. In seconds, you’ll see whether SPF, DKIM, and DMARC records exist and if they’re configured correctly.

But checking is just a snapshot. Microsoft 365 sends email constantly, and things break: someone adds a new service, a connector strips headers, a marketing tool misconfigures DKIM. Without continuous monitoring, you won’t know until your emails start bouncing.

This is why every Microsoft 365 domain needs DMARCTrust. Add your domain, get your unique reporting address, update your DMARC record. Within 48 hours, you’ll see exactly who’s sending as your domain and whether they’re passing authentication.

Microsoft 365 gives you the infrastructure. DMARCTrust gives you the visibility. You need both.