DMARC setup for Microsoft 365 and Office 365

Microsoft 365 does not publish DMARC for your custom domain. It also does not enable custom-domain DKIM for you. Your DNS administrator must configure both.

This guide follows Microsoft’s current DMARC and DKIM documentation. We verified the steps in August 2026.

From the DMARC reports we process, the common Microsoft 365 failure is not Exchange Online itself. It is a second sender using the same From domain. Typical examples are a CRM, ticketing system, finance platform, or marketing service that was never configured for aligned DKIM.

What Microsoft 365 configures and what DNS owns

For a custom domain, your DNS administrator must:

• Publish or update the domain’s SPF record.
• Publish both DKIM CNAMEs and enable signing for the custom domain.
• Publish the domain’s DMARC record.

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.

A DNS check finds missing records. DMARC aggregate reports show whether real Microsoft 365 and third-party mail passes alignment.

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 authorizes Exchange Online Protection. The -all mechanism returns SPF fail for sources that do not match. It does not by itself force a receiver to reject the message.

Do not replace an existing SPF record without first identifying every sender. A domain can publish only one SPF record.

If you have other senders

Most companies send mail through more than Microsoft 365. Other sources include marketing platforms, CRM systems, and helpdesk software. Add each source that uses the domain as its SPF identity. Build and check the combined record with our free SPF generator.

Example with multiple senders:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:mail.zendesk.com -all

SPF permits at most 10 DNS-querying terms during one evaluation. Nested includes count too. Check the complete record with our free domain checker before you publish it.

Step 2: configure DKIM

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

Why the default signature is not enough

Microsoft signs mail from the initial onmicrosoft.com domain. Microsoft currently states that outbound mail from custom domains is not DKIM-signed with that custom domain until you configure it. An onmicrosoft.com signature does not align with a From address at company.com.

To fix this, you need to:

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

Finding your exact CNAME values

Do not build the CNAME targets from an example. Microsoft introduced a new target format for custom domains added after May 2025. It uses dkim.mail.microsoft and a tenant-specific partition character. Older domains can still use the earlier onmicrosoft.com format.

Get the two exact targets from the Defender portal or Exchange Online PowerShell:

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

Publish both records:

Type	Host	Value
CNAME	selector1._domainkey	The Selector1CNAME value from Microsoft
CNAME	selector2._domainkey	The Selector2CNAME value from Microsoft

Microsoft uses one selector for signing and keeps the other ready for key rotation.

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, read the error. Microsoft shows the required CNAME targets when keys are missing. Check the authoritative DNS response, wait for the records to propagate, and try again.

Step 3: configure DMARC

Now that SPF and DKIM are working, DMARC ties them together with a policy and reporting. If you want a reference on every DMARC tag, with examples, our record tags guide breaks them down.

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
• Your policy does not request a delivery change solely because DMARC failed

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

We often see a domain move to enforcement before its finance, support, or marketing sender is aligned. The resulting failure looks like a Microsoft 365 problem, but the affected mail never passed through Microsoft.

RFC 9989, section 5.1 says to start with p=none, analyze aggregate reports, and remediate legitimate unaligned streams before enforcement. The time required depends on how often each sender is used. Do not use a fixed calendar deadline as proof that a domain is ready.

The monitoring problem

DMARC reports are designed for machine processing.

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>

RFC 9989 recommends machine parsing because aggregate reports are XML. DMARCTrust receives the files, resolves sending sources, and shows SPF, DKIM, and alignment results over time.

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: modifying mail after it is signed

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

Microsoft documents that downstream systems, including some Exchange Server versions, can modify messages and affect DKIM. Test the final message after every outbound gateway, disclaimer service, and security relay.

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. Configure the sender’s domain-authentication feature and verify the final d= value in a delivered message.

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

Mistake 4: testing at the wrong point in the route

An upstream DKIM pass is not enough. A gateway can add a footer or rewrite signed headers after Microsoft signs the message. Inspect the copy received by an external mailbox. Do not assume that a connector command fixes content modification.

Mistake 5: forgetting subdomains

The parent DMARC policy applies to subdomains unless sp or a subdomain policy changes it. Authentication still follows the identifiers in each message. SPF looks up the envelope-sender domain. DKIM looks up the signing domain in d=. Under relaxed alignment, either can align through the same organizational domain. Test each subdomain mail stream instead of assuming the parent setup covers it.

The enforcement path

Move toward enforcement after reports account for every legitimate sender.

Phase 1: quarantine dry run

v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected];

This asks receivers to apply the next-lower policy while you watch for problems.

Phase 2: full quarantine

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

This asks receivers to treat failing mail as suspicious. Receivers still apply their own local policy.

Phase 3: reject

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

For domains whose users post to Internet mailing lists, RFC 9989 section 7.4 says they should not publish p=reject without first evaluating the interoperability impact. The RFC recommends at least one month at p=none, then an equally long period at p=quarantine, before such a domain considers reject.

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.

Add the domain to DMARCTrust, copy its reporting address into rua, and wait for participating receivers to send reports. Reporting timing varies by receiver and traffic.

Microsoft 365 authenticates its own mail stream. DMARC aggregate reports reveal other systems that participating receivers observe using the same From domain.

FAQ

Does Microsoft 365 include DMARC?

Microsoft 365 evaluates DMARC for inbound mail, but it does not publish a DMARC record for your custom domain. You publish the TXT record at _dmarc in your authoritative DNS zone.

What are the Microsoft 365 DKIM CNAME records?

The hosts are selector1._domainkey and selector2._domainkey. The targets are tenant-specific. Get them from Microsoft Defender or Get-DkimSigningConfig. Do not copy an old onmicrosoft.com example.

Does Office 365 DMARC require both SPF and DKIM to pass?

DMARC passes when SPF or DKIM passes with identifier alignment. Configure both. DKIM is important because SPF often fails after forwarding.