Setting Up DMARC on Office 365: Step by Step

Why Microsoft 365 Is Different

Microsoft 365 looks simple from the outside — one tenant, one onmicrosoft.com namespace, one SPF include. The reality is messier. Exchange Online runs on shared infrastructure that also delivers mail for thousands of other tenants, tenant DKIM is off by default, and most real-world M365 environments accumulate relay connectors, on-prem Exchange servers, third-party security gateways, and direct-send applications that quietly bypass the control plane you think you're configuring.

All of this matters for DMARC because DMARC does not care what tenant your mail came from. It cares whether the domain that signed the message (or the domain in the envelope sender) aligns with the From: header. Out of the box, Microsoft 365 gets one of those two right — SPF — because spf.protection.outlook.com is the envelope sender for your tenant's outbound flow. DKIM, the more durable of the two, is not configured for your domain until you turn on tenant DKIM and publish the CNAMEs Microsoft generates.

This is the first big difference from Google Workspace. Google's DKIM is a one-click enable and a single TXT record. Microsoft's involves two rotating selectors, CNAMEs that point back into onmicrosoft.com, and a d= value that defaults to your tenant's *.onmicrosoft.com domain until you explicitly flip the switch. Messages signed with d=tenant.onmicrosoft.com will not align with a From: header of yourdomain.com. They pass DKIM. They fail DMARC.

Hybrid deployments make it worse. If you route outbound mail from on-prem Exchange through Exchange Online, the on-prem server is the originating host, EXO is a relay, and the SPF evaluation depends on which connector you're using and whether header rewriting is enabled. Direct-send applications — scanners, printers, line-of-business apps that send SMTP straight to *.mail.protection.outlook.com — bypass your tenant's connector rules entirely and often forget to authenticate at all.

Before you publish a DMARC record, internalize that Microsoft 365 is not one sending surface. It's at least three: Exchange Online, anything relayed through EXO, and anything sending direct. Each one has its own alignment story.

Step-by-Step DNS Setup

Your DMARC record lives at _dmarc.yourdomain.com as a single TXT record. How you publish it depends on who runs DNS for the domain.

Path A: External DNS (most common)

Most organizations keep authoritative DNS at their registrar or a dedicated provider (Cloudflare, Route 53, DNSimple, GoDaddy, NS1). You add the DMARC record there, not in the M365 admin center. The record:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:<token>@rua.mxdns.io; fo=1"

Notes on the mechanics:

• The TXT record name is _dmarc.yourdomain.com — the underscore is required.
• Set TTL to 3600 (1 hour) while you iterate. Drop to 86400 after the record stabilizes.
• Quote the value as a single string. Some DNS UIs add quotes automatically; others require you to type them. Never split the record across multiple strings unless it exceeds 255 characters, which a DMARC record rarely will.
• Wait for propagation before verifying. Authoritative DNS propagates in seconds, but public resolvers cache negative responses, so a dig against 8.8.8.8 may still return nothing for a few minutes.

Path B: Microsoft 365 as your DNS provider

A small minority of tenants buy the domain through Microsoft or delegate DNS to Microsoft's name servers. If ns1-01.azure-dns.com (or similar) shows up in your whois output, you're in this bucket.

1. Sign in to the Microsoft 365 admin center.
2. Go to Settings → Domains.
3. Click the domain you want to protect.
4. Open the DNS records tab.
5. Add a custom TXT record with name _dmarc and the value above.

Microsoft's UI will scope the name to the domain automatically — enter _dmarc, not the full FQDN.

Either path ends at the same place: a single TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none and an rua= address. Start at p=none. Do not start at quarantine or reject. Enforcement without reporting data is how legitimate email gets blocked.

Verify the Record With the DMARC Checker

Run the mxio DMARC Checker against your domain as soon as the TXT record is live. A successful result shows the parsed tags, the reporting address, and no warnings.

What M365-specific failures look like in the checker:

