DMARC for Office 365 Setup Guide (2026)

Use this step-by-step guide to set up DMARC for Office 365. Learn relevant compliance changes, common troubleshooting methods, and why Microsoft 365 alone isn’t enough for email security.

Microsoft supports and encourages setting up DMARC for Office 365, also called Microsoft 365 or M365. It allows them to adopt email authentication protocols uniformly across all their registered domains. As an authority on authentication protocols, we are using this blog to explain the processes to configure DMARC for Office 365 to validate any emails that have:

• Online Email Routing Addresses with Microsoft
• Custom domains added in the admin center
• Parked or inactive, but registered domains

Read this guide to understand DMARC for Microsoft 365, steps to set it up, changing authentication requirements, and how tools like PowerDMARC are necessary to roll out enforcement gradually.

Quick Answer

If you need the short version, here is the basic Microsoft 365 DMARC setup process:

1. Configure SPF: add v=spf1 include:spf.protection.outlook.com -all to your DNS
2. Enable DKIM: go to Microsoft 365 Defender → Email & Collaboration → Policies & Rules → Threat Policies → DKIM → select domain → Enable (requires two CNAME records)
3. Publish DMARC: create a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:[email protected]
4. Monitor reports for 2–4 weeks, then gradually move to p=quarantine → p=reject

For a more detailed guide to follow along, read this blog to the end.
Note: This quick path works only if all legitimate Microsoft 365 and third-party sending sources are correctly authenticated and aligned. If you use platforms such as CRMs, marketing automation tools, help desk systems, or billing tools, identify them before moving to enforcement.

What Is DMARC and Why It Matters for Microsoft 365

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication protocol that helps protect domains from spoofing, phishing, and unauthorized use.

DMARC works on top of SPF and DKIM. It checks whether a message passes SPF or DKIM and whether the passing domain aligns with the visible From domain. Then it tells receiving mail servers what to do with messages that fail authentication.

For Microsoft 365 users, DMARC matters for two reasons:

• It helps stop attackers from impersonating your domain.
• It improves trust and deliverability for legitimate outbound email.

Exchange Online Protection checks DMARC on inbound mail, but that does not automatically protect your own domain from being spoofed elsewhere. To protect outbound identity, you must publish SPF, DKIM, and DMARC records for your domain.

For a broader implementation reference, see PowerDMARC’s DMARC guide.

DMARC 2026: The RFC 9989, 9990, and 9991 Update

In May 2026, DMARC was updated through three IETF RFCs:

RFC 9989 obsoletes RFC 7489 and RFC 9091 and moves DMARC to Proposed Standard status. For domain owners, the most important practical change is the move from Public Suffix List-based organizational domain discovery to DNS Tree Walk.

Existing DMARC records still begin with:

txt

v=DMARC1

So most Microsoft 365 administrators do not need to rebuild their DNS records immediately. However, you should review:

• sp= subdomain policy behavior
• Any complex delegated subdomain structure
• Domains and subdomains that send email through Microsoft 365 or third-party platforms
• Non-sending and inactive domains that should be locked down

If your organization uses a complex domain hierarchy, publish explicit DMARC records for every domain and subdomain that sends email. This reduces ambiguity as receivers move from older DMARC processing to RFC 9989 behavior.

For more detail, see PowerDMARC’s guide to the DMARC RFC 9989, 9990, and 9991 update.

Does Microsoft 365 Handle DMARC for You?

Microsoft 365 performs DMARC validation for incoming email, but it does not fully configure outbound domain protection for your custom domain.

Exchange Online Protection automatically evaluates SPF, DKIM, and DMARC on messages your organization receives. That helps protect users from spoofed inbound mail.

For outbound email, the responsibility is different. You must configure SPF, enable DKIM, and publish a DMARC record in DNS for each sending domain.

The simplest way to understand the split is this: Microsoft protects your Microsoft 365 inbox, while DMARC protects your domain identity across the wider email ecosystem.

