2026 Outlook.com 550 5.7.515: How to Troubleshoot — Developer Acceptance Checklist

Verdict: Fix the sending domain’s authentication and alignment; changing the test recipient will not resolve Outlook.com 550 5.7.515. First confirm that Microsoft’s high-volume sender requirement applies to your sending domain, then inspect SPF, DKIM, DMARC, and the identifiers used by your sending provider.

This guide is for developers and operators responsible for their product’s sending domain and DNS authentication.
QA engineers can use it to separate a sender rejection from a message that was accepted but did not appear in the inbox.
If you manage a third-party sending integration, use the same checks to verify that it sends on behalf of your domain as intended.

Last updated October 22, 2026; checked against Microsoft’s error guidance and high-volume sender policy. Confirm current policy details in the Microsoft error explanation and Microsoft’s high-volume sender requirements before treating a configuration change as complete.

Start with the rejection, not the inbox

An Outlook.com 550 5.7.515 response is a sender-side rejection associated with Microsoft’s authentication requirements for high-volume senders. It does not mean that Microsoft accepted the message and routed it to Junk. Nor does it show that a test address failed to receive an otherwise accepted message. Microsoft’s specific troubleshooting guidance is the reference for interpreting the error.

Begin with the complete non-delivery report (NDR), not a screenshot of the final line. Preserve the diagnostic text, the recipient domain, the message ID, and the time of the attempt. If your sending service exposes its SMTP transcript or delivery event, save that too. You need evidence from the receiving system to distinguish a rejection from a message that was accepted but filtered, delayed, or routed elsewhere.

Check which service actually handled the recipient. Outlook.com, Hotmail, and Live.com addresses are Microsoft consumer mailboxes, but a forwarding rule or a corporate gateway can put another system in the delivery path. The reported SMTP response and NDR are stronger evidence than the address suffix alone.

Record the domain shown in the visible From header as well. That is the domain your product presents to the recipient. Do not assume it is the same domain your provider uses for the SMTP envelope sender or DKIM signature. Those identities matter later when you evaluate SPF, DKIM, and DMARC alignment.

Establish whether Microsoft’s high-volume policy applies

Microsoft’s requirement is not a universal statement that every sender account will be rejected unless it meets the high-volume sender rules. Microsoft describes high-volume senders in terms of messages sent to Outlook.com consumer addresses. Its published definition uses a threshold of more than 5,000 messages per day to those addresses; check the current Microsoft policy wording before applying that threshold to your own traffic.

Do not infer applicability from the number of accounts in your application, your provider’s total volume, or the number of messages sent to all domains combined. Work from the scope Microsoft describes and the evidence in your own sending setup. Identify the recipient platform, the domain in the message’s From header, and the domain or domains used by the provider for the envelope sender and DKIM signing. Keep the exact error text alongside those details.

For a product that uses a third-party sending service, ask which domain the provider uses for the message’s envelope sender and DKIM signature. A provider dashboard can report a successful send or a configured domain while the resulting message still uses identities that do not match your visible From domain. “Accepted by our provider” is not equivalent to “accepted by Outlook.com.”

If you cannot establish that the reported rejection is from Microsoft or that the message falls within the policy’s stated scope, avoid presenting the high-volume rule as a proven cause. Continue to check the message headers and authentication results, but record the applicability question as unresolved until the sending path and error evidence confirm it.

Read the authentication results as a chain

SPF, DKIM, and DMARC answer related but different questions. A DNS record being present does not prove that the receiver evaluated the expected message identity, and a passing result for one mechanism does not automatically prove that DMARC alignment passes.

SPF checks whether the sending host is authorized for the domain used in the SMTP envelope. In message diagnostics, this is generally associated with smtp.mailfrom, also known as the 5321.MailFrom identity. The visible sender in the email client is the From header, referred to as 5322.From. These values can differ.

DKIM checks a cryptographic signature and identifies the signing domain through the d= value. A valid signature shows that the signed content passed the receiver’s verification for that signing domain. It does not, by itself, prove that the signing domain aligns with the visible From domain.

