Why are my emails receiving Microsoft 550 5.7.515 access denied bounces despite correct authentication?
Updated on 22 Oct 2026: We clarified Microsoft's authentication requirements and added steps for investigating persistent 550 5.7.515 bounces.
The direct answer is that Microsoft can reject mail with 550 5.7.515 even when authentication passes in an earlier test. For high-volume domains, Microsoft requires both SPF and DKIM to pass, plus DMARC to pass through at least one mechanism aligned with the visible From domain. A message can look correct at the original sender but fail after forwarding or content changes, use an unaligned Return-Path or DKIM domain, or encounter a DNS lookup failure when Microsoft evaluates it.
A bounce can show SPF Fail, DKIM Pass, and DMARC Pass. That result is valid because aligned DKIM can make DMARC pass, but it still fails Microsoft's separate requirement that both SPF and DKIM pass for a high-volume sender domain.
Fast answer
- DMARC pass: At least one of SPF or DKIM passed and aligned with the 5322.From domain, but that does not prove both checks passed.
- SPF fail: A fail can appear after forwarding because SPF checks the last connecting server against the 5321.MailFrom domain.
- DKIM fail: A fail can appear when a relay or filter changes signed headers or body content after the original send.
- Transient DNS: Short-lived resolver or lookup issues can make a correct DNS record fail at Microsoft's side.
What the bounce means
The Microsoft support note says this NDR applies to Outlook.com and related consumer services such as Hotmail, Live.com, and MSN. The stricter requirements apply when a domain sends 5,000 or more messages per day to those services using the same 5322.From domain. Count traffic across every sending service using that From domain, not just one mailbox or campaign. Once the domain reaches the threshold, the requirement covers all its senders, including transactional mail.
Check the rejecting server and recipient service. This requirement concerns Outlook.com consumer delivery; Microsoft 365 business recipients have separate policies, even when the sender uses the same Outlook application.
Typical 550 5.7.515 bounce text
550 5.7.515 Access denied, sending domain example.com doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. Spf= Fail, Dkim= Pass, DMARC= Pass
The important phrase is 5322.From. This is the visible From address, also called the P2 sender. Microsoft checks whether SPF and DKIM pass and whether at least one of them meets DMARC domain matching requirements for this domain.
|
|
|
|---|---|---|
SPF Fail | The connecting IP was not authorized for the 5321.MailFrom domain. | Return-Path, authorized sources, forwarding, and DNS lookup count. |
SPF Temperror or Permerror | Temperror indicates a temporary lookup problem; Permerror indicates a record or evaluation error. | DNS availability for Temperror; duplicate SPF records, syntax, and the 10-lookup limit for Permerror. |
DKIM Fail or None | Fail means signature verification failed; None means no signature was available to evaluate. | Active selector, public key, signing domain, and changes to signed content. |
DMARC Pass | At least one passing mechanism aligned with the 5322.From domain. | Which mechanism aligned, and whether the other mechanism still failed. |
SPF Pass, DKIM Pass, DMARC Fail | Neither passing mechanism meets DMARC domain matching requirements, or the DMARC record cannot be evaluated. | Visible From domain, smtp.mailfrom, DKIM d= domain, and the published DMARC policy. |
Delayed NDR | An intermediate system accepted the message before a later delivery attempt failed. | Reporting-MTA, Remote-MTA, Diagnostic-Code, and Received headers; timing alone does not prove forwarding. |
How to read the signals in the NDR
Microsoft high-volume sender threshold
Microsoft applies stricter authentication when a domain sends 5,000 or more messages per day to its consumer email services using the same 5322.From domain.
Below threshold
Under 5,000 daily
Check combined traffic across all services using the From domain and confirm the rejecting host before assuming the rule does not apply.
High volume
5,000+ daily
Both SPF and DKIM must pass, with a valid DMARC policy and at least one passing mechanism meeting DMARC domain matching requirements.
Why correct authentication still fails
Treat this error as a Microsoft-facing authentication problem first, then verify DNS configuration. If the domain passes at the sending platform, check whether the same result survives routing, forwarding, filtering, and Microsoft's DNS evaluation.
- High-volume rule: Microsoft requires SPF and DKIM records, both checks to pass, DMARC to pass, and at least one passing mechanism to meet DMARC domain matching requirements for the 5322.From domain.
- Single-mechanism DMARC: DMARC can pass through aligned DKIM while SPF fails, or through aligned SPF while DKIM fails. That still falls short of the separate both-must-pass rule.
- Forwarded mail: A recipient rule, alias, or mailbox forward can make SPF fail because the forwarder becomes the connecting server.
- Changed content: A disclaimer, URL rewrite, footer, or security filter can break DKIM by changing signed content after send.
- DNS variance: A record can resolve correctly for one test but fail during a short resolver, cache, delegation, or DNSSEC problem.
- Recipient path: If only some Outlook.com addresses fail, compare their delivery paths and NDR timestamps before treating the issue as domain-wide.
Direct delivery
A direct delivery path gives SPF and DKIM the best chance of passing because Microsoft sees the sending server and signed content as intended.
- SPF check: The connecting IP is authorized for the 5321.MailFrom domain.
- DKIM check: The signature survives because no hop changes signed headers or body content.
- DMARC check: At least one passing mechanism meets DMARC domain matching requirements for the visible From domain.
Forwarded delivery
A forwarded path changes the evidence Microsoft receives. The original message can authenticate correctly while the later hop fails the final check.
- SPF check: The forwarder's IP is checked against the envelope sender it presents. Sender Rewriting Scheme (SRS) can restore SPF for the forwarder's domain, but does not by itself restore DMARC alignment with the original From domain.
- DKIM check: The signature fails when the forwarder modifies signed content.
- ARC check: ARC helps only when the chain is present, valid, and trusted by the receiver.
SPF, DKIM, DMARC, and forwarding checks in a Microsoft 550 5.7.515 rejection path.
How to diagnose Microsoft 550 5.7.515
Start with the full delivery status notification (DSN) and the message headers available to you. An SMTP rejection does not produce a delivered recipient copy, so ask the sending service for its outbound SMTP log and the message as transmitted after DKIM signing. Compare the Reporting-MTA, Remote-MTA, and Diagnostic-Code fields to identify the rejecting hop; a delayed NDR alone does not identify forwarding.
- Confirm timing: Check when the failure occurred and which server returned it; a queued outbound attempt can also produce a delayed NDR.
- Compare domains: Compare the Return-Path or 5321.MailFrom domain (P1 sender), the 5322.From domain (P2 sender), and the DKIM signing domain.
- Read results: Use the NDR and receiver-stamped Authentication-Results for that hop when available. Compare spf, smtp.mailfrom, dkim, header.d, dmarc, and header.from; an earlier sender-side pass does not prove Microsoft saw the same result.
- Check DNS: Run a domain health check for SPF, DKIM, DMARC, delegation, and obvious DNS issues.
- Send proof: Use Suped's email tester to inspect live headers, then send a controlled test through the affected route to a Microsoft consumer mailbox.
- Group bounces: Separate failures by Microsoft recipient domain, 5322.From domain, source IP, sending service, and timestamp.
Microsoft's authentication header reference distinguishes SPF lookup errors from authentication failures. Inspect the reported result before editing DNS.
For a live test, use the same sending service, From domain, DKIM selector, Return-Path pattern, and content path that produced the bounce. A test from a different route can pass while the affected production route still fails. Passing at a test mailbox is evidence about that delivery only.
If the bounce affects transactional mail, test the exact template class that failed. Per-customer routing or content changes after DKIM signing can affect verification even when DNS is identical. For Exchange Online senders, message trace helps retrieve the outbound rejection; other senders should use their provider's delivery logs.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the live test passes but Microsoft bounces continue, look for a route-specific problem. Common causes include forwarding, a subset of recipient domains, a specific sending IP, a DNS resolver issue, or content modification after signing.
Keep the raw test output with the DSN and record timestamps in UTC. Check authoritative DNS and cached answers for the actual MailFrom domain and DKIM selector, including the selector's TXT record or CNAME target. After a DNS change, allow the relevant positive or negative cache TTL to expire before retesting.
Microsoft 365 admin center message trace showing a 550 5.7.515 rejection event.
Minimum DMARC record for Microsoft high-volume checks
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none
This is the minimum policy example, not a replacement for an existing working policy. Add a valid rua address separately to request aggregate reports; rua and fo=1 are not required for this Microsoft authentication check. Publishing p=none does not make a failing message pass DMARC.
Check every third-party sending service
Microsoft lists third-party sender configuration as a separate troubleshooting step. Check every service that sends with your 5322.From domain because one billing, support, marketing, or transactional route can trigger the NDR even when the primary mail system passes.
- Verify the Return-Path: Confirm the actual 5321.MailFrom domain and that its SPF record authorizes the connecting source. A provider-owned Return-Path can pass SPF while your own DKIM signing domain supplies DMARC alignment.
- Verify DKIM signing: Enable signing with your domain, verify the d= signing domain and s= selector, and publish the matching key at selector._domainkey.signing-domain. Confirm the signature survives the full production route.
- Verify DMARC alignment: Confirm at least one passing mechanism meets the From domain's DMARC matching requirements. Both SPF and DKIM must still pass, but both authenticated domains do not have to match the visible From domain.
- Test each route: Send through every active service and subdomain using production Return-Path, DKIM selector, headers, and content.
DMARC alignment defaults to relaxed matching: the authenticated domain and visible From domain share an organizational domain. For example, bounces.example.com can match example.com. With aspf=s or adkim=s, the relevant domain must match exactly. SPF can pass for a provider-owned domain while DKIM supplies the required match. See Microsoft's DMARC configuration guidance.
What to inventory
List every system allowed to use the visible From domain, then record its source IPs, SPF authorization, 5321.MailFrom domain, DKIM signing domain, selector, and message purpose. Remove obsolete authorization only after confirming that no production route depends on it.
Fix SPF, DKIM, and DMARC failures
The right fix depends on the result Microsoft received. Use the bounce as evidence, then confirm it with headers and DMARC aggregate data. The Microsoft support note requires working SPF, DKIM, and DMARC for high-volume domains sending to Microsoft consumer recipients.
|
|
|
|---|---|---|
SPF path | SPF fails while DKIM and DMARC pass. | For direct sends, authorize the observed source in the actual MailFrom domain's SPF record. For forwarding, investigate the forwarder rather than adding its IP to your original SPF record. |
SPF Permerror | The actual MailFrom domain has duplicate SPF records, invalid syntax, or exceeds the evaluation limit. | Publish one SPF record per domain and keep evaluation within 10 DNS-triggering terms, including nested includes and redirects. |
DKIM break | DKIM fails after a relay or filter. | Sign later in the route or stop changing signed content. |
Forwarding | Received headers and SMTP logs identify a forwarding hop. | Review recipient-side forwarding, preserve DKIM, and check the forwarder's SRS and ARC handling. Receiver trust still determines ARC acceptance. |
DNS issue | Lookup errors or inconsistent DNS answers coincide with failures. | Check delegation, TTLs, DNSSEC, and resolver variance. |
Third-party sender | Only one service or selector produces failures. | Correct that service's Return-Path, SPF authorization, DKIM signing, and alignment. |
Common causes and practical fixes
Do not fix the wrong thing first
- DMARC policy: Do not change p=none to p=reject to solve this. Microsoft accepts p=none as the minimum policy; a stricter policy does not repair SPF or DKIM.
- SPF changes: Do not add broad includes unless the 5321.MailFrom domain and connecting IP evidence point there.
- Retry loops: 550 is a permanent SMTP failure for that attempt. Stop automatic retries of the unchanged message; send a controlled new attempt after correcting the cause.
If Microsoft bounces use several response codes, compare their wording with a general 550 bounce guide. That separates authentication-specific 5.7.515 failures from relaying, recipient policy, reputation, and other 550-class errors. A 5.7.515 bounce does not establish that the recipient address is invalid.
When tests pass but Microsoft still rejects
A current DNS check or a successful delivery elsewhere does not establish what Microsoft evaluated for a rejected message. If the NDR appears to contradict passing tests, preserve the evidence before making further changes.
- Match the failed attempt. Record the complete NDR, UTC timestamp, Message-ID, source IP, rejecting host, affected recipient, and visible From domain. Include the envelope sender plus DKIM d= and s= values.
- Compare a successful sample. Use the same service, source IP, template, and signing selector where possible. Confirm both results concern the final Microsoft-facing delivery rather than an earlier relay or a different test inbox.
- Ask the sending provider to investigate. Supply its outbound SMTP transcript and the signed message it transmitted. Request a comparison of successful and failed routes, selector lookups, and authentication results at the failure time.
- Escalate persistent contradictions through Outlook.com sender support. Include the evidence and any provider case reference, especially if Microsoft reports SPF, DKIM, and DMARC passing in the rejected attempt. Share recipient details privately, and request investigation rather than assuming a receiver defect.
Retest the affected Microsoft route after the provider confirms the fix or the relevant DNS cache expires. A passing sample verifies that attempt; continue checking the affected sources before resuming normal volume.
Where Suped fits
Suped's DMARC platform combines DNS checks, aggregate reports, alerts, and remediation steps. For a 550 5.7.515 investigation, use the affected 5322.From domain to identify reported source IPs, compare SPF and DKIM alignment, and see whether failures cluster around one sender.
Start with DMARC monitoring to group reported pass and fail results by source for the From domain. Aggregate reports arrive after delivery attempts and do not cover every message or receiver, so keep the full NDR and sending logs alongside Suped's results. Hosted SPF helps when the actual problem is a lookup-limit error in an SPF domain you control.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Manual workflow
- Data split: Bounces, headers, DNS records, and aggregate reports sit in different places.
- Slow grouping: Teams spend time grouping failures by source, IP, domain, and recipient route.
- DNS risk: SPF changes can create lookup-limit issues or remove valid senders.
Suped workflow
- Issue detection: Suped groups failed sources and provides the related remediation steps.
- Alerts: Teams investigate newly reported authentication issues alongside bounce logs.
- Scoped fixes: Use the reported source and remediation steps to target the affected sending service.
Views from the trenches
Best practices
Identify the rejecting hop in logs before changing DNS or sender authentication settings.
Compare the failed leg in the NDR with full headers and aggregate DMARC data promptly.
Group failures by timestamp, Microsoft recipient domain, sending IP, and visible From domain.
Common pitfalls
Assuming DMARC pass means Microsoft accepted every required SPF and DKIM authentication check.
Treating forwarded mail the same as direct delivery when SPF evidence has changed.
Changing the DMARC policy before proving which authentication check or delivery hop failed.
Expert tips
A tiny failure rate still matters at high volume because it creates many visible bounces.
ARC helps forwarded mail only when the chain is valid and the receiver trusts the seal.
Short resolver incidents can make a correct DNS record fail for one receiver temporarily.
Marketer view
Marketer from Email Geeks says short DNS lookup failures can produce this error even when the published records are correct and later tests pass.
2025-06-12 - Email Geeks
Marketer view
Marketer from Email Geeks says delayed bounces often point to forwarding, where SPF fails because Microsoft sees the forwarding server.
2025-06-13 - Email Geeks
Verify the fix before resuming volume
After correcting the affected source, send a controlled test through the same production route to a Microsoft consumer mailbox. Confirm the delivery result and the authentication evidence available for that attempt, then check bounce logs for the same source before resuming normal volume.
Practical close-out checklist
- Headers captured: You have the full DSN, available message headers, and outbound SMTP logs for the failed attempt.
- Path known: You identified the rejecting hop from logs and headers rather than assuming every delayed NDR means forwarding.
- Mechanisms proven: You know whether SPF and DKIM passed at the Microsoft-facing hop and which mechanism aligned for DMARC.
- Change scoped: Any DNS or signing change targets the source and domain that produced the failure.