If you only rely on native Microsoft 365 controls, you may still lack:

• Human-readable DMARC reporting
• Visibility into third-party senders
• Guidance for moving from p=none to enforcement
• Centralized monitoring across domains
• SPF lookup-limit management
• Alerts when vendors or DNS records break alignment

For a detailed breakdown, see why Microsoft 365 users still need DMARC.

Prerequisites: Set Up SPF and DKIM for Microsoft 365

Before you publish a DMARC record, ensure that both SPF and DKIM are correctly configured for your domain. DMARC does not authenticate email on its own; it relies entirely on SPF and/or DKIM results. If these are missing or misaligned, DMARC will fail, and legitimate emails may be impacted once enforcement is enabled.

Step 1: Configure SPF for Microsoft 365

SPF, or Sender Policy Framework, defines which mail servers are authorized to send email for your domain.

For a Microsoft 365-only domain, the standard SPF record is:

v=spf1 include:spf.protection.outlook.com -all

If you use third-party senders, include them in the same SPF record:

v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all

Important: Only one SPF TXT record can exist per domain. Multiple SPF records cause SPF PermError and can break authentication.

SPF also has a hard limit of 10 DNS lookups. Exceeding it causes SPF PermError, which DMARC interprets as a failure. If you use multiple SaaS services, use PowerSPF’s hosted SPF with Macros to stay permanently under the limit without manual DNS edits. You can also check your current SPF record or use this SPF generator for free.

Step 2: Enable DKIM for Microsoft 365

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your emails. This allows receiving servers to verify the message was not altered and genuinely comes from your domain.

⚠️  DKIM in Microsoft 365 is not enabled by default for custom domains. You must enable it explicitly in the admin centre.

Manual DKIM Setup: DNS + Admin Centre

1. Go to the Microsoft 365 Defender portal
2. Navigate to Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM
3. Select your domain.

Before you can enable, Microsoft will prompt you to add two CNAME records:

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

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

1. After publishing these CNAME records, return to the Defender portal and toggle ‘Enable’ for DKIM

Once activated, Microsoft begins signing all outgoing emails with DKIM. Verify your setup using PowerDMARC’s free DKIM checker.

How to Set Up DMARC for Office 365

After SPF and DKIM are configured, you can publish DMARC. The Microsoft 365 DMARC setup process happens in DNS, not inside the Microsoft 365 admin center for most custom domains.

Step 1: Identify All Email Sending Sources

Before publishing a DMARC record, you need a complete picture of who is sending email on behalf of your domain. Missing a legitimate sender can cause delivery failures once enforcement is enabled.

Common Microsoft 365 sending sources include:

• Microsoft 365 (Exchange Online)
• Marketing platforms (Mailchimp, HubSpot, Klaviyo)
• CRM systems (Salesforce, HubSpot CRM)
• Support tools (Zendesk, Freshdesk, Intercom)
• Internal applications or on-premises mail servers
• Third-party email gateways or security appliances

This is where many DMARC rollouts fail. A domain may appear to be “Microsoft 365-only,” but invoices, newsletters, password resets, ticket updates, and HR notifications often come from outside Microsoft 365.

If you are unsure which systems send on your behalf, start with p=none and use DMARC aggregate reports to discover them.

Step 2: Create Your DMARC Record

A DMARC record is a TXT record published in your DNS at _dmarc.yourdomain.com. Use PowerDMARC’s DMARC Record Generator to create a valid, error-free record in seconds.

A recommended starting record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected];

Breaking this down:

• v=DMARC1 — specifies the DMARC version
• p=none — monitoring mode (no enforcement; data collection only)
• rua=mailto:… — where aggregate (RUA) reports are sent

Step 3: Publish the DMARC Record in DNS

Add the following TXT record at your DNS hosting provider:

Note: After publishing, it may take some time (typically a few minutes to a few hours) for the record to propagate globally.