DMARC evaluates the visible From domain against SPF and DKIM results. For a DMARC pass, at least one of those mechanisms must both pass and align with the 5322.From domain under the applicable alignment mode. That is why “SPF pass” or “DKIM pass” in isolation is not a sufficient acceptance test. See Microsoft’s overview of email authentication and the IETF DMARC specification, RFC 9989 for the mechanisms and alignment model.

Use a received message’s Authentication-Results header as evidence of what the receiving system evaluated. If a rejection prevents you from receiving a message header, use the sending provider’s diagnostics and DNS records to investigate, but do not label an unobserved receiver result as a confirmed pass. Microsoft documents relevant message-header fields in its header reference.

When a provider sends on behalf of your product, inspect the identifiers on the message that was actually sent. Do not rely only on the provider’s account screen or on a DNS lookup that proves a record exists. The practical question is whether the received message authenticates using the expected domains and whether at least one passing mechanism aligns with the visible From identity.

FAQ: Interpret the error and plan the retest

What the code establishes

A 550 5.7.515 NDR establishes that Outlook.com rejected that delivery attempt with the stated policy error. It is evidence about that message and that receiving path. It is not a general diagnosis for all Outlook.com messages from your product, and it does not establish that the message reached a spam folder. Preserve the full NDR because its context helps you confirm the recipient system and reported sender domain.

How rejection differs from spam placement

A rejected message was not accepted for normal mailbox delivery by the responding system. A message in Junk was accepted and then classified or routed by the receiving service. Compare the SMTP response, NDR, and provider event before making that distinction. If the provider reports acceptance but you cannot find the message, check mailbox folders and delivery details; do not attribute that case to 550 5.7.515 without the corresponding rejection evidence.

Why a passing mechanism can still leave DMARC misaligned

SPF may pass for the envelope domain while the user-visible From uses another domain. DKIM may pass for a signing domain that also differs from the visible sender. DMARC checks alignment, not simply whether a mechanism passed. Review smtp.mailfrom, the DKIM d= value, and 5322.From together, then compare the results with the receiver’s alignment outcome.

What counts as a meaningful retest

A meaningful retest follows the same product path, sending provider, and sender configuration that produced the rejection. Save the provider’s SMTP or delivery result, the full NDR if one returns, and the headers of any successfully received message. Then check the authentication results and alignment again. A clean result from one controlled recipient demonstrates that attempt’s outcome, not a universal promise of delivery.

Checklist: Validate the fix before release

Use this checklist for your own product’s test or pre-production mail flow. Keep the evidence with the configuration change so another engineer can distinguish verified results from assumptions.

• [ ] Preserve the original failure. Save the complete NDR, including the SMTP diagnostic, recipient domain, sender details, and message identifier. Keep the timestamp from your mail system so you can match the failure to provider logs.
• [ ] Confirm the recipient platform. Verify whether the response came from Microsoft’s consumer mail service or from an intermediate gateway. Record the evidence; do not rely only on an address suffix or an application-level “send succeeded” event.
• [ ] Capture the sender identities. Record the visible From domain, the provider’s envelope sender domain, and the DKIM signing domain. If you cannot see the final message headers, obtain the identities from the sending provider’s diagnostics and mark that evidence as provider-reported.
• [ ] Check policy scope. Compare your Outlook.com-bound sending volume and the relevant sender domain with Microsoft’s current high-volume sender definition. Do not extend the rule to all accounts or all mail destinations without support from Microsoft’s published wording.
• [ ] Inspect SPF for the actual envelope domain. Confirm that the DNS record authorizes the service that sends your product’s mail. Then verify the receiver’s SPF result for a message from the same route. A record lookup alone does not show what the recipient evaluated.
• [ ] Inspect DKIM on the delivered message. Check that a signature is present, that its verification passes, and that the d= value is the domain you expect. If the provider signs with its own domain, confirm whether the integration supports signing with your domain and how it is configured.
• [ ] Check DMARC and alignment. Compare the visible From domain with the authenticated SPF domain and DKIM signing domain. Confirm the receiver’s DMARC result and which passing mechanism, if any, aligned. Do not call the message compliant based solely on a passing SPF or DKIM result.
• [ ] Review third-party sending configuration. Verify that your domain is authorized with the provider and that the provider is using the expected envelope and signing identities. Check for differences between test and production configurations, including any separate sending streams used by your application.
• [ ] Send a controlled test through the product. Trigger the message from the same application path and environment that produced the failure. Use a controlled recipient you can inspect, and save the SMTP response, provider event, NDR if returned, and received headers if delivered.
• [ ] Repeat after the DNS or provider change. Allow the relevant DNS change to become visible to the systems involved, then send another controlled message. Compare its identities and authentication results with the original evidence rather than relying on a green dashboard status.
• [ ] Document the outcome precisely. Separate the configuration change, observed authentication results, and delivery outcome. If you received the message, note that this recipient accepted that attempt. Do not turn one successful test into a claim that all Microsoft consumer mailboxes will accept future messages.

