How to set up DMARC for Office 365 and Microsoft 365

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.

Office 365, Microsoft 365 and Exchange Online: which name applies

Microsoft began renaming its Office 365 subscriptions to Microsoft 365 in April 2020, and both names are still in daily use across UK IT teams. You will meet O365 and M365 as shorthand, and Exchange Online for the mail service itself, which is the part of the subscription that actually sends and receives your email. For email authentication none of that matters: the SPF record, the DKIM CNAMEs and the DMARC record are identical whichever name your licence carries and whichever abbreviation your colleagues use. The Office 365 name has not disappeared either, which is why the portal you use to switch DKIM on belongs to Microsoft Defender for Office 365.

One case genuinely does differ. In an Exchange Server hybrid deployment, some mail leaves through an on-premises server rather than through Exchange Online, and include:spf.protection.outlook.comdoes not cover it. Microsoft’s guidance for that scenario is to add the public IP addresses of your on-premises servers to the SPF record alongside the include. DKIM signing likewise applies only to mail that genuinely travels out through Exchange Online, so anything leaving by another route has to be signed wherever it leaves. The rest of this guide assumes mail sent from Exchange Online.

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.

Read your CNAME values, do not build them from a template

Custom DKIM uses two CNAME records that point at Microsoft’s signing infrastructure. Microsoft changed the format of those records in May 2025, and the current one contains a value you cannot work out for yourself, so read the records from your own tenant rather than filling in a template. For new custom domains the format is:

You can fill in two of the three placeholders yourself. <CustomDomainWithDashes> is your domain with the full stops replaced by hyphens, so example.com becomes example-com. <InitialDomainPrefix> is the custom part of the .onmicrosoft.com domain you enrolled with, so contoso.onmicrosoft.com gives contoso. The third, <DynamicPartitionCharacter>, is a single character such as r or n that Microsoft assigns automatically when you add the domain and enable DKIM. It comes from Microsoft’s internal routing, it is not configurable, and there is no way to derive it from your domain or your tenant name. That is why a fill-in-the-blanks CNAME copied from an older guide will not match what your tenant expects.

Older tenants see something different, and that is correct for them. Custom domains that were already signing before the change, and the .onmicrosoft.com initial domain itself, continue to use the previous format, which ended at ._domainkey.yourtenant.onmicrosoft.com. The old and new formats cannot coexist for the same selector, so do not mix them and do not rewrite a working record by hand. Publish exactly what your own tenant reports for that domain.

Enable signing in the Microsoft Defender portal

1. Go to the Microsoft Defender portal (security.microsoft.com).
2. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then select the DKIM tab.
3. Find your custom domain in the list and try to switch its toggle to enabled. Microsoft generates the key pair, the attempt does not complete because the DNS records do not exist yet, and the status becomes CnameMissing.
4. Open the domain to see its details and copy the two values from the Publish CNAMEs section, then publish them at your DNS host exactly as given.
5. Once the records resolve, return to the domain and toggle Sign messages for this domain with DKIM signatures to enabled.

If you would rather not click through the portal, Exchange Online PowerShell returns the same values, including the partition character Microsoft assigned to that domain:

A CnameMissing status that will not clear is almost always a DNS problem rather than a Microsoft one: the host name entered with the domain appended to it, a TXT record published where a CNAME was needed, or the records added to the wrong zone. Compare what is published against the portal values before raising a ticket.

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.

Do not forget your .onmicrosoft.com domain

Every tenant has a Microsoft Online Email Routing Address domain: the .onmicrosoft.com one you were given when you enrolled. SPF and DKIM are already configured for it by Microsoft, but DMARC is not, and it is the one domain you cannot fix at your DNS host, because Microsoft owns the zone. Its record goes in the Microsoft 365 admin center instead. Go to Show all > Settings > Domains, select the .onmicrosoft.com domain, open the DNS records tab and choose Add record. Set the type to TXT, enter _dmarc as the name and v=DMARC1; p=reject as the value. If you do send mail from that domain, start at p=none with a rua= address and work up to enforcement as you would for any other domain.

The same reasoning applies to domains you own but never send from. A registered domain with no DMARC record is a free identity for anyone who wants to use your name, so publish a reject policy on it whether or not it sits in your tenant. Our guide to DMARC for parked domains covers the records to use.

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.

How to check DMARC on Office 365

This is where a lot of administrators lose an afternoon, so it is worth being blunt. There is no page in the Microsoft 365 or Defender portals that shows the DMARC record for a custom domain, and no PowerShell cmdlet that returns it. Microsoft states this plainly in its own documentation. Your DMARC record is an ordinary TXT record at whoever hosts your DNS, and that is the only place it exists. If you are looking for a DMARC screen inside Microsoft 365, you will not find one. The single exception is the .onmicrosoft.com domain described above, whose record is added in the admin centre because Microsoft holds that zone.