• "No DMARC record found" usually means the TXT record was added to the wrong name — dmarc.yourdomain.com instead of _dmarc.yourdomain.com, or added at the apex. The underscore prefix is non-negotiable.
• "Multiple DMARC records" shows up when a previous admin published a record and the current one was added as a second TXT instead of replacing the first. DMARC requires exactly one record at _dmarc. Delete the stale one.
• "Invalid syntax in rua=" typically means a mailto URI with no scheme (reports@rua.mxdns.io instead of mailto:reports@rua.mxdns.io).
• "External reporting destination not authorized" is specific to RUA addresses at a domain you don't own. Covered in the next section.

If the checker shows green, the record is parseable. That does not mean your mail flow passes DMARC yet — it means the policy is published and receivers will start sending reports.

Publishing the RUA Address

Aggregate reports land in whatever mailbox you name in rua=. You can point them at your own address, but parsing the XML by hand is tedious and does not scale past a few days of reports. The mxio pattern is to use a per-account RUA address on rua.mxdns.io:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:a1b2c3d4@rua.mxdns.io; fo=1"

The token a1b2c3d4 is issued when you add the domain in the DMARC dashboard. Reports are ingested as they arrive, parsed into the Report Viewer, and classified by source (Authorized, Failing, Unknown, Forwarded, Misconfigured).

Because the reporting mailbox is on rua.mxdns.io — a different organizational domain than the one being protected — RFC 7489 §7.1 requires the reporting domain to publish an authorization record. Without it, major receivers (Gmail, Microsoft, Yahoo) silently drop the reports. mxio publishes this record automatically on rua.mxdns.io, so no additional DNS work is required on your side. If you choose to self-host reporting at a domain you own, publish a TXT at yourdomain.com._report._dmarc.yourreportingdomain.com with value v=DMARC1 before directing reports there.

M365-Specific Pitfalls

These are the alignment failures the combined Google/Microsoft guide does not cover in detail. They are what you will actually see in your aggregate reports.

Hybrid deployments and SPF include drift

In a hybrid topology, on-prem Exchange accepts mail from your users, then routes outbound through Exchange Online via an outbound connector. From the internet's perspective, messages originate from spf.protection.outlook.com — so your SPF include is correct. From the DKIM side, signing happens at the EXO hop only if you've configured tenant DKIM for the domain. If you configured DKIM on the on-prem Exchange server instead, those signatures may survive the EXO relay, or they may be replaced depending on the connector's header rewriting settings. Audit both ends: verify which server is signing, with which selector, and which d= domain.

Direct-send bypassing EXO

