DMARC for Office 365: Step-by-Step Setup & Best Practices

⚠️Important update (May 2025): Microsoft now enforces DMARC for high-volume senders. If you send more than 5,000 emails per day to Outlook, Hotmail, or Live users without DMARC, your messages may be rejected with a 550 5.7.515 error.

Microsoft supports and encourages setting up DMARC for Microsoft 365 (also called Office 365 or M365) users, which allows them to adopt email authentication protocols uniformly across all their registered domains. In this blog, we explain the processes to configure DMARC for Office 365 to validate any Office 365 emails that have:

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

What Is DMARC and Why It Matters for Microsoft 365

DMARC is an email authentication protocol that protects domains from spoofing and phishing. (Domain-based Message Authentication, Reporting, and Conformance) works on top of SPF and DKIM, aligning authentication results with domain policy and telling receiving servers how to handle messages that fail those checks.

In a Microsoft 365 environment, DMARC plays a dual role. It protects your domain from being impersonated by attackers, and it also helps ensure your legitimate emails are trusted by external recipients.

Does Microsoft 365 Handle DMARC for You?

One of the most common misconceptions among administrators is that Microsoft 365 handles DMARC for you.

Microsoft 365 does perform DMARC validation, but only for incoming email. Exchange Online Protection (EOP) automatically checks SPF, DKIM, and DMARC on messages your organization receives. That means your users are protected from spoofed emails to some extent.

However, for outbound email, Microsoft does nothing unless you configure it. If you want to protect your domain and meet modern compliance requirements, you must publish a DMARC record in your DNS.

This distinction is critical. Microsoft protects your inbox, but DMARC protects your domain reputation, which is why Microsoft 365 needs DMARC even with EOP in place. The setup you’re about to implement applies to outbound protection.

Prerequisites: Set Up SPF and DKIM for Microsoft 365

Before you publish a DMARC record, you must 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 (Sender Policy Framework) defines which mail servers are authorized to send emails on behalf of your domain. In a Microsoft 365 setup, this typically includes Microsoft’s own mail servers and any third-party services you use.

Manual SPF Setup (DNS Method)

To configure SPF manually:

1. Go to your DNS hosting provider (e.g., GoDaddy, Cloudflare, etc.)
2. Create or update a TXT record for your root domain

Use the following standard Microsoft 365 SPF record:

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

If you use additional services (like Mailchimp or Salesforce), you must include them as well. For example:

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

💡Tip: Avoid multiple SPF records; only one SPF TXT record should exist per domain. If multiple services are used, they must be combined into a single record.

Automated SPF Setup (Using PowerDMARC)

Manually building SPF records can become complex, especially when multiple services are involved. Errors like exceeding DNS lookup limits or misconfigurations are common.

Using PowerDMARC’s SPF tools simplifies this process. The SPF generator automatically builds a valid record based on your sending sources.

Step 2: Enable DKIM for Microsoft 365

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

Unlike SPF, DKIM in Microsoft 365 requires both DNS configuration and activation in the admin center.

Manual DKIM Setup (DNS + Admin Center)

To enable DKIM manually:

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

Image source

Before you can enable DKIM, Microsoft will prompt you to add two CNAME records to your DNS.

These typically look like:

selector1._domainkey.yourdomain.com → selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

selector2._domainkey.yourdomain.com → selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

After publishing these records, return to the admin portal and click “Enable” for DKIM. Once activated, Microsoft will begin signing all outgoing emails with DKIM.

Automated DKIM Setup (Using PowerDMARC)

DKIM setup can be confusing, especially for administrators unfamiliar with CNAME records and selector formats.

PowerDMARC simplifies this by automatically generating the correct DKIM records for your domain, offering Auto-DNS publishing to eliminate manual entry errors, and offering a DKIM checker to confirm DKIM is correctly enabled

How to Set Up DMARC for Office 365?

Once SPF and DKIM are properly configured, you can move on to setting up DMARC. In Microsoft 365, this process is done at the DNS level, but doing it correctly requires understanding your email ecosystem, choosing the right policy, and monitoring results before enforcement.

Step 1: Identify All Email Sending Sources