After publishing, verify your record using a DMARC checker to confirm there are no syntax errors and the record is resolving correctly.

Step 4: Monitor DMARC Reports

After enabling DMARC with a p=none policy, you will begin receiving DMARC aggregate reports (RUA) from receiving servers. These reports provide visibility into: who is sending emails using your domain, which messages pass or fail authentication, and alignment status for SPF and DKIM.

DMARC reports arrive as raw XML, difficult to interpret without tooling. PowerDMARC’s report analyzer converts them into human-readable dashboards so you can identify issues and safely progress toward enforcement.

Step 5: Gradually Move to Enforcement

Once you’ve confirmed all legitimate senders are properly authenticated, tighten your DMARC policy in stages:

Stage 1 — Monitoring (p=none):

v=DMARC1; p=none; rua=mailto:[email protected]

Stage 2 — Quarantine (suspicious emails go to spam):

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25; t=y

Stage 3 — Enforcement (reject unauthenticated mail):

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Tip:  Do not rush to p=reject. Premature enforcement is the most common cause of legitimate email being blocked during rollout.

Step 6: Configure DMARC for Different Domain Types

Your approach varies depending on the domain you’re configuring.

Step 7: Validate and Maintain Your Microsoft 365 DMARC Setup

DMARC is not a one-time setup. As your email ecosystem changes, your configuration must evolve. Even after reaching p=reject, continuous monitoring is essential to maintain deliverability and security.

You should regularly:

• Review DMARC reports
• Update SPF when adding new senders
• Ensure DKIM remains enabled and aligned
• Monitor for unauthorized activity

DMARC Policy Rollout: Why Gradual Enforcement Matters

Moving directly to a reject policy is one of the most common mistakes in DMARC implementation. Without visibility into your email flows, enforcement can disrupt legitimate communication.

A phased rollout allows you to monitor and correct issues before applying strict policies. Most organisations follow a progression from monitoring to quarantine and finally to reject. The duration of each phase depends on the complexity of your email environment, and skipping steps just increases the risk of unintended delivery failures.

How Exchange Online Handles Inbound DMARC

Exchange Online Protection automatically evaluates DMARC on all inbound messages. Since July 2023, Microsoft has honoured the sender’s published policy by default. When the recipient domain’s MX record points directly to Microsoft 365, messages failing DMARC against a p=reject policy are rejected at the gateway. Similarly, p=quarantine failures are sent to quarantine. This is controlled by the ‘Honor DMARC record policy when the message is detected as spoof‘ setting in the anti-phishing policy, enabled by default.

For a detailed walkthrough of configuring this setting and all related options, see PowerDMARC’s guide to Office 365 anti-phishing policy.

Source: Microsoft

The ‘oreject’ Behaviour Explained

Before this, Microsoft applied an internal override called action=oreject (origin reject) to inbound messages that failed a sender’s p=reject policy. Instead of rejecting the mail outright at the gateway, EOP routed it to the recipient’s junk folder and stamped the header with the oreject action.

Microsoft did this deliberately; forwarded mail and mailing-list traffic frequently break SPF and DKIM in transit, and a hard reject on p=reject would have dropped significant volumes of legitimate mail. The junk folder was a compromise: recipients could recover the mail if needed, and the sender’s policy was technically respected.

When You’ll Still See oreject Today

Since the default changed, EOP now honours p=reject as a true rejection for direct-MX flows. But the older behaviour hasn’t gone away entirely. You’ll still see oreject in three scenarios:

1. ‘Honor DMARC’ is disabled in your anti-phishing policy: check under Microsoft 365 Defender → Email & Collaboration → Threat Policies → Anti-phishing → Spoof settings
2. Mail flows through a third-party gateway (Proofpoint, Mimecast) before reaching Microsoft 365: enable Enhanced Filtering for Connectors in the Defender portal
3. A tenant-level allow rule is bypassing filtering: allowlisted senders, trusted inbound connectors, or SCL -1 rules skip DMARC enforcement entirely

