When SPF, DKIM, and DMARC Pass but Microsoft 365 Still Blocks the Message

Seeing spf=pass, dkim=pass, and dmarc=pass in a message header can make a Microsoft 365 rejection feel impossible. It is not. Those results establish useful domain authentication, but they do not give a message a delivery exemption.

Microsoft 365 still evaluates spoofing context, sender and IP reputation, message content, recipient behavior, tenant policies, routing, and malware or phishing signals. Authentication is a checkpoint in that process, not the final admission decision.

First separate “blocked” from “not in the Inbox”

“Microsoft blocked it” can describe several different outcomes:

• SMTP rejection, usually accompanied by a 5xx response
• temporary deferral, usually a 4xx response
• delivery to Junk Email
• quarantine in Microsoft Defender
• delivery followed by a later removal through Zero-hour Auto Purge
• delivery to a mailbox folder changed by a rule or user setting

These outcomes need different evidence. A sender cannot diagnose an SMTP rejection from a Junk folder screenshot, and a recipient cannot prove a sender-side block from a message that was accepted and later quarantined.

For a rejected message, preserve the complete SMTP response, timestamp, recipient, sender, connecting IP, and message ID. For an accepted message, preserve the original headers and check the message trace and quarantine details in the recipient tenant.

What the three passes actually prove

SPF proves that the connecting server was authorized for the SMTP envelope sender, commonly shown as smtp.mailfrom or Return-Path. DKIM proves that a signature validated for its signing domain, shown as header.d. DMARC checks whether at least one of those authenticated domains aligns with the visible From: domain.

A simplified result might look like this:

Authentication-Results: ...
  spf=pass smtp.mailfrom=example.org;
  dkim=pass header.d=example.org;
  dmarc=pass header.from=example.org

That is a healthy authentication result. It does not prove that the sending account was not compromised, that the recipient requested the message, that the links are safe, or that the sender has a good reputation with Microsoft.

The distinction is especially important when inspecting a real header. Do not rely on a testing tool or on the sender’s own claim that authentication passed. Read the Authentication-Results header added by Microsoft 365, and compare the domain values with the actual visible From: address.

Microsoft adds more signals after authentication

Microsoft 365 uses anti-spam and anti-phishing systems in addition to SPF, DKIM, and DMARC. Its filtering can classify a message as spam, high-confidence spam, phishing, high-confidence phishing, or bulk. It can then move, quarantine, reject, or delete the message according to the applicable policy.

The Microsoft documentation on anti-spam protection describes content filtering and the configurable actions for those verdicts. The same page explains that anti-spam headers can show why a message was marked or why it skipped a filter.

Authentication is therefore one input into a broader decision. A message can be perfectly authenticated and still have:

• a poor IP or domain reputation
• a sudden or unusual volume pattern
• high complaint or unknown-user rates
• links or attachments associated with abuse
• suspicious language, impersonation, or credential-harvesting behavior
• a sender identity that resembles a spoof of an accepted domain
• a tenant-specific allow, block, transport, or anti-phishing rule

Changing DNS will not repair every one of those conditions. First identify which layer produced the disposition.

Read compauth and its reason code

Microsoft’s compauth value is composite authentication. It is Microsoft's interpretation of the sender identity using authentication results and additional context. It is not a replacement for SPF, DKIM, or DMARC, but it often explains why the result feels contradictory.

Look for a header resembling:

Authentication-Results: ...
  spf=pass smtp.mailfrom=example.org;
  dkim=pass header.d=example.org;
  dmarc=pass action=none header.from=example.org;
  compauth=fail reason=001

The exact result and reason vary with the message and Microsoft’s current evaluation. Use Microsoft’s anti-spam message header reference for the current reason-code table rather than treating a code copied from an old incident as universal.

The important diagnostic cases are:

• compauth=fail means Microsoft was not persuaded by the composite identity, even if an individual mechanism appears to pass.
• reason=000 or reason=100 commonly points to an explicit DMARC failure and enforcement. Check the header.from, smtp.mailfrom, header.d, and policy action together.
• reason=001 points to an implicit-authentication failure. A raw SPF or DKIM pass may not have provided the identity context Microsoft expected.
• reason=010 or reason=601 can indicate spoofing involving an accepted domain in the recipient organization. Investigate internal applications, compromised accounts, and unexpected routing.
• reason=130 is associated with a trusted ARC sealer overriding a DMARC failure. It matters when forwarding or an intermediary changed the message.
• reason=905 points toward complex routing. A gateway, hybrid Exchange path, or other intermediary may be part of the authentication story.

Do not diagnose from compauth alone. Read it after the ordinary SPF, DKIM, DMARC, ARC, and routing fields. Microsoft’s email authentication documentation explains how composite authentication fits into that larger evaluation.

Reputation can override a clean checklist

An authenticated sender can still have a history Microsoft does not trust. Reputation is built from behavior over time, including complaints, invalid recipients, spam-trap signals, sending volume, recipient engagement, and the history of the IP, domain, and signing identity.

Common triggers include a newly assigned IP, a shared IP pool with poor neighbors, a sudden campaign launch, a stale list, or a compromised account sending a large amount of mail. A valid DKIM signature may confirm that the message came through an authorized system while also making it clear that the authorized system is currently sending harmful or unwanted mail.

For Outlook.com recipients, Microsoft’s postmaster troubleshooting guidance covers blocked or junked mail and SMTP responses. For high-volume consumer sending, also review Microsoft’s published requirements and sender-support options. Do not assume that a clean result in one tenant proves a good reputation everywhere.

