Skip to content
iBlockSpam
Setup guides

How do you set up DMARC for Microsoft 365 domains?

By iBlockSpam Team How we check our guides Updated 9 min read 6 sources
Short answer

Set up SPF and DKIM signing first. Then publish a _dmarc TXT record for each custom domain at your DNS host, starting with p=none and a reporting address. If you don't send from your onmicrosoft.com domain, add v=DMARC1; p=reject to it in the Microsoft 365 admin center. Move to quarantine, then reject, at least a month apart.

Microsoft 365 takes care of SPF and DKIM for your onmicrosoft.com domain, but not DMARC. For your own domains, it has no switch for DMARC at all: you publish a DNS record, and the receiving servers do the rest.

This guide covers both kinds of domain, the safe order of steps, and the Microsoft 365 settings that decide what happens to DMARC failures in your own inbox. If DMARC itself is new to you, read what DMARC is first.

What do you need before publishing DMARC in Microsoft 365?

DMARC passes when SPF or DKIM passes for a domain that aligns with the visible From address. So both have to be right before any DMARC policy can help you (Microsoft Learn).

Domain type SPF DKIM DMARC
yourtenant.onmicrosoft.com Set up by Microsoft Signed automatically by Microsoft You add it in the Microsoft 365 admin center
Custom domain (example.com) You publish it at your DNS host You publish two CNAMEs and turn signing on You publish it at your DNS host
Parked domain (no mail) v=spf1 -all Not needed v=DMARC1; p=reject

For custom domains, check three things first:

  1. SPF. Your record includes Microsoft 365 (include:spf.protection.outlook.com) and every other service that sends as you. Our Microsoft 365 SPF page shows the exact include.
  2. DKIM. Microsoft says that "currently, no DKIM signing occurs for outbound mail from custom domains" until you configure DKIM for them, so DKIM can't help those messages pass DMARC. A signature from the onmicrosoft.com domain wouldn't help either: Microsoft's own alignment table shows contoso.onmicrosoft.com failing against user@contoso.com. Our DKIM setup guide walks through the CNAMEs.
  3. Other senders. Invoicing tools, CRMs, newsletters, website forms and scanners all need aligned SPF or DKIM of their own.