A copier scanning to email. A CRM's scheduled report. A legacy VB script. These often send SMTP directly to yourdomain-com.mail.protection.outlook.com with a From: address at your domain. Microsoft accepts the mail because it's destined to a tenant they host, but the sender is not authenticated. SPF fails (the sender's IP is not in your record), DKIM is absent, DMARC fails.

Fix this one of three ways: route the device through a tenant connector that authenticates it, migrate the sender to a transactional ESP (SendGrid, Postmark) that signs with your domain, or — for internal-only traffic — relay through on-prem Exchange and include its IP in your SPF record. Adding the sender's public IP directly to SPF is a last resort; it works but does not cover DKIM, so those messages are one forwarding hop away from failing.

Relay connectors and alignment

Inbound mail routed through a third-party security gateway (MailRoute, Mimecast, Proofpoint, Barracuda) then forwarded to EXO is not a DMARC concern on the receiving side — the gateway is the recipient, not the sender. Outbound mail relayed through a gateway is. If the gateway rewrites envelope sender addresses or adds list footers that break DKIM signatures, alignment will fail at the recipient's mail server. Test outbound flow through the gateway explicitly and confirm both SPF (does the gateway's IP appear in your SPF record, directly or via the provider's include) and DKIM (does the signature survive the relay intact).

Third-party ESPs alongside M365

Most M365 tenants don't only use Exchange Online. Marketing sends through Mailchimp or HubSpot. Transactional mail comes from SendGrid or Postmark. Alerts come from Datadog or PagerDuty. Each of these is a separate sending surface with its own SPF and DKIM story. Configure domain authentication in every ESP so they sign with d=yourdomain.com, and add their SPF includes to your record — watching the 10-lookup limit as you go. If you blow past it, Managed SPF flattens the record automatically; manually editing SPF to stay under the limit is a maintenance tax you should not pay.

Enhanced DKIM (tenant DKIM) vs shared onmicrosoft.com DKIM

This is the single most common M365 DMARC failure. Until you explicitly enable DKIM for your custom domain in the Defender portal, Exchange Online signs outbound mail with d=yourtenant.onmicrosoft.com. That signature passes DKIM validation — the cryptography is fine — but it does not align with a From: header of yourdomain.com. DMARC relaxed alignment requires the DKIM d= domain and the From: header to share an organizational domain. They don't.

The fix: enable tenant DKIM (Defender portal → Email authentication settings → DKIM → select your domain → Enable). Publish the two CNAMEs Microsoft generates. Wait a few minutes to a few hours for Microsoft to activate signing. Verify with the mxio DKIM Checker using selector selector1 and confirm the result shows d=yourdomain.com.

Moving p=none to quarantine to reject

The phased rollout for M365 follows the same structure as the general DMARC deployment guide, but M365 has specific watchpoints at each transition.

Weeks 1 to 4 at p=none: Watch aggregate reports for three patterns. First, spf.protection.outlook.com sources should show SPF pass and — after you enable tenant DKIM — DKIM pass with d=yourdomain.com. Second, any direct-send sources from your own IP space (on-prem scanners, legacy apps) should appear. These are the ones you need to fix. Third, third-party ESPs should all resolve to known providers; anything labeled as an unknown source is either shadow IT or spoofing.

p=quarantine; pct=10 for 1 to 2 weeks: If any M365 source is still failing at p=none, fix it before starting the ramp. The pct= tag limits blast radius but does not eliminate it — a 10% sampling of legitimate failures is still failed legitimate mail.

p=quarantine at 25, 50, 100: Step up weekly. Watch for new sources appearing in reports — teams sign up for new services without telling IT, and a new ESP misconfigured against your domain will surface as an alignment failure. The Enforcement advisor in the DMARC dashboard flags this automatically.

p=reject; pct=10 for 1 week, then ramp to 100: Full enforcement. At this point M365 mail flow should be bulletproof — tenant DKIM signing, SPF include covering all relays, no direct-send holdouts. If the advisor reports green on known sources and your Unknown bucket is stable or shrinking, you're ready.

Do not skip the pct= ramp on either transition. M365 environments accumulate edge cases faster than almost any other platform because of the sheer number of ways mail can enter the system.

Reading Your First Aggregate Reports

Aggregate reports arrive within 24 to 48 hours of publishing p=none. The XML format is ugly but structured; see DMARC Aggregate Reports Explained for a full walkthrough.

Identifying M365 traffic in a report:

• Source IP: Exchange Online publishes its outbound IP space under spf.protection.outlook.com. Reports from Gmail or Yahoo will show those IPs as the source_ip for legitimate M365 mail.
• header.from: Your domain. If it's not your domain, the report is about spoofing, not about your legitimate mail.
• dkim.domain: yourdomain.com if tenant DKIM is working. yourtenant.onmicrosoft.com if it isn't — this is your signal that enhanced DKIM was never enabled or never propagated.
• spf.domain: Usually yourdomain.com for EXO-originated mail, since Microsoft sets the envelope sender to match.

In the Report Viewer, M365 sources are labeled "Microsoft 365 / Exchange Online" when the IP matches Microsoft's published ranges. You don't need to memorize IPs or parse XML — the classification happens automatically and sources are bucketed by status.

Next Steps

DMARC is not set-and-forget. New services, connector changes, DKIM key rotations, and tenant migrations all affect alignment. Keep rua= in your record permanently, review reports at least monthly, and let the Enforcement advisor track readiness for any future policy changes.

Start monitoring with the DMARC Reporting dashboard — it ingests reports automatically, classifies every sending source, and surfaces the exact DNS changes you need at each step of the enforcement ladder. The DMARC Checker and DMARC Wizard are free to use without an account and cover the record validation side of the workflow.

Related Articles

• DMARC Deployment Guide: From p=none to p=reject
• DMARC for Google Workspace and Microsoft 365 — the combined platform overview
• Moving from p=none to p=reject
• DMARC Aggregate Reports Explained
• DMARC Reporting Product Guide
• No DMARC Record Found