Why am I getting DMARC policy bounces from Microsoft despite DMARC passing?
Published 15 Nov 2025
Updated 17 Oct 2026
15 min read
Summarize with
Updated on 17 Oct 2026: We clarified Microsoft's sender requirements and how to distinguish authentication failures from DMARC alignment failures.
If Microsoft returns 550 5.7.515 with DMARC passing, its high-volume sender requirements explain how the message can still be rejected. For Outlook.com, Hotmail, Live.com, and MSN recipients, affected domains need raw SPF and DKIM checks to pass, plus DMARC to pass through at least one aligned authentication path. If the bounce says Dkim=Fail and DMARC=Pass, the message can still hit Microsoft error 550 5.7.515 because the raw DKIM check failed even though SPF supplied the aligned path that passed DMARC.
An ESP's "DMARC Policy" bounce category does not identify which authentication check failed. Read the complete non-delivery report (NDR) and the receiving server's SMTP response. The DMARC record is usually not the first problem. Start with the authentication result inside the bounce, especially DKIM failure, intermittent DNS lookup failure, message modification after signing, or a forwarding path that changes the message body or signed headers.
- Direct answer: For 550 5.7.515, Microsoft is rejecting the message because the 5322.From domain did not meet its required authentication level, even though the DMARC result passed.
- DKIM failure signal: If the NDR contains Dkim=Fail, investigate raw DKIM verification. An 80% raw DKIM pass rate on the affected legitimate stream leaves failures that can explain rejected Microsoft traffic.
- Main caveat: If the same sending stream authenticates cleanly at control recipients, Microsoft-side DNS or authentication handling is still a suspect, but you need evidence from the exact rejected attempts before escalating it.
What Microsoft 550 5.7.515 means
Start with the NDR line and the rejecting server, not the ESP's bounce category. For Microsoft consumer recipients, 550 5.7.515 means that the visible 5322.From domain did not meet the required authentication level. Microsoft's high-volume threshold is 5,000 or more messages per day to its consumer services. Traffic from subdomains counts toward the primary domain's total, as Microsoft explains in its sender requirement clarification. Raw SPF and DKIM checks must both pass, and DMARC must pass through SPF and/or DKIM alignment. See Microsoft's 550 5.7.515 guidance for the documented requirements.
The standard DMARC rule remains simple: a message passes DMARC when SPF or DKIM passes and that authenticated domain aligns with the visible From domain. Microsoft's separate high-volume requirement explains why the same result can show DMARC=Pass and still end in rejection.
Check the exact error code before applying this explanation. Microsoft 365 error 550 5.7.509 means the receiver evaluated DMARC as failing with a reject policy. If another copy shows DMARC passing, compare the same SMTP attempt and receiving hop, including any forwarding path. Microsoft's NDR reference distinguishes this failure from other policy rejections.
Read the bounce literally
If the bounce contains Spf=Pass, Dkim=Fail, and DMARC=Pass, investigate why raw DKIM verification failed on the rejected messages. If the NDR instead reports Spf=Fail, Dkim=Pass, and DMARC=Pass, investigate SPF. The passing DMARC result does not repair either failed check.
Example Microsoft bounce patterntext
smtp;550 5.7.515 Access denied sending domain example.com does not meet the required authentication level The sender's domain in the 5322.From address does not meet requirements Spf=Pass, Dkim=Fail, DMARC=Pass
Illustrative Exchange admin center message trace for Microsoft 550 5.7.515 with SPF pass, DKIM fail, and DMARC pass.
Microsoft's DMARC setup guidance confirms the underlying logic: DMARC can pass when either an SPF-authenticated or DKIM-authenticated domain aligns with 5322.From. That standard rule explains the DMARC pass. The extra consumer sender requirement explains the rejection. See Microsoft DMARC setup for the baseline DMARC mechanics.
Why DMARC passes when DKIM fails
DMARC does not require both SPF and DKIM to pass. It checks whether at least one successful authentication result uses a domain aligned with 5322.From. Microsoft can then apply its additional high-volume rule and reject the same message because the other raw authentication check failed.
Standard DMARC pass
- SPF path: SPF passes for 5321.MailFrom and that domain aligns with 5322.From.
- DKIM path: DKIM passes and its d= signing domain aligns with 5322.From.
- Pass rule: Only one aligned path has to succeed for DMARC to pass.
Microsoft high-volume check
- Volume trigger: Microsoft's threshold is 5,000 or more messages per day to consumer services, with subdomain traffic included in the primary domain's count.
- Extra rule: Raw SPF and DKIM checks both need to pass, while at least one must match 5322.From for DMARC.
- Bounce signal: A DKIM failure inside a 550 5.7.515 NDR explains the rejection even when DMARC passes.
This difference matters when an ESP uses its own return-path domain. SPF can pass for that envelope domain without aligning with your visible From domain, while DKIM supplies the aligned DMARC path. Microsoft still expects the raw SPF result and the raw DKIM result to pass. Authentication and alignment therefore need separate checks.
Why Microsoft rejects an email with SPF pass, DKIM fail, and DMARC pass.
Authentication pass versus alignment
A raw authentication pass answers whether a sending source or signature is valid for its own domain. Alignment answers whether that authenticated domain matches the visible 5322.From domain under the DMARC mode. A result such as SPF pass does not prove SPF alignment, and a DKIM pass from an ESP-owned d= domain does not prove DKIM alignment.
|
|
|
|---|---|---|
5322.From | Visible author domain | Baseline for DMARC alignment |
5321.MailFrom | Envelope sender checked by SPF | Compare its domain with 5322.From |
DKIM d= | Domain that signed the message | Compare d= with 5322.From |
Authentication-Results | Receiver's raw and policy results | Read SPF, DKIM, DMARC, and domains together |
Fields to compare when Microsoft reports a 550 5.7.515 authentication failure.
Relaxed and strict alignment
DMARC defaults to relaxed alignment, where the organizational domains can match even when one side uses a subdomain. With aspf=s or adkim=s, the relevant domains must match exactly. Check those tags before treating a raw SPF or DKIM pass as an aligned DMARC path.
Read authentication results in DMARC reports
DMARC aggregate reports separate raw authentication from DMARC alignment. A DKIM failure in policy_evaluated does not prove the signature failed verification. Check auth_results before treating a dashboard percentage as a raw DKIM pass rate.
|
|
|---|---|
auth_results/dkim/result | Raw signature verification result for the reported signing domain and selector. |
auth_results/spf/result | Raw SPF result for the reported envelope domain. |
policy_evaluated/dkim and policy_evaluated/spf | DMARC results that require successful authentication and matching domains under the applicable alignment mode. |
source_ip and count | Identify the sending source and weight pass rates by message count rather than report-row count. |
Report fields to distinguish authentication failures from alignment failures.
For example, raw dkim=pass with DMARC-level dkim=fail means the signature passed but did not provide a matching DMARC path. Repair domain alignment instead of replacing a working key. RFC 9990 defines these report fields.
Aggregate reports contain grouped results, without individual message headers or the exact SMTP bounce. Their disposition describes DMARC policy handling. Correlate the reporting window and source IP with NDRs and sending logs to establish actual delivery outcomes.
What to check first
Work backward from the rejected Microsoft attempt. Do not average authentication over the whole day and call it solved. Pull the complete NDR and any attached original headers, then compare them with accepted messages from the same campaign, ESP stream, From domain, and DKIM selector. A delivered or later-forwarded copy does not prove what Microsoft evaluated during the rejected SMTP attempt. Use Microsoft's receiving-hop Authentication-Results when available. Earlier relay results and ARC-Authentication-Results describe other evaluations. Attached original headers do not always contain Microsoft's final result for the rejected attempt.
- Capture evidence: Save several complete Microsoft NDRs with UTC timestamps, message IDs, sending IPs, and attached original headers when present, plus accepted samples from the same path.
- Compare DKIM: Inspect every DKIM-Signature, its s= selector and d= signing domain, canonicalization, and body hash result. A failure for one signature does not prove all signatures failed.
- Check SPF: Confirm SPF passes for 5321.MailFrom and authorizes the actual outbound IPv4 or IPv6 address, then check that domain against 5322.From for DMARC alignment.
- Review DNS: Look for slow authoritative nameservers, DNSSEC failures, long CNAME chains, inconsistent TXT answers, and intermittent lookup errors.
- Trace changes: Find anything that modifies the subject, body, footer, encoding, tracking, MIME structure, or signed headers after DKIM signing.
A fast way to separate record problems from message-specific problems is to check public DNS first, then test a real sent message. Suped's domain health check reviews published authentication records and scans common DKIM selectors. Check the exact selector from the rejected message separately, since a common-selector scan cannot find every key or verify a message signature.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If the public records look clean, move to message evidence. A domain can have valid DNS records and still fail DKIM because the message changed after signing, Microsoft could not resolve the key at evaluation time, or only part of the outbound stream used the affected selector.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
DKIM failure patterns
If raw DKIM passes around 80% of legitimate messages on the affected stream, investigate the failures. First confirm that the percentage measures raw verification rather than DMARC alignment. A missing or invalid key used by every message tends to fail the full stream. Partial failures point to route differences, DNS resolution differences, content changes, or a subset of mail using another selector; some routes also omit signing entirely.
|
|
|
|---|---|---|
Message changed | Body hash mismatch | Sign after every content edit |
Selector split | Failures cluster by selector | Audit each active selector |
Key lookup issue | Intermittent DNS error | Stabilize authoritative DNS |
Route difference | Only one mail path fails | Use consistent signing |
Encoding rewrite | Body bytes differ | Keep encoding stable |
Unsigned route | No DKIM-Signature header | Enable signing on that outbound route |
Common causes behind Microsoft DMARC policy bounces when DKIM is inconsistent.
A common trap is testing one seed message and assuming that result applies to the full stream. A single successful test proves that one message, on one route, with one selector, at one moment, passed. It does not prove every message in the batch kept a verifiable DKIM signature through the full path.
A useful split test
- Same content: Send identical content through the production path and a stripped-down path without footers or rewrites.
- Same selector: Confirm both paths use the same DKIM selector and signing domain.
- Control recipients: Compare Microsoft recipients with non-Microsoft control recipients using full headers, not dashboard summaries.
DNS and forwarding issues
DNS matters because DKIM verification depends on Microsoft retrieving the public key for the selector. Intermittent timeouts, DNSSEC validation failures, or inconsistent authoritative answers can prevent verification even when the sender signed correctly. Preserve the exact result and diagnostic text: a DNS timeout can produce temperror, while a missing key is a permanent verification error. DKIM verification requirements distinguish temporary lookup errors from permanent failures.
Short TTLs do not automatically break DKIM. Raising a TTL from 3600 to 7200 seconds does not repair slow authoritative nameservers, DNSSEC validation errors, or records that differ between authoritative servers. Query every authoritative server directly and compare the returned selector key when the problem is intermittent. Build the lookup name as selector._domainkey.signing-domain using the signature's s= and d= values. During key rotation, compare cached answers with authoritative answers as well.
Authentication result triage
Use the affected message results to choose the next check. Microsoft does not publish an acceptable DKIM failure percentage for this requirement.
Authentication checks pass
SPF pass + DKIM pass
Confirm at least one successful path also meets DMARC alignment.
Lookup error
Temporary verification error
Investigate DNS availability and preserve the exact diagnostic text.
Verification failure
SPF or DKIM fails
Check the sending route, key, and signed message content.
Forwarding is another source to check early. A forwarded or relayed message can retain the original From domain while an intermediary appends a footer, rewrites MIME parts, or changes encoding. Those content changes can break the DKIM body hash. Relaxed canonicalization tolerates limited whitespace normalization, but it does not make appended content safe. Forwarding also changes the connecting IP, so SPF can fail even when the content and DKIM signature remain intact.
Do not treat 80% DKIM as acceptable
If raw DKIM passes on only 80% of legitimate messages on a direct Microsoft-bound high-volume stream, investigate the failing messages. DMARC can still pass through aligned SPF, but raw DKIM failures leave that traffic outside Microsoft's authentication requirements.
A practical fix sequence
Do not loosen DMARC to fix this bounce. Keep reporting active and repair the authentication path Microsoft rejected. A p=none policy satisfies Microsoft's minimum DMARC policy requirement, but changing quarantine or reject to p=none does not repair SPF or DKIM. That change removes the request to quarantine or reject DMARC failures; aggregate reporting continues when rua remains configured.
Example for a domain beginning DMARC monitoringtext
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Prove scope: Scope NDRs to Microsoft consumer recipients, then compare available Microsoft aggregate reports for the affected 5322.From domain and source IP. Calculate raw DKIM pass rates from auth_results, weighted by message count.
- Fix DKIM: Make every outbound route sign consistently, verify the public key for each selector, and confirm at least one passing signature aligns with 5322.From.
- Harden DNS: Use reliable authoritative DNS and avoid unnecessary CNAME chains. Retain retired selector keys until queued messages signed with them have cleared and relevant DNS cache lifetimes have expired.
- Validate SPF: Confirm SPF passes for 5321.MailFrom and check DMARC alignment. Publish one SPF record per domain and stay within the limit of 10 DNS-lookup-causing terms across nested evaluations; violations can produce permerror.
- Retest Microsoft: Send a controlled batch after DNS changes have propagated and compare new NDRs or accepted-message headers with the original rejected samples.
After publishing a DMARC record change, use Suped's DMARC checker to verify the record that resolves in DNS and its syntax. If you manage frequent policy changes, Suped's Hosted DMARC supports policy staging without repeated manual DNS edits.
Escalation evidence for Microsoft
- Samples: Provide complete NDRs, message IDs, UTC timestamps, recipient domains, and the reported authentication results.
- Control evidence: Show accepted messages from the same stream with the same From domain, selector, sending IP, and passing DKIM result.
- Pattern: Document whether failures cluster by selector, sending IP, UTC time, recipient domain, or Microsoft receiving host.
How Suped helps
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring groups aggregate results by source, domain, policy, and failure type. For this workflow, filter the affected 5322.From domain and sending source, then compare DKIM failures with Microsoft NDRs instead of relying on a healthy global pass rate. Distinguish raw verification failures from alignment failures, and use NDRs and sending logs to confirm rejected attempts.
Suped also surfaces authentication issues with guided checks and alerts. Use those signals to narrow the affected sending source, then inspect reported selectors and original message evidence before editing DNS.
Manual investigation
- Separate evidence: XML reports, NDR text, and headers need separate review.
- Broad averages: Microsoft failures can disappear inside unrelated recipient traffic.
- Manual correlation: Selectors and sending sources have to be matched across reports.
Suped workflow
- Focused filtering: Narrow authentication data by domain, source, and failure type.
- Issue alerts: Spot a DKIM failure increase before it becomes a sustained bounce pattern.
- Domain oversight: Track the same investigation across client or business domains.
Views from the trenches
Best practices
Save full headers for bounced and delivered samples before changing DNS or sender settings.
Track Microsoft consumer domains separately because their bulk sender rules add checks.
Keep DKIM selectors simple, stable, and documented across every active sending route.
Common pitfalls
Treating DMARC=Pass as final hides DKIM failures that still trigger Microsoft bounces.
Changing TTLs alone misses weak DNS hosting, stale selectors, or inconsistent TXT answers.
Testing one seed message can hide routing differences inside the actual production stream.
Expert tips
Compare identical messages at Microsoft and control recipients before blaming one provider.
Look for encoding or footer changes after signing when DKIM fails only part of the time.
Escalate with message IDs, timestamps, selectors, and full NDR text, not summary rates.
Expert view
Expert from Email Geeks says this is not automatically a DMARC policy error when the result says DMARC passed; Microsoft-side DNS or authentication handling still needs investigation.
2025-09-04 - Email Geeks
Marketer view
Marketer from Email Geeks says Microsoft's high-volume sender rules require both SPF and DKIM checks to pass, while DMARC still needs only one matching authenticated path.
2025-09-05 - Email Geeks
When to escalate to Microsoft
If Microsoft continues returning 550 5.7.515 after controlled tests show passing SPF, DKIM, and DMARC on the same sending path, escalate with the evidence listed above. Include the rejecting Microsoft host and exact UTC times so the failed attempts can be traced. A 550 response is a permanent failure for that SMTP attempt. Repair the cause before a controlled resend.