Expand regression testing only when evidence supports it

After the controlled test, decide whether to widen the regression scope based on the observed outcome. If the same 550 5.7.515 response returns, preserve the new NDR and compare its sender and recipient details with the original. Check whether your test actually used the updated configuration. A repeated error can point to an unapplied DNS or provider change, an identity mismatch, or a remaining authentication issue; it is not a reason to keep changing unrelated settings without evidence.

If the rejection no longer occurs and the receiver reports the expected authentication results, record that result for the exact route tested. Then decide whether the release needs tests for other application environments, sending providers, or message types. A password-reset message, a notification, and a marketing stream may use different sender identities or provider settings. They should not be assumed to share one verified configuration merely because one test message passed.

Keep three categories separate in the release record:

• Configuration changes: DNS records, provider authorization, envelope sender settings, DKIM signing, or application-level sender selection.
• Verified evidence: the SMTP response, complete NDR, message headers, authentication results, alignment outcome, and recipient platform.
• Open questions: results not visible to you, untested sending paths, and delivery outcomes that remain unexplained.

This record makes a later incident easier to diagnose. It also prevents a common QA mistake: treating an accepted test message as proof that the complete mail flow is healthy for every recipient. Microsoft’s error guidance and the authentication results in the message should remain the reference points when you review a later failure.

Use a controlled recipient for content checks, not authentication fixes

Once the sending identities and domain authentication are configured, a separate test inbox can help you inspect the actual product email: its visible sender, subject, body, links, and headers. It can also keep a test message away from a personal or work inbox. That is useful evidence for a controlled acceptance run.

A test inbox cannot authorize your sending server in SPF, create a DKIM signature, or make a misaligned domain pass DMARC. It cannot prove why Microsoft rejected an earlier message, and it cannot guarantee that another recipient will accept a later one. Resolve the sender-side problem first; use the controlled recipient afterward to verify what the configured product actually sends and what the receiving system reports.

If you need a separate recipient for a short-lived product check, EmailPut is an option for keeping that test separate from your primary inbox. Use it to inspect a message that reaches the inbox, while keeping the SMTP response, NDR, and authentication evidence as the basis for diagnosing 550 5.7.515.

Frequently asked questions

What does an Outlook.com 550 5.7.515 bounce tell me?

It indicates that Microsoft rejected the message under its authentication requirements for high-volume senders. It is not the same as a message being accepted and placed in Junk. Keep the full non-delivery report and confirm the receiving service and the sender domain shown in the error before changing DNS or blaming the test inbox.

How can I tell a rejection from a message that went to Junk?

Check the SMTP outcome and the complete non-delivery report first. A rejection includes a failed delivery response from the receiving system; a Junk-folder issue means the receiving system accepted the message but classified it differently. If you have no bounce, inspect the sending provider's delivery event and the recipient mailbox before treating it as this specific error.

Why can SPF or DKIM pass while DMARC alignment fails?

A passing SPF result authenticates the envelope sender domain, while DMARC also compares that domain with the visible From domain. DKIM can pass for its signing domain, but that domain must align with the visible From domain for that signature to contribute to DMARC success. A pass for either mechanism alone does not prove that the domains align.

How should I verify the fix before releasing an email change?

Send a controlled message through the same application and sending provider used by the product. Save the SMTP response, any bounce, and the received message headers. Confirm the relevant SPF, DKIM, and DMARC results and their alignment, then repeat the test against the affected Microsoft consumer mailbox. A successful test supports this configuration; it does not guarantee delivery for every recipient.