--- title: "Microsoft DMARC: Office 365 Setup Guide 2026" description: "Microsoft enforces DMARC for Outlook senders since May 5, 2025. Set up DMARC for Office 365 and Microsoft 365 step-by-step with DNS examples. Configure now." publishedAt: 2026-04-27 tags: ["microsoft-365", "compliance", "email-authentication", "dmarc", "outlook"] faq: - question: "What is Microsoft DMARC?" answer: "Microsoft DMARC refers to how Microsoft's consumer Outlook.com service and Exchange Online tenants implement the DMARC standard defined in RFC 7489. Outlook.com enforces DMARC at the edge for high-volume senders; Exchange Online tenants honor inbound DMARC through anti-phishing policy settings and sign outbound DKIM when custom domains are configured." - question: "Does Microsoft 365 use DMARC?" answer: "Yes. Microsoft 365 honors sender DMARC on inbound mail when the recipient MX points to Exchange Online, signs outbound DKIM for custom domains once enabled in the Defender portal, and sends DMARC aggregate (rua) reports to domains that publish a valid rua mailbox. Microsoft 365 never sends forensic (ruf) reports." - question: "When did Microsoft enforce DMARC?" answer: "Microsoft enforced DMARC for Outlook.com consumer inbound starting May 5, 2025 for domains sending more than 5,000 messages per day. Non-compliant senders receive a 550 5.7.515 SMTP rejection. Exchange Online tenant inbound enforcement has honored p=reject and p=quarantine by default since July 2023, using NDR code 550 5.7.509." - question: "How do I set up DMARC in Office 365?" answer: "Publish an SPF TXT record with include:spf.protection.outlook.com, enable DKIM signing in the Defender portal at security.microsoft.com, then add a _dmarc.yourdomain.com TXT record starting at v=DMARC1; p=none. Monitor aggregate reports, then progress p=none to p=quarantine to p=reject once legitimate sources align." - question: "What is the difference between Microsoft 365 DMARC and M365 DMARC?" answer: "They are the same thing. M365 is Microsoft's common abbreviation for Microsoft 365, and both terms describe DMARC configuration for tenants running Exchange Online and custom sending domains. Setup steps, DNS records, and enforcement behavior are identical regardless of which label you search for." - question: "Does Microsoft send DMARC aggregate reports?" answer: "Yes, Microsoft 365 sends DMARC aggregate (rua) reports to domains that publish a valid rua mailbox, but only when the recipient domain's MX record points directly to Microsoft 365. Hybrid routing or a third-party gateway fronting Exchange Online suppresses report generation. Microsoft never sends forensic (ruf) reports." --- # Microsoft DMARC Enforcement: Setting Up DMARC for Office 365 and Microsoft 365 603,854 domains — 19.6% of every SPF-enabled domain in our 5.5 million-domain scan — route their mail through `spf.protection.outlook.com`. When Microsoft started enforcing DMARC for bulk senders to Outlook.com on May 5, 2025, it reshaped compliance for the largest email footprint on the internet ([DMARCguard SPF Supply Chain Study, 2026](/research/spf-supply-chain/); [Microsoft Defender for Office 365 Blog, 2025-04-30](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlooks-new-requirements-for-highvolume-senders/4399730)). Microsoft DMARC is not one thing but two: a sender-side enforcement regime for anyone emailing Outlook.com consumer mailboxes, and a tenant-side configuration burden for every Microsoft 365 Global Administrator. Miss either, and mail to `@outlook.com`, `@hotmail.com`, `@live.com`, and `@msn.com` starts bouncing with `550 5.7.515 Access denied`. By the end of this guide you will have a published DMARC record, a working SPF and DKIM stack in the Microsoft Defender portal, and a clear picture of how Microsoft, Google, and Yahoo treat DMARC differently in 2026. ## Why Microsoft DMARC changed in 2025 (and what that means in 2026) On April 2, 2025, Microsoft's Defender for Office 365 team announced new bulk-sender requirements: domains sending more than 5,000 messages per day to Outlook.com consumer mailboxes must pass SPF, pass DKIM, and publish a DMARC record with at least `p=none` aligned to SPF or DKIM. The first draft routed failing mail to the Junk folder. The version 4.0 update on April 30, 2025 replaced Junk-foldering with outright SMTP rejection effective May 5, 2025. Microsoft's own words: "The rejected messages will be designated as `550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.`" ([Microsoft Tech Community, 2025-04-30](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlooks-new-requirements-for-highvolume-senders/4399730)). The scope is narrower than most operators assume. The May 5, 2025 rule governs Outlook.com consumer inbound only — `outlook.com`, `hotmail.com`, `live.com`, and `msn.com`. Exchange Online tenant-to-tenant mail runs on a separate default, rolled out July 2023: inbound mail with `p=reject` is rejected with `550 5.7.509` when the recipient's MX points to Office 365, governed by the tenant's anti-phishing policy `HonorDmarcPolicy` toggle ([Microsoft Learn, DMARC configure, 2025-05-07](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)). Between June 2025 and April 2026, Microsoft did not publish a follow-on escalation. The Outlook.com Postmaster Policies page (updated March 3, 2026) still anchors on the May 5, 2025 date and the 5,000-per-day threshold. Any domain sending commercial volume to Microsoft consumer mailboxes now treats DMARC as blocking, not optional. ## Microsoft DMARC requirements at a glance There are two audiences for Microsoft DMARC, and they are not the same. **Senders TO Outlook.com consumers.** If your domain sends more than 5,000 messages per day to `@outlook.com`, `@hotmail.com`, `@live.com`, or `@msn.com`, you must publish SPF (aligned), DKIM (aligned), and DMARC at least `p=none`. Non-compliant mail is rejected with `550 5.7.515`. Smaller senders are "strongly recommended" but not mandated ([Outlook.com Postmaster, 2026-03](https://sendersupport.olc.protection.outlook.com/pm/Policies)). **Administrators OF Microsoft 365 tenants.** Your outbound domains need SPF, DKIM, and DMARC so mail reaches every destination — Microsoft, Google, Yahoo, and the long tail. Inbound enforcement is governed by the anti-phishing policy's Honor DMARC toggle; `HonorDmarcPolicy=$true` with `DmarcRejectAction=Reject` is the new-tenant default, but legacy tenants may still carry `MoveToJmf`. "M365 DMARC" and "Microsoft 365 DMARC" are the same thing — M365 is Microsoft's internal abbreviation. Setup, DNS, and enforcement are identical regardless of which phrasing your vendor documentation uses. | Requirement | Bulk sender to Outlook.com (>5,000/day) | Exchange Online tenant (outbound) | Exchange Online tenant (inbound) | | ------------------ | --------------------------------------- | -------------------------------------- | -------------------------------- | | SPF published | Mandatory, must pass | Mandatory for every sending domain | Evaluated against sender domain | | DKIM signing | Mandatory, must pass | Mandatory for custom domains | Evaluated against sender domain | | DMARC policy | At least `p=none`, aligned | Start `p=none`, progress to `p=reject` | Honored per anti-phishing policy | | ARC | Recommended | Recommended for forwarders | Trusted ARC sealers opt-in | | Non-compliance NDR | `550 5.7.515` | Dependent on destination | `550 5.7.509` for `p=reject` | | Threshold | 5,000 messages/day | Any volume | Any volume | ## How do I set up DMARC in Microsoft 365? (step-by-step) The fastest path to set up DMARC in Office 365 is the same order Microsoft uses in its own documentation: publish SPF, enable DKIM signing in the Defender portal, then publish DMARC. Microsoft is explicit that the order matters — "Configure SPF, DKIM, and DMARC records (in that order) for all custom Microsoft 365 domains" ([Microsoft Learn, MDO deployment guide](https://learn.microsoft.com/en-us/defender-office-365/mdo-deployment-guide)). **Before you start.** You need Global Administrator in Microsoft Entra plus Organization Management or Security Administrator in Exchange Online to access the Email authentication settings blade — Security Administrator in Entra alone cannot open it. The custom domain must already be verified in Microsoft 365; confirm with `Get-AcceptedDomain`. Three facts to anchor in your head before you edit DNS: - SPF must `include:spf.protection.outlook.com` for any domain sending through Exchange Online. - DMARC lives at `_dmarc.yourdomain.com` as a TXT record starting `v=DMARC1; p=none;`. - Policy progression is `p=none` → `p=quarantine` → `p=reject`, not "turn on reject immediately." ### Step 1 — Publish the SPF TXT record for Exchange Online For a custom domain that sends only through Exchange Online (commercial or GCC), publish this single TXT record at the root of your sending domain: TTL: 3600 seconds (one hour) minimum, per Microsoft's guidance to avoid DNS lookup timeouts ([Microsoft Learn, SPF configure, 2025-09-17](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)). Use `-all` (hard fail) — Microsoft explicitly recommends it because DKIM and DMARC catch legitimate misalignments. For hybrid Exchange environments, add IP literals or additional `include:` mechanisms alongside the Microsoft include: GCC High / DoD tenants use `include:spf.protection.office365.us`; 21Vianet tenants use `include:spf.protection.partner.outlook.cn`. Watch the 10-DNS-lookup ceiling. Each `include:` costs at least one DNS lookup, and multi-vendor stacks (Microsoft 365 + Mailchimp + Salesforce + SendGrid + HubSpot) are routinely close to the limit. 148,655 domains in our 5.5 million-domain scan already exceed it and silently SPF-fail. ### Step 2 — Enable DKIM signing in the Microsoft Defender portal DKIM management lives in the Microsoft Defender portal at `https://security.microsoft.com`. Navigate: **Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM tab**. Shortcut: `https://security.microsoft.com/authentication?viewid=DKIM` ([Microsoft Learn, DKIM configure, 2026-01-31](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)). Select your custom domain, locate the toggle labeled "Sign messages for this domain with DKIM signatures" (default: Disabled), and publish the two CNAME records the flyout shows at your external DNS host. For newly onboarded custom domains, the May 2025 format change means CNAMEs now target `.dkim.mail.microsoft` with a dynamic partition (`k-v1`, `r-v1`): TTL: 3600. Pre-May-2025 tenants still use the legacy format with `.onmicrosoft.com`: Copy the CNAME target exactly as the portal shows it. A common 2025–2026 failure mode: following a third-party walkthrough that predates the May 2025 selector format and using `.onmicrosoft.com` targets for a domain Microsoft now expects on `.dkim.mail.microsoft` ([Microsoft Q&A, 2025-09-08](https://learn.microsoft.com/en-us/answers/questions/5488542/trouble-syncing-the-dkim)). After CNAMEs resolve, flip the toggle back to Enabled. Default key size is 2048-bit RSA; valid `-KeySize` values are 1024 or 2048. Rotation is admin-triggered through the "Rotate DKIM keys" button or `Rotate-DkimSigningConfig` in Exchange PowerShell. The `.onmicrosoft.com` MOERA domain has no automatic rotation cadence in 2026 — rotate it on the same schedule you rotate custom-domain keys. ### Step 3 — Publish the DMARC TXT record Microsoft cannot publish custom-domain DMARC from any admin portal — you edit your external DNS. The Defender portal and M365 admin center publish DMARC only for `.onmicrosoft.com` ([Microsoft Learn, DMARC configure, 2025-05-07](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)). Microsoft's recommended monitoring record for a custom subdomain: Microsoft documents only `v`, `p`, `pct`, `rua`, and `ruf`; for `sp=`, `adkim=`, `aspf=`, and `fo=`, Microsoft defers to RFC 7489. The default for `pct` is 100. Need one generated for your own domain? [Generate a Microsoft-ready DMARC record](/tools/dmarc-generator/) — pick your tenant type, paste your rua mailbox, and the generator outputs a record you can paste into your DNS host. Two operational notes: - Point `rua=` at a dedicated mailbox or Microsoft 365 Group, never a user's personal mailbox. Aggregate reports arrive as gzipped XML attachments. - Do not rely on `ruf=`. Microsoft 365 never emits forensic reports, regardless of whether a valid `ruf=mailto:` address exists in your record. ### Step 4 — Walk p=none to p=quarantine to p=reject Microsoft recommends a gradual rollout. Start with `p=none` and a valid `rua=` destination. Read aggregate reports for two to four weeks, identifying every legitimate sender that currently fails DMARC alignment. Fix those at the source — custom DKIM for your ESP, SPF include for your CRM, subdomain delegation for your transactional provider. When the failing-source list is empty of legitimate mail, tighten the policy. Use `pct=` to ramp impact rather than flip from `none` to `reject` overnight. Microsoft's documented progression is `pct=10`, `pct=25`, `pct=50`, `pct=75`, `pct=100` at each stage. At each step, measure two metrics: alignment rate (percentage of your mail passing SPF or DKIM aligned to the From domain) and failing-source count. Enforcement is only safe when alignment is above 99% and every failing source is known and intentional. Run a free Microsoft 365 DMARC check on your domain to see alignment results in the next 24 hours. [Check DMARC status for your Microsoft-hosted domain](/tools/dmarc-checker/) — no signup required. ### Step 5 — Protect MOERA and every parked domain Microsoft auto-signs DKIM and auto-publishes SPF for `*.onmicrosoft.com`, but does not publish a DMARC TXT record for your tenant's MOERA subdomain by default. Attackers spoof `user@contoso.onmicrosoft.com` and headers show `dmarc=none` because there is nothing to enforce ([Microsoft Learn, MOERA step-by-step, 2025-09-04](https://learn.microsoft.com/en-us/defender-office-365/step-by-step-guides/how-to-enable-dmarc-reporting-for-microsoft-online-email-routing-address-moera-and-parked-domains)). Close it. In the M365 admin center under **Settings → Domains → your `.onmicrosoft.com` domain → DNS records**, publish: Apply the same `p=reject` posture on every registered-but-unused custom domain. Pair it with SPF `v=spf1 -all` and no DKIM record. Parked domains cost nothing to protect. ## Microsoft-specific DMARC gotchas the official docs will not tell you Most setup guides stop at the DNS record. The failures happen after that. **`compauth` reason codes change the delivery verdict.** Microsoft stamps a composite authentication result in every Authentication-Results header. `compauth=fail reason=000` means explicit DMARC fail on a `p=quarantine` or `p=reject` sender — the actual delivery outcome is set by `DmarcRejectAction` / `DmarcQuarantineAction` in your anti-phishing policy, not the DNS record. `compauth=pass reason=130` means an ARC sealer rescued a genuine DMARC fail — the only reliable signal that [ARC chain validation](/learn/arc/) was load-bearing. `compauth=none reason=905` means DMARC was silently skipped because complex routing hid the originating IP ([Microsoft Learn, message headers, 2025-10](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo)). **Tenant-level `HonorDmarcPolicy` vs the policy you published.** Verify with `Get-AntiPhishPolicy | fl Name,HonorDmarcPolicy,DmarcQuarantineAction,DmarcRejectAction`. New tenants default to `$true`, `Reject`, `Quarantine`. Legacy tenants may still carry `MoveToJmf` — your published `p=reject` becomes silent Junk-foldering instead of a `550 5.7.509` rejection. **`sp=` on a subdomain record is silently ignored.** DMARC's `sp=` tag is read only on the organizational domain. Publishing `v=DMARC1; p=none; sp=reject` on `mail.example.com` does nothing. For a specific subdomain, publish an explicit `_dmarc.` TXT with its own `p=`. **Outbound mail silently signs with `.onmicrosoft.com` and breaks alignment.** If you miss Step 2 for any custom domain, Exchange Online signs with your tenant's MOERA domain. The DKIM signature is valid but does not align with the custom From — DMARC fails the moment you move past `p=none`. Verify received mail shows `dkim=pass header.d=`. **Third-party gateway fronting EOP breaks DMARC without Enhanced Filtering for Connectors.** With MX pointed at Mimecast, Proofpoint, or Barracuda, the last hop EOP sees is the gateway IP. Without EFC (`Set-InboundConnector -EFSkipLastIP $true` plus `-EFSkipIPs` populated with gateway egresses), SPF and DMARC evaluate against the gateway and fail on legitimate mail. Add the gateway as a Trusted ARC Sealer if it modifies messages. **Microsoft only sends rua reports when MX points directly at Microsoft 365, and never sends ruf.** Hybrid routing and SEG-fronted routing both suppress Microsoft-originated aggregate reports. If your MX is pointed at anything other than `*.mail.protection.outlook.com`, rely on aggregated reporting from every other receiver (Google, Yahoo, Proofpoint) that your rua address collects. Catching these in production takes a DMARC monitor, not a one-off check. ## Microsoft vs Google vs Yahoo: the 2026 DMARC enforcement side-by-side The three providers share direction — mandatory SPF, DKIM, DMARC for bulk senders — but differ on dates, thresholds, and exactly which SMTP code you see when mail fails.
| Area | Microsoft (Outlook.com) | Google (Gmail / Workspace) | Yahoo (Yahoo Mail / AOL / AT&T) | | ------------------------------- | --------------------------- | --------------------------------------- | ------------------------------- | | Initial enforcement date | May 5, 2025 | February 1, 2024 | February 2024 | | Follow-on escalation | None dated after May 2025 | November 2025 ramp | None published | | Bulk-sender threshold | >5,000/day to Outlook.com | ~5,000/day to personal Gmail | No numeric threshold published | | Minimum DMARC policy | At least `p=none`, aligned | At least `p=none` | At least `p=none` | | SPF + DKIM both required (bulk) | Both must pass individually | Both required, either aligned | Both required | | ARC stance | Recommended | Required for forwarded mail | Recommended | | Exact SMTP rejection code | `550 5.7.515` | `5.7.26` permanent / `4.7.31` temporary | `553`/`554` generic | | One-click unsubscribe mandated | Not mandated by name | Yes, since June 1, 2024 | Yes, since June 2024 | | Spam complaint threshold | Not published | 0.10% target / 0.30% ceiling | Below 0.3% | | Sends DMARC aggregate (rua) | Yes, when MX points at M365 | Yes | Not published | | Sends DMARC forensic (ruf) | No | Not published | Not published | Sources: [Outlook.com Postmaster Policies (2026-03)](https://sendersupport.olc.protection.outlook.com/pm/Policies), [Google Workspace Admin Help 81126](https://support.google.com/a/answer/81126) and [14229414](https://support.google.com/a/answer/14229414), [Yahoo Sender Hub Best Practices](https://senders.yahooinc.com/best-practices/), [Yahoo Sender Hub FAQs](https://senders.yahooinc.com/faqs/). **Notes and conflicts.** Microsoft's Postmaster index (updated March 3, 2026) still describes Junk-foldering, while the Policies page and the April 30, 2025 Tech Community revision document active `5xx` rejection — treat the latter two as authoritative. Google phrases its threshold differently between pages: "more than 5,000 messages per day" (81126) versus "close to 5,000 messages or more … within a 24-hour period" (14229414). For a deeper operator-level walkthrough, see our companion guide on [Google and Yahoo's sender requirements](/blog/google-yahoo-dmarc-requirements/).
## How DMARCguard monitors Microsoft 365 DMARC results Microsoft's reporting stops where your environment leaves the Microsoft network. A DMARC monitor closes the gap. - **Named sender identification on Microsoft 365 outbound.** Rua reports show `spf.protection.outlook.com` as a sending source; DMARCguard resolves that to "Exchange Online" so you are not triaging IP literals. - **Aggregate report ingestion from every receiver.** When your MX does not point at Microsoft 365, Microsoft does not send rua — but Google, Yahoo, and a hundred smaller receivers still do. DMARCguard collects all of them at one rua mailbox. - **ARC chain visibility.** `compauth=pass reason=130` means an ARC sealer rescued a DMARC fail. DMARCguard flags those so you know which forwarders are load-bearing and which are waste. ## Frequently asked questions ### What is Microsoft DMARC? Microsoft DMARC describes how Microsoft's two email footprints implement the DMARC standard ([RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489)): Outlook.com consumer mailboxes enforce DMARC at the edge for bulk senders, and Exchange Online tenants honor inbound DMARC through anti-phishing policy and sign outbound DKIM for custom domains. Both run on the same protocol — the difference is where the enforcement lives. For the underlying standard, see our [DMARC primer](/learn/dmarc/). ### Does Microsoft 365 use DMARC? Yes. Microsoft 365 honors sender DMARC on inbound mail when the recipient MX points to Exchange Online, signs outbound DKIM for custom domains once enabled, and sends DMARC aggregate (rua) reports to domains with a valid rua mailbox. Microsoft 365 never sends forensic (ruf) reports. ### When did Microsoft enforce DMARC? Microsoft enforced DMARC for Outlook.com consumer inbound on May 5, 2025, for domains sending more than 5,000 messages per day. Non-compliant mail is rejected with `550 5.7.515`. Exchange Online tenant inbound has honored `p=reject` / `p=quarantine` by default since July 2023, using NDR code `550 5.7.509`. ### How do I set up DMARC in Office 365? Publish an SPF TXT record with `include:spf.protection.outlook.com`, enable DKIM signing in the Defender portal by publishing the two portal-generated CNAMEs, then add a `_dmarc.yourdomain.com` TXT starting `v=DMARC1; p=none; pct=100; rua=mailto:rua@yourdomain.com`. Monitor aggregate reports for two to four weeks, then progress `p=none` to `p=quarantine` to `p=reject`. ### What is the difference between Microsoft 365 DMARC and M365 DMARC? They are the same thing. M365 is Microsoft's abbreviation; setup steps, DNS records, and enforcement behavior are identical regardless of which label vendor documentation uses. ### Does Microsoft send DMARC aggregate reports? Yes — to domains that publish a valid rua mailbox, but only when the recipient's MX record points directly to Microsoft 365. Hybrid routing and SEG-fronted routing (Mimecast, Proofpoint, Barracuda fronting EOP) suppress Microsoft-originated rua generation. Microsoft 365 never sends forensic (ruf) reports. ## Where to go from here Microsoft DMARC is not a one-day project. The DNS records take an hour; the alignment work — matching every legitimate sending source against SPF or DKIM — takes weeks. Bulk senders to Outlook.com are out of time: since May 5, 2025, non-compliant mail is rejected, not Junked. Start with a baseline: publish a record at `p=none` with a rua mailbox, and let two weeks of aggregate reports tell you what your environment actually looks like. If you also send to Gmail and Yahoo, pair this guide with the companion walkthrough on Google and Yahoo's sender requirements linked in the comparison section above — the three providers converge on the same endpoint, but the operational details diverge enough to matter.