Understanding compauth and Composite Authentication

Microsoft layers reputation signals on top of DMARC results through a system called composite authentication (compauth). This means a message can technically fail DMARC but still be delivered if Microsoft’s reputation signals indicate the sender is legitimate (compauth=pass). Conversely, a message can pass DMARC and still be junked if compauth fails. When troubleshooting DMARC delivery issues in M365, always check the Authentication-Results header for the reason= code. See this complete guide to compauth fail and composite authentication for more information.

Tightening Inbound Enforcement with Transport Rules

For organisations that want guaranteed rejection of DMARC-failing mail, an Exchange Online transport rule is the most reliable mechanism:

1. Go to Exchange admin centre → Mail flow → Rules → create a new rule
2. Set condition: A message header includes any of these words. Header name: Authentication-Results. Header value: dmarc=fail action=oreject
3. Set action: Reject the message with explanation ‘Message failed DMARC authentication and was rejected per organisational policy’

1. (Optional) Add exception for trusted internal senders or known legitimate forwarders
2. Set rule mode to ‘Test without Policy’ or  ‘Test with Policy Tips’ if available for the first week; review matched messages in message trace before switching to Enforce

Use this approach when regulatory or internal policy requires true rejection of failing mail, when your organisation is a high-value spoofing target (finance, legal, executive communications), or when you want consistent behaviour across direct-MX and third-party gateway flows.

Microsoft’s May 2025 DMARC Enforcement: What Changed

In May 2025, Microsoft introduced a major shift in how it handles unauthenticated email from external senders. This change primarily affects high-volume senders but has broader implications for all organisations.

Mailbox Provider Enforcement Comparison

Key Requirements Introduced by Microsoft

• Mandatory DMARC for bulk senders: domains sending 5,000+ emails per day to Microsoft consumer services must have a valid DMARC record
• Applies to Microsoft’s consumer mailbox ecosystem: Outlook.com, Hotmail.com, and Live.com
• Minimum requirement: DMARC at p=none — even a monitoring policy is acceptable, but no DMARC record is no longer tolerated at scale
• Strong emphasis on domain alignment: authentication alone is not enough, SPF and DKIM must align with the visible ‘From’ domain
• Hard rejection for non-compliance: 550 5.7.515 Access denied, sending domain does not meet the required authentication level

The change brings Microsoft in line with Apple, Google and Yahoo’s email authentication requirements, meaning the largest mailbox providers now all enforce authentication for bulk senders. See Microsoft’s DMARC Outlook requirements for a complete compliance checklist.

Why Microsoft 365 Alone Is Not Enough

While Microsoft 365 provides strong inbound protection, it offers limited capabilities for managing and monitoring DMARC at scale.

No Human-Readable Reporting

Microsoft now sends DMARC reports for enterprise users when the MX points directly to Office 365. However, these raw XML files are difficult to interpret without specialised tools. Without proper analysis, organisations lack visibility into who is sending email on their behalf and whether those sources are properly authenticated.

No Enforcement Guidance

Microsoft does not provide automated guidance for moving from monitoring to enforcement. This leaves administrators to manually interpret data and make decisions that can impact email delivery.

Not Suitable for Ongoing Management

A dedicated DMARC solution doesn’t just transform raw reports into actionable insights. It enables continuous monitoring, simplifies policy management, and helps organisations safely progress toward full enforcement, at a scale that Microsoft 365 simply does not provide.

Troubleshooting Common DMARC Issues in Office 365

You can also be a part of Microsoft’s learning community to keep in touch with Office 365 and its authentication protocol requirements.

Moving Forward with DMARC on Microsoft 365

DMARC on Microsoft 365 is a two-sided problem. Exchange Online Protection handles inbound validation for you automatically, but outbound protection is entirely your responsibility. The May 2025 enforcement changes make that responsibility urgent for anyone sending at volume, with the DMARCbis publication in May 2026 signaling that the email industry is treating DMARC as permanent, formal infrastructure.