Before publishing a DMARC record, you need a complete picture of who is sending emails on behalf of your domain. This is one of the most important steps, because missing a legitimate sender can cause delivery failures later.

Your sending sources typically include:

• Microsoft 365 (Exchange Online)
• Marketing platforms (Mailchimp, HubSpot, etc.)
• CRM systems (Salesforce)
• Support tools (Zendesk, Freshdesk)
• Internal applications or servers

If any of these are not properly authenticated via SPF or DKIM, they will fail DMARC once enforcement is enabled.

💡Tip: If you’re unsure about all sources, start with a monitoring policy (p=none) and use DMARC reports to discover unknown senders before enforcing stricter policies.

Step 2: Create Your DMARC Record

A DMARC record is a TXT record published in your DNS. It defines your policy and tells receiving servers how to handle emails that fail authentication. You can create a unique office 365 DMARC record for your domain by using PowerDMARC’s instant DMARC record generator tool.

A basic DMARC record looks like this: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Let’s break this down:

v=DMARC1 – Specifies the DMARC version
p=none – Monitoring mode (no enforcement)
rua=mailto:[email protected] – Where aggregate reports are sent
fo=1 – Enables failure reporting

This is the recommended starting point because it allows you to collect data without affecting email delivery.

Step 3: Publish the DMARC Record in DNS

Once your record is ready, you need to add it to your DNS.

Use the following settings:

Record Type: TXT
Host/Name: _dmarc
Value: Your DMARC record
TTL: 1 hour (or default)

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

💡Tip: Always verify your record after publishing using a DMARC checker to ensure there are no syntax errors.

Step 4: Monitor DMARC Reports

After enabling DMARC with a p=none policy, you will begin receiving reports 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 are typically sent in XML format and can be difficult to interpret manually. Without proper analysis, it’s easy to miss misconfigurations or unauthorized senders.

💡Tip: Use a DMARC report analyzer tool to convert raw reports into readable insights. This makes it easier to identify issues and safely move toward enforcement.

Step 5: Gradually Move to Enforcement

Once you’ve reviewed your reports and confirmed that all legitimate senders are properly authenticated, you can begin tightening your DMARC policy.

A typical progression looks like this:

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

↓

Move to quarantine (suspicious emails go to spam): v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

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

💡Tip: Do not rush to p=reject. Premature enforcement is one of the leading causes of legitimate email being blocked.

Step 6: Configure DMARC for Different Domain Types

Your approach may vary 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 organizations follow a progression from monitoring to quarantine and finally to reject. The duration of each phase depends on the complexity of your email environment, but skipping steps increases the risk of unintended delivery failures.

How Exchange Online Handles Inbound DMARC

Exchange Online Protection automatically evaluates DMARC on all inbound messages, and since July 2023, Microsoft honors 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, which is enabled by default.

Image source

The “oreject” Behavior Explained

Before July 2023, 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 as forwarded mail and mailing-list traffic frequently break SPF and DKIM in transit. This means that a legitimate message that passes authentication at the original sender can fail it by the time a secondary recipient receives it. A hard reject on p=reject would have dropped a significant volume of legitimate mail along with the spoofed messages. The junk folder was a compromise: recipients could still recover the mail if needed, and the sender’s policy was technically respected.

The trade-off was that spoofed messages that should have been rejected were still landing in user inboxes (in the junk folder), where a distracted recipient might open them. For security teams, this meant DMARC enforcement never felt as strict as the policy suggested.

When You’ll Still See oreject Today

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

1. “Honor DMARC” is disabled in your anti-phishing policy.

To troubleshoot this: Check the setting under Microsoft 365 Defender → Email & Collaboration → Threat Policies → Anti-phishing → Spoof settings. The toggle is on by default, but tenants that migrated from older configurations may have it turned off.

2. Mail flows through a third-party gateway before reaching Microsoft 365.

If your MX points to a security appliance (Proofpoint, Mimecast, etc.) that then forwards to EOP, Microsoft can’t re-evaluate DMARC unless you enable Enhanced Filtering for Connectors in the Defender portal. Without it, EOP trusts the upstream gateway’s verdict and defaults to oreject behavior for failing mail.

