How to set up DMARC for Microsoft 365 and Office 365

The order of work

Work through these steps in order. Enforcement comes last because it depends on the rest.

1. SPF. Publish one TXT record at the root of your domain with include:spf.protection.outlook.com and your other senders, within 10 DNS lookups.
2. DKIM. Copy the two CNAME records the Microsoft Defender portal gives you, publish them at your DNS host, then turn on signing for the domain.
3. DMARC. Publish a TXT record at _dmarc that starts at p=none (monitoring only) and names a reporting address.
4. The onmicrosoft.com domain. If nobody sends from it, give it v=DMARC1; p=reject in the Microsoft 365 admin center.
5. Enforcement. Fix each sender your reports show failing, then move to p=quarantine (send fakes to spam) and then p=reject (refuse fakes).

The records are the same whatever your subscription is called: Office 365, Microsoft 365 or O365. Exchange Online is the mail service inside it, and it sends the mail these records describe.

Step 1: publish one SPF record that includes Microsoft 365

Adding your domain to Microsoft 365 already asked you for an SPF record, so check what is published before you add anything. A domain can have one SPF record. Two records make SPF return a permanent error, which counts as a fail for DMARC (Microsoft's SPF guidance).

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

Add the other services that send as your domain to the same record, before ~all. Each include: costs at least one of the 10 DNS lookups SPF allows, and includes nested inside it count too. Past 10, SPF fails with a permanent error.

Microsoft's include listed only IP ranges when we checked on 9 October 2026, so it costs 1 lookup. If your record needs more, our page on fixing too many SPF lookups sets out the options. Do not swap Microsoft's include for its IP ranges: Microsoft says its sending addresses change often.

Microsoft's example record ends in -all. Microsoft recommends hard fail for domains that also use DKIM and DMARC, so that DMARC can act on unsigned mail that fails SPF.

We suggest ~all on a domain that sends mail. Some receivers act on a hard fail before DMARC runs. Forwarded mail that DKIM would have passed can then be refused, and those refusals never reach your reports (RFC 9989 section 7.1). Our guide to SPF hard fail and soft fail sets out both views.

Two cases need more than the include. In an Exchange hybrid set-up, add the public IP addresses of on-premises servers that send mail as ip4: entries. Each subdomain that sends mail also needs its own SPF record, because subdomains do not inherit one.

Step 2: turn on DKIM signing in the Microsoft Defender portal

This step decides whether your Microsoft 365 mail survives enforcement. Microsoft signs mail from your onmicrosoft.com domain automatically, but it does not sign as your own domain until you set it up (Microsoft's DKIM guidance). A pass for yourtenant.onmicrosoft.com does not align with your From domain, so it does not count for DMARC.

Without your own signature, your mail passes DMARC on SPF alone, and SPF breaks when mail is forwarded. RFC 9989 section 7.4 says a domain at p=reject must not rely on SPF alone.

Turn it on in the portal

1. At security.microsoft.com, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings and select the DKIM tab.
2. In your domain's row, slide the toggle to Enabled. A Client error dialog opens because the DNS records do not exist yet. Select OK, and the status changes to CnameMissing.
3. Select the row to open the domain's details, and copy the two values under Publish CNAMEs.
4. Publish both CNAME records at your DNS host, exactly as shown. Microsoft can take a few minutes or longer to find them.
5. Back in the details, turn on Sign messages for this domain with DKIM signatures. The status should then read Signing DKIM signatures for this domain.

Copy the CNAME values, do not build them

selector1._domainkey  CNAME  selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft
selector2._domainkey  CNAME  selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

Microsoft introduced this format for new custom domains in May 2025. example.com becomes example-com, and the prefix is the custom part of your onmicrosoft.com domain. The partition character is a letter, such as r or n, that Microsoft assigns from its internal routing. Existing custom domains keep the older format, which ends in ._domainkey.<InitialDomainPrefix>.onmicrosoft.com. The two formats cannot coexist for one selector, so publish what your tenant shows.

Exchange Online PowerShell returns the same values, partition character included:

Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

When the CNAMEs resolve, Set-DkimSigningConfig -Identity example.com -Enabled $true turns signing on.

If signing will not turn on

A status stuck at CnameMissing usually means a DNS entry problem. Microsoft's DKIM guidance names the common ones:

• a host name with your domain on the end, which publishes selector1._domainkey.example.com.example.com
• a TXT record where a CNAME belongs
• a typing error in the target, such as a dot where a dash belongs

Keep both CNAMEs. Microsoft signs with one selector and switches to the other when the keys rotate. A checker may find a key behind only one of them. That is normal, so keep the other CNAME: the next rotation needs it.

If a checker reports a 1024-bit key, run Rotate-DkimSigningConfig -Identity example.com -KeySize 2048. The new key starts signing after four days. Only that selector changes, so rotate again later for the other one.

Other services that send as you need DKIM set up in each service. Our DKIM set-up steps by provider cover them. The DKIM checker on that page looks up selector1 and selector2 when your MX or SPF records name Microsoft.

Step 3: publish your DMARC record at _dmarc

Microsoft 365 has no portal page or PowerShell cmdlet for a custom domain's DMARC record (Microsoft's DMARC guidance). You publish it at your DNS host.

Host:  _dmarc
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Enter _dmarc on its own as the host. Many DNS hosts add your domain for you, so typing _dmarc.example.com creates _dmarc.example.com.example.com, which nobody queries. Publish one record, starting with v=DMARC1. It also covers subdomains that have no DMARC record of their own.

p=none is monitoring only. It asks receivers to take no DMARC action on failing mail, and receivers that report send aggregate reports to the rua= address.

Point it at a dedicated mailbox or a reporting service, not a person's inbox. An address on another domain needs that domain to publish an authorisation record first (RFC 9990 section 4). Our DMARC generator builds the record, and our guide to what DMARC is explains each tag.

Step 4: read the reports, then move to enforcement

Stay at p=none until your aggregate reports show each service that sends as you passing with aligned SPF or DKIM. Before p=reject, each one must also sign with aligned DKIM (RFC 9989 section 7.4). The gate is clean reports, not a date, though that section asks a domain whose users post to mailing lists for at least a month at p=none and as long again at p=quarantine. Our guide to moving from p=none to p=reject covers the steps in between, and How to read a DMARC RUA XML report explains each field.

Microsoft 365 sends aggregate reports, but no failure reports, so a ruf= address gets nothing from Microsoft. Reports come only from receivers that send them, so a quiet day is not proof that nothing was sent as you.

Leave pct= out of the record. Microsoft's DMARC guidance still shows pct= steps, but RFC 9989 removed the tag (Appendix A.6). Receivers on the older standard apply a value below 100 to only part of your failing mail, which leaves the rest at the weaker policy.

At p=reject, you ask receivers to refuse mail that fails DMARC, and each receiver makes the final call (RFC 9989 section 5.4). DMARC covers mail that uses your domain in the From address. It does nothing about lookalike domains.

Give your onmicrosoft.com domain a DMARC record

Every tenant has an initial domain ending in onmicrosoft.com, which Microsoft calls the MOERA domain (Microsoft Online Email Routing Address). Microsoft publishes its SPF record and signs its mail, but the DMARC record is yours to add. Microsoft hosts that zone, so you add the record in the Microsoft 365 admin center. Microsoft's DMARC guidance gives the same steps.

1. In the Microsoft 365 admin center, select Show all > Settings > Domains.
2. Select your onmicrosoft.com domain, then the DNS records tab.
3. Select Add record. Set Type to TXT (Text), TXT name to _dmarc and TXT value to v=DMARC1; p=reject. Leave TTL at 1 hour and select Save.

Microsoft recommends p=reject for this domain when nobody sends from it. If something does, start at p=none with a rua= address and work up, as for your main domain. Domains you own but do not send from need a reject policy too, at their own DNS host. Our guide to DMARC for parked domains has the records.

Microsoft 365 traps that break alignment

Services that send as you

Marketing platforms, CRMs, helpdesks and invoicing tools send from their own servers. Many use their own bounce domain, so SPF passes for their domain, not yours. Adding their include to your SPF record does not change that.

Set up DKIM signing with your domain in each service, or a custom return-path on your domain. Microsoft suggests a subdomain such as marketing.example.com for services you do not control, which also gets its own 10 lookups.

Forwarding and ARC

When someone forwards your mail, the forwarding server is not in your SPF record, so SPF fails at the next hop. An aligned DKIM signature usually survives unless the forwarder changes the message. That is why Step 2 comes before enforcement.

ARC (Authenticated Received Chain) lets a service that alters messages record the results it saw first. In Microsoft 365 you use it for mail coming in to your tenant. If a gateway or mailing list alters messages before they reach you, add it as a trusted ARC sealer. On the ARC tab of Email authentication settings, select Add, enter the d= domain from its ARC-Seal header and select Save (Microsoft's ARC guidance).

Gateways and hybrid mail flow

If your MX record points at a filtering service or an on-premises server, Microsoft sees that server as the sender. Turn on Enhanced Filtering for Connectors on the inbound connector so SPF, DKIM and DMARC are judged against the real source. Without it, your tenant does not apply the Honor DMARC record policy setting described below. While your MX points elsewhere, Microsoft also sends no aggregate reports about mail your tenant receives (Microsoft's DMARC guidance).

How Exchange Online handles DMARC on inbound mail

Your DMARC record asks other receivers how to treat your mail that fails DMARC. How your tenant treats other domains' policies is set in your anti-phishing policy (Microsoft's anti-phishing policy reference). In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Anti-phishing.

The setting is Honor DMARC record policy when the message is detected as spoof. Under it, you choose one action for senders at p=quarantine and one for senders at p=reject. In Microsoft's default policy the setting is on (Microsoft's recommended settings). Failing mail from p=quarantine senders is quarantined, and failing mail from p=reject senders is rejected. Check yours in Exchange Online PowerShell:

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

The Authentication-Results header shows the outcome. dmarc=fail action=oreject marks a failure from a sender at p=reject. Microsoft refuses such mail by default, so a copy that carries this header was quarantined or delivered instead. action=quarantine and action=none map to the other two policies. dmarc=bestguesspass means the sender's domain has no DMARC record, but the message would have passed if it had one.

If a legitimate sender keeps failing, Microsoft's DMARC guidance prefers a trusted ARC sealer. It calls an allow entry in the Tenant Allow/Block List temporary.

Check that it worked

Microsoft 365 has no page or cmdlet for managing a custom domain's DMARC record, so check it in DNS. In PowerShell:

Resolve-DnsName -Name _dmarc.example.com -Type TXT

Our DMARC checker validates the record against RFC 9989, analyses SPF and looks for DKIM keys at selector1 and selector2. Then run Get-DkimSigningConfig -Identity example.com: the domain should show Enabled as True and Status as Valid.

Last, send a message to a mailbox outside your organisation, because Microsoft does not sign mail between your own domains. In the Authentication-Results header of the copy that arrives, look for dkim=pass for your own domain and dmarc=pass. Our email header analyser reads the header for you.

Where ShieldMarc fits

ShieldMarc is a DMARC monitoring platform. Add your ShieldMarc address to rua=, and the Email page groups your reports by the service that sent the mail. Each provider gets one row, with the share of its mail that aligned on SPF and on DKIM. We publish the authorisation record that an external reporting address needs.

Before you tighten the policy, the Email page estimates how much legitimate mail a stricter policy would affect. It also calls out mail that passes on SPF alone.

On Professional, MSP and the 30-day trial, monitors also watch the set-up. DKIM monitors re-check selector1 and selector2 about once a day. They treat the waiting Microsoft selector as normal and email you when a key is removed, revoked or weakened.

DMARC health monitors email you when your domain's DMARC policy changes. Starter is free for one domain, with no time limit: create a free ShieldMarc account.

Frequently asked questions