To confirm the record is live, query it yourself. From a command prompt or from PowerShell:

Our DMARC Checker runs the same lookup, validates the syntax and checks SPF and DKIM in the same pass, and our DNS Lookup tool shows the raw TXT and CNAME records if you want to see exactly what is published rather than a verdict about it.

When a checker says no DMARC record found and you are certain you added one, there are three usual causes. The first is that the record is at the wrong name: many DNS hosts append the zone for you, so entering _dmarc.yourdomain.com as the host produces _dmarc.yourdomain.com.yourdomain.com, which nothing will ever query. Enter _dmarc on its own. The second is more than one _dmarc TXT record, often a leftover from a previous vendor; make sure only one exists. The third is a value that does not begin with v=DMARC1, which is required before anything else in the record, so receivers do not recognise it as DMARC at all. If none of those apply, give DNS time to propagate and check again.

A published record is only half the job, because DMARC passes on the back of an aligned SPF or DKIM result rather than on its own. Confirm that signing is genuinely switched on for the domain with Get-DkimSigningConfig, which reports the enabled state and status next to the CNAME values Microsoft expects to find. For the wider picture, our Security Grade assesses DMARC, SPF, DKIM, MTA-STS, DNSSEC and TLS certificates in one scan, so you can see where the domain stands overall.

The last check is a real message. Send one from your Microsoft 365 mailbox to an external address, open the copy that arrives and read the Authentication-Results header. It states each result in turn: spf=, dkim=, dmarc=and Microsoft’s own composite verdict, compauth=. A DMARC pass here is an aligned pass, which is the thing you were actually trying to achieve. Paste the headers into our Email Header Analyser if you would rather not read them by eye.

Enable inbound DMARC enforcement in Microsoft 365

Everything above concerns mail you send. The other half of the job is what Microsoft 365 does with the DMARC policies other people publish, and that is governed by your anti-phishing policy rather than by DNS. The setting is Honor DMARC record policy when the message is detected as spoof, found under Email & collaboration > Policies & rules > Threat policies > Anti-phishing. With it turned on, two further settings decide what actually happens: one action for senders publishing p=quarantine and a separate one for senders publishing p=reject.

In Microsoft’s default anti-phishing policy, all three are already set the way most organisations would want them. Honouring DMARC is on, quarantine-policy senders are quarantined and reject-policy senders are rejected, and those are the same values Microsoft recommends for both its Standard and Strict presets. Most tenants are therefore already enforcing inbound DMARC, so the useful exercise is confirming it rather than assuming it either way. From Exchange Online PowerShell:

Two dependencies are worth knowing. Spoof intelligence handles the implicit failures that composite authentication catches, while these DMARC actions handle explicit authentication failures; turning spoof intelligence off does not switch DMARC enforcement off, but it does remove the implicit checks, so leave it on. And if your MX record points at a gateway sitting in front of Microsoft 365 rather than at Microsoft directly, the honour-DMARC setting only applies when Enhanced Filtering for Connectors is enabled on the connector that receives your inbound mail.

You can see the result in the Authentication-Results header of any inbound message. dmarc=fail action=oreject means the sender published p=reject and the message was rejected during the SMTP conversation. action=quarantine means it was quarantined or junked, and action=none means the sender is on p=none, so DMARC took no action and the rest of the filtering stack decided. You will also see dmarc=bestguesspass from time to time: that is Microsoft inferring a pass because the sending domain has published no DMARC record at all, which is a fair description of what your own domain looked like before you started.

When a legitimate sender keeps failing, resist the urge to reach for an allow entry. Forwarding and mailing lists break SPF by design, and the supported fix is to configure the intermediary as a trusted ARC sealer, which Microsoft prefers over a Tenant Allow/Block List entry. Allow entries there expire after 30 days in any case, so they postpone the problem rather than solve it.

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.
• Your tenant quietly stops sending aggregate reports. As a receiver, Microsoft 365 generates DMARC aggregate reports for the domains whose mail it accepts, but only while the MX record for the domain points directly at Microsoft 365. Route inbound mail through a gateway or an on-premises server first, as hybrid deployments do, and those reports stop. Enabling Enhanced Filtering for Connectors on the inbound connector restores correct source identification for SPF, DKIM and DMARC. Separately, Microsoft never sends forensic reports at all, so a ruf= address in your own record will never be filled in by Microsoft, whatever other receivers do.

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. An A or A+ on the Security Grade means enforced DMARC, restrictive SPF, valid SSL, and hardening like MTA-STS, DNSSEC and CAA in place. 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.
• If you run both platforms, or you are moving between them, our DMARC for Google Workspace guide covers the same steps for Gmail, including how both platforms fit into the single SPF record a domain is allowed to publish.