3. A tenant-level allow rule is bypassing filtering.

Allowlisted senders, trusted inbound connectors, or transport rules that stamp Spam Confidence Level (SCL -1) will skip DMARC enforcement entirely and the message lands in the inbox regardless of policy.

For stricter handling, turn on Spoof Intelligence in the Defender portal alongside “Honor DMARC.” Spoof Intelligence evaluates sender reputation separately from DMARC and quarantines messages that look like impersonation attempts even when authentication technically passes.

Tightening Inbound Enforcement with Transport Rules

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

How to build the rule:

1. Go to Exchange admin center → Mail flow → Rules and create a new rule.
2. Set the condition: A message header includes any of these words. Header name: Authentication-Results. Header value: dmarc=fail action=oreject.
3. Set the action: Reject the message with the explanation — enter something like “Message failed DMARC authentication and was rejected per organizational policy.”
4. (Optional) Add an exception for trusted internal senders or known legitimate forwarders to prevent false positives.
5. Set the rule mode to Test with Policy Tips for the first week. Review the matched messages in the message trace before switching to Enforce.

You can refer to Microsoft’s extended documentation on mail flow rules for more information.

When to use this approach:

Transport rules make sense when regulatory or internal policy requires true rejection of failing mail, when your organization is a high-value spoofing target (finance, legal, executive communications), or when you want consistent behavior 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 organizations.

At a high level, Microsoft’s email sender requirements align with broader industry moves toward stricter authentication and sender accountability. The update introduces clear thresholds, enforcement actions, and expectations that were previously more loosely applied.

Key Changes Introduced by Microsoft

• Mandatory DMARC for bulk senders: Domains sending 5,000+ emails per day to Microsoft consumer services must now have a valid DMARC record in place.
• Applies to Outlook.com, Hotmail.com, and Live.com: Enforcement specifically targets Microsoft’s consumer mailbox ecosystem, not just enterprise tenants.
• Minimum requirement: DMARC at p=none: Even a monitoring policy is acceptable, but no DMARC record is no longer tolerated at scale.
• Stronger emphasis on domain alignment: Authentication alone is not enough, SPF and DKIM must align with the visible “From” domain for DMARC to pass.
• Hard rejection for non-compliance: Emails that fail to meet requirements may be blocked with: 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

The change brings Microsoft in line with Google and Yahoo, who rolled out similar requirements in February 2024, meaning the three largest mailbox providers now all enforce authentication for bulk senders.

Platforms like PowerDMARC fill this gap by offering dedicated compliance programs to align with mailbox provider requirements across all your sending sources.

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 – capabilities that dedicated email authentication platforms provide.

Lack of Human-readable Reporting

While Microsoft now sends DMARC reports for enterprise users, there is no built-in system for aggregating and interpreting DMARC reports in a meaningful way. These reports are sent in XML format and can be difficult to analyze without specialized tools. As a result, organizations often 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 transforms raw reports into actionable insights. It enables continuous monitoring, simplifies policy management, and helps organizations safely progress toward full enforcement, at a scale that Microsoft 365 does not provide natively.

Troubleshooting Common DMARC Issues in Office 365

1. No DMARC record published

This is the most common problem. “No DMARC record published” basically implies that your domain has a missing DMARC TXT record in DNS, so receivers have no policy to act on.

To troubleshoot this, first

• Verify this with the help of a DMARC checker.
• If the tool returns a “DMARC record missing” error, the fix is to publish a record starting at v=DMARC1; p=none; rua=mailto:[email protected] so you can begin collecting reports before tightening policy.
• You can then slowly move to enforcement while monitoring your reports once you are comfortable with your setup.

2. Forwarding breaks SPF and DKIM

Email Forwarding is the single biggest source of legitimate-but-failing mail. When an intermediary (mailing list, forwarding service, or security appliance) modifies a header included in the DKIM signature, the signature no longer verifies, and DKIM fails. SPF usually breaks at the same time because the forwarding server’s IP isn’t in your record.

Here are three possible best practices to troubleshoot this:

• Prefer DKIM-aligned signing at the source, since DKIM survives forwarding better than SPF when headers aren’t rewritten
• Avoid Sender Rewriting Scheme (SRS) as a fix, as it patches SPF but doesn’t restore From-domain alignment, so DMARC still fails
• Configure trusted ARC (Authenticated Received Chain) sealers in Microsoft Defender for any forwarding service that legitimately modifies your mail. Microsoft will honor the upstream authentication result via the ARC chain rather than failing the message outright.

3. SPF Permerror due to too many DNS lookups

If SPF suddenly fails for every legitimate source and returns a Permerror, the underlying cause is usually structural rather than configuration-level.

There may be two likely causes for this:

• The first is that you’ve crossed the 10-lookup limit SPF imposes on include, a, mx, redirect, exists, and ptr mechanisms. Nested lookups inside vendor includes count too, so a record that reads fine at a glance can quietly be at 12 or 13. When it tips over, every receiver returns permerror, and SPF-based DMARC alignment collapses for the whole domain at once.

What to do: Start by auditing your record using an SPF lookup tool and removing vendors you no longer use. But this is a temporary fix. A long-term solution is to use a hosted SPF solution like PowerSPF with SPF macros optimization for dynamic SPF lookup management.

• The second cause, if you’re seeing temperror specifically against Microsoft destinations, may be DNS timeouts. If the timeouts are happening on a specific include, that’s the vendor to flatten or move off the record.

4. p=reject policies aren’t being honored

Since July 2023, Microsoft honors p=reject by default, i.e., a failing message should get rejected outright. If it isn’t, one of four things is in the way:

• DMARC honoring may be turned off in your Anti-phishing policy: Make sure “Honor DMARC record policy when the message is detected as spoof” is enabled, and that the action for p=reject is set to Reject (not Quarantine).
• A third-party gateway sits in front of Microsoft 365: If your MX points to a third-party security gateway, Microsoft won’t re-enforce DMARC unless you enable Enhanced Filtering for Connectors.
• Composite authentication overrode the result: Microsoft layers reputation signals on top of DMARC. A message can fail DMARC and still be delivered if compauth=pass
  (Learn more about this on Microsoft’s learning community).
• A tenant allow-rule is bypassing filtering: A allowlisted sender, a trusted inbound connector, or a rule that stamps Spam Confidence Level SCL-1 will skip DMARC enforcement entirely.

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.

The safest path is the slow one: 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 steps is the single most common reason legitimate mail breaks during rollout.

Once you’re at enforcement, the work shifts from setup to monitoring. 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. That’s where a dedicated DMARC platform earns its keep. PowerDMARC’s reporting and analysis tools turn raw XML into readable insights and flag drift before it becomes a deliverability problem.

Start by checking your current DMARC record to see where you stand today.

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.

Does Microsoft require DMARC?

Yes, Microsoft mandates DMARC for high-volume senders. It is also strongly recommended for all organizations to ensure deliverability and protection.

What is the 550 5.7.515 error?

This error indicates that your emails are being rejected due to missing or non-compliant DMARC policies under Microsoft’s enforcement rules.

Why are emails still being delivered with p=reject?

Microsoft has historically applied an internal override called “oreject” (origin reject), which routes DMARC-failing messages to the Junk folder instead of rejecting them outright at the gateway. This was designed to protect legitimate senders from accidental loss, but it leaves spoofed messages visible to recipients.

Two things to know:

1) Since the May 2025 enforcement changes, Microsoft is moving toward stricter, true rejection for high-volume senders.

2) If you want guaranteed rejection inside your own Microsoft 365 tenant, create an Exchange transport rule that hard-rejects messages.

Should I use quarantine or reject?

Start with monitoring (p=none) to monitor your sending sources and email channels, then move to quarantine, and only use reject once you are confident that all legitimate sources are aligned.

“`

• 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)

• DMARCbis Explained – What’s Changing and How to Prepare - April 16, 2026
• SOA Serial Number Format Is Invalid: Causes & How to Fix It - April 13, 2026
• How to Send Secure Email in Gmail: Step-by-Step Guide - April 7, 2026