Separate streams when possible. Password resets, employee notifications, newsletters, and prospecting mail should not all inherit the same sending identity and reputation. Review volume by IP, DKIM signing domain, envelope domain, campaign, and recipient segment rather than averaging the whole organization.

Content and identity still matter

SPF, DKIM, and DMARC do not verify that a message is safe or wanted. Microsoft can act on:

• a login link whose destination does not match its visible text
• a newly registered or compromised landing domain
• an attachment pattern associated with malware
• display-name impersonation or an urgent request for credentials
• an unusual sender-to-recipient relationship
• a campaign that produces repeated complaints

The same applies to a legitimate domain used by a compromised mailbox or API key. The message can pass DKIM because the attacker is using a real authorized sender. Treat a clean authentication result as evidence about the domain path, not as a content safety verdict.

Forwarding and gateways change the evidence

The message that passed authentication at its original destination may not arrive at Microsoft 365 unchanged. Forwarding can break SPF because the forwarder connects to Microsoft. A gateway or mailing list can modify the body and invalidate DKIM. A hybrid or layered routing design can also make the apparent source IP differ from the original sender.

Inspect the Received chain, ARC headers, gateway-specific headers, and the order of authentication results. If an intermediary is legitimate and modifies messages, configure it as a trusted ARC sealer only when its identity and operating practices are understood. Microsoft’s trusted ARC sealer guidance explains the recipient-side configuration.

Do not solve a routing problem by broadly allowlisting a sender. Microsoft warns that allowed senders and domains can bypass important protection and create a path for spoofed or compromised mail. Prefer fixing the path, using Enhanced Filtering for Connectors where appropriate, or applying a narrowly scoped and temporary exception with an owner and expiration.

Tenant policy may be the deciding layer

If the recipient organization controls the Microsoft 365 tenant, inspect the result in Microsoft Defender and Exchange Online rather than changing the sender’s DNS blindly. Check:

1. Message trace for the delivery event and final action.
2. Quarantine for the verdict, policy, and release details.
3. Anti-spam and anti-phishing policies, including policy priority.
4. Tenant Allow/Block List entries and their expiration.
5. Mail flow rules that change the spam confidence level or redirect mail.
6. Safe Links, Safe Attachments, impersonation protection, and malware results.
7. Connectors, Enhanced Filtering, and any gateway in front of Microsoft 365.
8. User inbox rules and Junk Email settings when the message was delivered.

Microsoft’s guide for handling legitimate messages that are blocked is the right starting point for a false positive. Submit representative messages and headers instead of adding a permanent broad allow entry.

If the recipient tenant is not under your control, provide the recipient administrator with the SMTP response or original message headers, the sending IP, the message ID, and the exact time. The recipient administrator can see tenant-local policy and quarantine information that the sender cannot.

A practical investigation sequence

Use this order to avoid random DNS changes:

1. Capture the actual failure

Record whether the message was rejected, deferred, quarantined, junked, delivered, or later removed. Save the SMTP response if there is one. “Blocked” is not specific enough for a useful diagnosis.

2. Verify the identity fields

From the Microsoft-added authentication results, record:

header.from=
smtp.mailfrom=
header.d=
spf=
dkim=
dmarc=
compauth=
reason=

Confirm that the visible From: domain is the identity the recipient expects. Check every DKIM signature if more than one exists. A passing signature from an unrelated domain can coexist with a different identity problem.

3. Check the sending path

Map the connecting IP, reverse DNS, envelope sender, DKIM selector, provider, gateway, and route. Compare a working message with a failing message from the same stream. Differences in IP, template, link host, recipient group, or route are often more informative than the shared domain name.

4. Inspect Microsoft’s reason and policy evidence

Read compauth, its reason, anti-spam headers, message trace, and quarantine details together. If the reason points to accepted-domain spoofing, investigate the recipient tenant and internal routes. If it points to reputation or content, stop changing SPF and DKIM records.

5. Test one controlled message

Send a small, representative message to a controlled mailbox. Keep the subject, links, attachment behavior, sender, and route close to the failing message. Change one variable at a time and retain the headers from each test.

6. Correct the narrowest cause

Fix alignment or DNS when the evidence shows an authentication problem. Fix list hygiene, volume, content, credentials, or reputation when those are the cause. Ask the recipient administrator to review tenant policy when the message is accepted but filtered locally.

What not to do

Several common reactions make the incident harder to understand:

• Do not add every Microsoft sending IP to SPF unless the organization actually controls and needs those sources.
• Do not rotate DKIM keys as a response to a reputation or content verdict.
• Do not move mail to a new domain or IP to escape a block without addressing complaints and compromised credentials.
• Do not broadly allowlist an authenticated domain. Attackers can abuse the same domain or a compromised sender.
• Do not infer that a message passed merely because a third-party tester reported green checks.
• Do not treat DMARC aggregate reports as a per-message delivery log. Pair them with message trace, bounce data, headers, and sender telemetry.

The right mental model

Microsoft 365 is not contradicting SPF, DKIM, and DMARC when it blocks a message after those checks pass. Authentication answers whether a domain identity is authorized through a particular mechanism. Microsoft’s filtering answers whether this message, from this infrastructure, to this recipient, is acceptable under the tenant’s current security and reputation signals.

Keep the authentication configuration correct, then investigate the layer that actually produced the block. In practice, the decisive evidence is usually the SMTP response, compauth reason, anti-spam headers, message trace, quarantine record, reputation history, or routing path, not another change to the domain’s TXT records.

Authentication is the checkpoint, not the destination

The strongest troubleshooting habit is to preserve the full message context. A green SPF, DKIM, and DMARC result is valuable, but it is only one part of the route to delivery. Once that boundary is clear, Microsoft 365 blocks become diagnosable events instead of mysterious failures.