The safest path is slower but effective: publish p=none, watch your reports for two to four weeks, fix the senders that surface, then move to p=quarantine and eventually p=reject. Skipping these steps is how legitimate business mail breaks during rollout.

The work shifts from setup to monitoring upon reaching enforcement. New senders get added, and third-party vendors change their infrastructure, all of which can quietly break alignment if no one’s watching the reports. Prioritise email security by checking your current DMARC record to see where you stand today.

For a complete reference of all DMARC tags, policies, and implementation options, see PowerDMARC’s DMARC guide.

Frequently Asked Questions

Does Microsoft 365 automatically set up DMARC?

Microsoft validates DMARC for inbound email but does not configure it for your custom domain. You must manually publish the outbound DMARC TXT record yourself. Domain protection requires you to publish SPF, DKIM, and DMARC records in DNS yourself.

Does Microsoft require DMARC?

Yes. Microsoft mandated DMARC (at minimum p=none) for domains sending 5,000+ emails per day to Outlook.com, Hotmail.com, and Live.com in 2025. Non-compliant senders are rejected at the server level, without reaching any inbox. Microsoft also strongly recommends all senders implement DMARC regardless of volume.

What is the 550 5.7.515 error?

This Microsoft 365 error means your emails are being rejected because your sending domain does not meet authentication requirements. The fix is to publish a valid DMARC record (at minimum p=none) and ensure SPF and DKIM are both configured and aligned with your From domain.

Why are emails still being delivered with p=reject?

There are four common reasons: (1) ‘Honor DMARC’ is disabled in your anti-phishing policy; (2) a third-party gateway sits in front of Microsoft 365; (3) Enhanced Filtering for Connectors is not enabled; (4) Microsoft’s composite authentication (compauth) is overriding the DMARC fail result; (5) a tenant allow-rule is bypassing filtering entirely. While Microsoft has moved toward stricter true rejection for high-volume senders, these overrides remain active in misconfigured environments.

Should I use quarantine or reject?

Start with monitoring (p=none) to understand your sending sources, then move to quarantine, and only use reject once you are confident all legitimate sources are aligned. Jumping straight to reject without monitoring is the leading cause of legitimate email loss during DMARC rollouts.

What does DMARCbis mean for Microsoft 365 admins?

DMARCbis (RFC 9989, published May 2026) officially moves DMARC to a Proposed Standard. For most M365 admins, no immediate DNS changes are required, existing DMARC records remain valid. The key change to be aware of is the DNS Tree Walk approach for determining organisational domains, which replaces the Public Suffix List. Review your sp= (subdomain policy) tag to confirm it still applies correctly under the new logic.

Does DMARC apply to onmicrosoft.com domains?

Yes. The onmicrosoft.com domain (MOERA) is often overlooked, but attackers actively use it for spoofing. SPF is auto-provisioned by Microsoft for MOERA domains, but DKIM and DMARC must be published manually. Use a strict p=reject policy on these domains since they’re typically not used for legitimate outbound mail.

Is DMARC required for PCI DSS compliance?

From March 31, 2025, PCI DSS v4.0 section 5.4.1 made anti-phishing controls, including DMARC, SPF, and DKIM, fully mandatory for all organisations handling payment card data. All 2026 assessments are conducted against PCI DSS v4.0.1 with no grace period. If your organisation processes card payments and uses Microsoft 365, DMARC is a strict compliance requirement.

• About
• Latest Posts

Yunes Tarada

Domain & Email Security Expert at PowerDMARC

Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.

Latest posts by Yunes Tarada (see all)

• SPF flattening: What is it and why do you need it? - July 28, 2026
• DMARC for Office 365 Setup Guide (2026) - July 21, 2026
• How to Fix “DKIM Signature Is Not Valid” and “Body Hash Not Verified” Errors - July 16, 2026