belkins.app

Guide / Outlook.com rejection

How to fix Outlook.com error 550 5.7.515

If an Outlook.com non-delivery report contains “550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level,” Microsoft rejected the message because the domain in its 5322.From address did not meet the documented level for high-volume senders. The rule is consumer-scoped; it does not establish the same result for Microsoft 365.

Folderly editorial owner reviewed 28 September 2026 constructed examples only

Microsoft defines a high-volume sender here as sending 5,000 or more messages to Microsoft consumer email services with the same domain in the 5322.From address. Once that scope applies, Microsoft says SPF and DKIM must both pass, a DMARC record must be published, and at least one of SPF or DKIM must align with the 5322.From domain. Microsoft’s NDR guidance is the primary source. The NDR is evidence of a rejection; it is not, by itself, evidence of which record or sending-service setting failed.

Confirm the route before editing DNS

Preserve the complete NDR, recipient domain, time, and sending path. Record whether the recipient is an Outlook.com, Hotmail, Live.com, or MSN consumer mailbox. A business Microsoft 365 tenant is out of scope for this page.

Next write the three identities side by side:

Three identities in an Outlook.com rejection review
Identity Evidence to capture Why it matters
5322.From The exact visible sender domain in the NDR or message header Microsoft’s high-volume definition groups messages by this domain.
5321.MailFrom / return path The envelope sender domain from the receiver-evaluated header Microsoft says this domain must align with 5322.From if SPF is the passing DMARC mechanism.
DKIM signing domain The d= domain and selector from the header Microsoft says the DKIM signing domain must align with 5322.From if DKIM is the passing mechanism.

Microsoft also says to check receiver SPF, DKIM, and DMARC results and verify that third-party services use the sender’s domain for the envelope and DKIM configuration. See Microsoft’s troubleshooting steps.

Diagnostic decision table

Use one row for the next action. Keep an unknown visible rather than turning a DNS lookup into a message-level conclusion.

Evidence, unknown, owner, and next action
Evidence Unknown Owner Action
NDR has 550 5.7.515 and the recipient is a Microsoft consumer mailbox. Whether this sender has reached Microsoft’s high-volume scope and which authentication check failed on the rejected message. Campaign or deliverability operator. Save the full NDR, 5322.From domain, recipient scope, volume estimate, ESP, and send time. Route the header and DNS review to the authorized operators.
The same-path header shows SPF or DKIM did not pass. Whether the record is missing the ESP’s authorized source, stale, or being evaluated for a different envelope or signing domain. DNS owner with the ESP operator. Compare the evaluated domains with the ESP configuration and selector. Update only the provider-supported record or setting, then test through the same path.
SPF or DKIM passes, but its domain does not align with 5322.From. Whether the ESP supports branded return-path or DKIM signing for this account. ESP operator, with the DNS owner available. Inspect the account’s custom-domain settings and current ESP documentation. Do not substitute a vendor domain for the client’s visible sender.
A DMARC record is absent or the receiver reports DMARC failure. Whether SPF or DKIM actually passed and aligned on this message; a published record alone does not answer that. DNS owner and deliverability operator. Review the DMARC record and the receiver’s evaluated results. Microsoft lists p=none, p=quarantine, and p=reject as valid policy values; the authorized owner must choose the policy appropriate to the domain.

A bounded repair path

  1. Classify the destination. Keep Outlook.com consumer mail separate from Microsoft 365 enterprise mail and other providers.
  2. Read the receiver evidence. Start with the NDR and a real header from the same ESP path. A dashboard badge is not the receiver’s result.
  3. Check authentication and alignment. For a high-volume consumer path, Microsoft expects SPF and DKIM to pass, with DMARC passing through at least one aligned mechanism.
  4. Assign and recheck. The DNS owner controls records; the ESP operator controls envelope and signing settings. Send an authorized test through the same path and save the receiver result.

Constructed example: an NDR names client.example in 5322.From; the ESP header shows SPF passing for bounce.vendor.example and DKIM passing for vendor.example. Those passes do not prove alignment. The operator must inspect the actual result and supported custom-domain setup.

Microsoft’s updated announcement says non-compliant high-volume messages began being rejected with 550 5.7.515 on 5 May 2025, superseding earlier Junk-folder wording. See the Microsoft Community Hub announcement. An older screenshot may therefore show a different outcome.

What establishes resolution—and what does not

Useful resolution evidence is a new authorized test to the same Microsoft consumer scope with no 550 5.7.515 rejection and a receiver header showing SPF and DKIM results plus a DMARC pass through an aligned mechanism. Keep the test date, recipient scope, 5322.From domain, ESP, and sanitized result together.

That test cannot prove inbox placement, sender reputation, list quality, acceptance by every Microsoft consumer mailbox, or behavior for another From domain, subdomain, ESP, volume, or recipient service. A DNS checker can show that a record is published; it cannot prove how a particular message was signed and evaluated. It also cannot turn a consumer Outlook.com result into a Microsoft 365 enterprise certification.

Scope fit / one sending path

When a scoped handoff helps

If the route, domain, and NDR are known but one authorized operator still needs a prioritized interpretation, request scope for one sending path. Folderly Launch Audit is the existing US$495 manual service for one domain or subdomain and one ESP/CRM path. After payment and complete intake, the agreed start begins a 48-hour report window with up to five prioritized actions and owners, a 45-minute handoff, and one recheck within seven days of the report. It is read-only advice; your authorized operator makes DNS and ESP changes. There is no implementation, warming, reputation recovery, list repair, multidomain review, or inbox-placement guarantee. Do not send credentials, raw headers, or customer lists in the request.

Prepare an editable scope draft
Aligned authentication compare the three domains Gmail 550 5.7.26 classify another authentication rejection Editorial method see how evidence is labeled

Sources and applicability. Sources reviewed 28 September 2026: Microsoft Support: Fix NDR error “550 5.7.515” in Outlook.com and Microsoft Community Hub: Outlook’s new requirements for high-volume senders. The support page says “5,000 or more” to Microsoft consumer services and does not state a time period in that definition. The announcement uses “more than 5,000 per day.” This guide preserves both wordings and does not claim a safe edge case. Neither source establishes the rule for Microsoft 365 tenants, non-Microsoft providers, every From domain, or inbox placement. The examples are constructed; this page reports no tested domain, customer launch, benchmark, ranking, traffic, or payment result.