To confirm DKIM signing is on, open the Defender portal at Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then the DKIM tab (https://security.microsoft.com/authentication?viewid=DKIM). Or check in Exchange Online PowerShell:

Get-DkimSigningConfig |
  Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

If a domain shows Enabled : False and its CNAMEs are already published, turn signing on:

Set-DkimSigningConfig -Identity example.com `
  -Enabled $true

How do you add DMARC for the onmicrosoft.com domain?

Every tenant has an onmicrosoft.com domain, known as the Microsoft Online Email Routing Address (MOERA) domain. Microsoft says you need to create its DMARC record yourself. It also says parked domains should declare that no mail ever comes from them, and that "this directive includes the *.onmicrosoft.com domain if you aren't using it for email" (Microsoft Learn).

  1. In the Microsoft 365 admin center (https://admin.microsoft.com), select Show all > Settings > Domains.
  2. Select the onmicrosoft.com domain by clicking anywhere in its row other than the check box.
  3. Open the DNS records tab and select Add record.
  4. In the Add a custom DNS record flyout, check that Type is TXT (Text).
  5. Set TXT name to _dmarc and TXT value to v=DMARC1; p=reject.
  6. Leave TTL at 1 hour and select Save.

If you do send from the onmicrosoft.com domain, for example from a shared mailbox nobody renamed, fix that first or use the staged rollout below. Microsoft's example with reporting is v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Note that ruf (failure) reports are sent by few receivers.

How do you publish DMARC for a custom domain?

Microsoft states plainly that "there are no admin portals or PowerShell cmdlets in Microsoft 365" to manage DMARC records for custom domains. You add the record wherever your domain's DNS is hosted, which is often your registrar.

  1. Sign in to your DNS host and open the zone for example.com.
  2. Create a TXT record with host (name) _dmarc. Some hosts want the full name, _dmarc.example.com.
  3. Set the value to a monitoring policy with a reporting address:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
  1. Save the record. Make sure there's only one DMARC TXT record at _dmarc; two records cause errors at receivers.
  2. Check it with the DMARC Checker, or from Windows PowerShell:
Resolve-DnsName -Name "_dmarc.example.com" `
  -Type TXT | Select-Object -ExpandProperty Strings

Microsoft recommends sending reports to a dedicated mailbox or Microsoft 365 Group, not a person's inbox, and naming specific people to read them. If the rua address is on a different domain, that domain must publish an authorization record such as example.com._report._dmarc with the value v=DMARC1;, or receivers won't send reports there.

The DMARC Record Generator builds the record for each stage. For every tag, see DMARC record examples.

How do you roll out from p=none to p=reject?

Microsoft's stated goal is p=reject for all your custom domains and subdomains, reached gradually so receivers don't reject good mail (Microsoft Learn). It suggests starting with a low-volume domain or subdomain and saving the parent domain for last.

Stage Record Stay at least Move on when
1. Monitor v=DMARC1; p=none; rua=mailto:... A month Every legitimate sender passes aligned SPF or DKIM
2. Quarantine, test mode (optional) v=DMARC1; p=quarantine; t=y; rua=mailto:... Until no new legitimate failures Reports stay clean
3. Quarantine v=DMARC1; p=quarantine; rua=mailto:... A month No complaints of lost mail
4. Reject v=DMARC1; p=reject; rua=mailto:... Ongoing Keep reading reports

Why not use pct like Microsoft's examples?

Microsoft's article still shows pct=10, pct=25 and so on for a gradual rollout, because its syntax section follows RFC 7489. That standard is now obsoleted by RFC 9989, which removed pct and added t=y. A test-mode record asks receivers to apply the policy one level down: reject is treated as quarantine, and quarantine as normal handling. Receivers on the old standard ignore t. So treat stage 2 as real quarantine at some receivers, and don't count on any partial rollout. Our DMARC rollout guide covers the timing in more detail.

What to fix during monitoring

Each aggregate report lists sending IPs, message counts and whether SPF and DKIM aligned. Microsoft's own troubleshooting table points to the usual causes:

  • A service sends as you with its own domain. SPF passes for the service's bounce domain, DKIM signs with the service's domain, and DMARC fails. Fix it with custom DKIM at the service, or a custom return-path on your domain.
  • Forwarding. Forwarded mail often fails SPF, and DKIM breaks if the body changes. Small volumes from mailing list servers are usually this, not an attack.
  • Strict alignment. aspf=s or adkim=s fails subdomain senders. Keep the relaxed default unless you have a reason.

The DMARC Report Analyzer reads the XML in your browser. Our guide to reading DMARC reports explains each field.

Subdomains and parked domains

A DMARC record covers subdomains, including ones that don't exist, unless a subdomain has its own record. Microsoft suggests putting bulk mail services on a subdomain such as marketing.example.com, so their problems don't hurt your main domain's reputation. Each sending subdomain still needs its own SPF and DKIM. For domains that never send mail, publish v=DMARC1; p=reject; and the SPF record v=spf1 -all, as covered in protecting parked domains.

Does p=reject change how Microsoft 365 sends your mail?

It can. Microsoft says outbound mail from Microsoft 365 domains that fails DMARC at the destination is routed through its high-risk delivery pool when your policy is p=reject or p=quarantine, and "there's no override for this behavior." That pool is meant for mail that looks risky, so fix failing senders before you enforce, not after.

How does Microsoft 365 handle DMARC on mail you receive?

Your DMARC record protects other people from fakes of your domain. A separate setting decides what your tenant does with incoming mail that fails the sender's policy. It lives in anti-phishing policies (Microsoft Learn):

  1. In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Anti-phishing (https://security.microsoft.com/antiphishing).
  2. Open a policy and select Edit in the actions section.
  3. Check Honor DMARC record policy when the message is detected as spoof. It's selected by default.
  4. Review the two actions. For p=quarantine, the default is Quarantine the message (the alternative is the Junk Email folder). For p=reject, the default is Reject the message (the alternative is quarantine).

To review every policy at once in PowerShell:

Get-AntiPhishPolicy |
  Format-List Name, HonorDmarcPolicy, `
    DmarcQuarantineAction, DmarcRejectAction

If someone turned the setting off, turn it back on with explicit actions:

Set-AntiPhishPolicy -Identity "Office365 AntiPhish Default" `
  -HonorDmarcPolicy $true `
  -DmarcQuarantineAction Quarantine `
  -DmarcRejectAction Reject

Policies created by the Standard and Strict presets can't be edited here; change them on the Preset security policies page. Allow up to 30 minutes for policy changes to apply.

A message rejected this way shows dmarc=fail action=oreject in its Authentication-Results header. Our guide to Microsoft 365 spam headers explains that and the compauth result.

What if your MX points to a gateway?

If a filtering service sits in front of Microsoft 365, Microsoft says the Honor DMARC policy setting applies only when Enhanced Filtering for Connectors is on for the inbound connector. Without it, Microsoft 365 sees the gateway's IP as the source and can't judge the original sender. Microsoft also doesn't send DMARC aggregate reports for mail that arrived through another service first. Our Enhanced Filtering guide shows how to set it up.

Next steps

  1. Confirm SPF and DKIM for each custom domain with the SPF Checker and DKIM Checker.
  2. Add v=DMARC1; p=reject to your onmicrosoft.com domain if nobody sends from it.
  3. Publish p=none with a dedicated rua mailbox on each custom domain, and read reports for at least a month.
  4. Move to p=quarantine, then p=reject, at least a month apart, starting with your quietest domain.
  5. Check that Honor DMARC record policy is on in every anti-phishing policy, and that Enhanced Filtering is on if a gateway such as iBlockSpam sits in front of Microsoft 365.

With the record in place, iBlockSpam's DMARC monitoring can collect the aggregate reports for your Microsoft 365 domain and show which senders pass before you tighten the policy.

Browse more setup guides.

Frequently asked questions

Does Microsoft 365 create a DMARC record for me?

No. Microsoft 365 configures SPF and DKIM for your onmicrosoft.com domain, but you must add its DMARC record yourself in the Microsoft 365 admin center. For custom domains, Microsoft has no portal or cmdlet to manage DMARC. You publish the _dmarc TXT record at your registrar or DNS host.

Should the onmicrosoft.com domain have a DMARC record?

Yes. Microsoft says to publish DMARC for the onmicrosoft.com domain even if you only use custom domains. If nobody sends from it, use v=DMARC1; p=reject so nobody else can send convincing mail as it. Add it on the domain's DNS records tab in the Microsoft 365 admin center.

Does Microsoft 365 send DMARC aggregate reports?

Yes, to domains with a valid rua address, as long as the receiving organization's MX record points directly to Microsoft 365. If mail passes through another service first, Microsoft doesn't send aggregate reports for it. Microsoft 365 never sends forensic (failure) reports, even when a ruf address is published.

What happens to inbound mail that fails the sender's DMARC policy in Microsoft 365?

With the default anti-phishing settings, Microsoft 365 honors the sender's policy. Mail failing p=quarantine is quarantined, and mail failing p=reject is rejected. Admins can change either action per anti-phishing policy. A p=none failure gets no DMARC-specific action, though other filtering still applies.

Why does Microsoft's DMARC guide still show pct=?

Microsoft's examples were written for RFC 7489, which defined pct for partial rollout. RFC 9989 replaced pct with t=y test mode. Receivers following the older standard may still honor pct and newer ones may honor t, so don't rely on either. Treat each stage as if it applies to all mail.

Corrections and significant updates

  • : Corrected the DKIM step: Microsoft 365 doesn't DKIM-sign mail from custom domains until you configure DKIM; it doesn't fall back to signing with the onmicrosoft.com domain.

Sources

  1. Microsoft Learn: Set up DMARC to validate email in Microsoft 365
  2. Microsoft Learn: How to use DKIM for email in your custom domain
  3. Microsoft Learn: Anti-phishing policies in Microsoft 365
  4. Microsoft Learn: Configure anti-phishing policies for all cloud mailboxes
  5. Microsoft Learn: Enhanced Filtering for Connectors in Exchange Online
  6. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

See how your domain measures up

Run a free Email Health Check: MX, SPF, DKIM, DMARC and transport security in one scan, with the raw records shown. No sign-up.

Keep reading