An order confirmation to a @hotmail.com or @outlook.com address comes back immediately. The ESP calls it a bounce. The text says 550 5.7.515. Nothing reached the customer, and clicking “resend” sends the same refusal again.
Microsoft’s support article for this code is specific. The domain in the visible From address (5322.From) did not meet the authentication level Outlook.com requires of high-volume senders. This page follows that article. It does not add a complaint-rate percentage Microsoft does not publish for this error.
Last verified: 26 September 2026, against Fix NDR error 550 5.7.515 and the Outlook.com postmaster announcement.
What the error actually says
The text Microsoft documents is:
550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.
The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender.
550 means the receiving server refused the message. SMTP 4xx vs 5xx explains why a 5xx is a refusal and not a retry. It is not sitting in Junk waiting to be found. If your question is “the dashboard says delivered and the customer cannot find it,” that is a different problem, covered in delivered but not received.
Who the rule applies to
Microsoft defines a high-volume sender with both of these:
- You send 5,000 or more messages per day to Microsoft consumer services (Outlook.com, Hotmail, Live, MSN).
- Those messages use the same domain in the
5322.Fromaddress.
After a domain crosses that line, Microsoft expects all messages from senders on that domain to meet the authentication rules. A store that only sends a few hundred Outlook messages on a quiet day can still be inside the rule if the domain has already been a high-volume sender.
Microsoft’s high-volume authentication rules date from 5 May 2025 (not from 2026). The postmaster announcement said non-compliant mail would go to Junk first and that rejection would follow. For the Gmail and Yahoo side of the same shift, see the Gmail bulk sender requirements guide. The current NDR article documents 550 5.7.515 as a rejection. If you still see Junk placement without this bounce, you are in a different filtering path. If you see this code, the message was refused.
What Microsoft requires for this error
These are the three checks in the NDR article. They are requirements for the rejection, not general deliverability tips.
| Check | What Microsoft states | What it does not say |
|---|---|---|
| SPF and DKIM | Both checks must pass. SPF must authorize the host that sent the message. | A DMARC pass does not excuse a failing SPF or DKIM check. |
| DMARC record | Publish a TXT record at _dmarc. p=none, p=quarantine, and p=reject are all valid policies in the article. |
p=none meets the published minimum. It does not protect customers from spoofing. |
| DMARC alignment | At least one of SPF or DKIM must align with the domain in 5322.From. |
Both do not have to align. One is enough for the DMARC result. Both checks still have to pass. |
For a Klaviyo or SES store, the usual miss is alignment. The visible From is store.com, DKIM signs send.store.com or the ESP’s domain, and SPF is evaluated on a return-path the customer never sees. Each record can “exist” while the From domain still fails.
Gmail and Yahoo separately require one-click unsubscribe on bulk marketing mail, and they publish complaint-rate figures (stay under 0.10% at Gmail, avoid 0.30%; stay under 0.30% at Yahoo). Microsoft’s NDR article for 550 5.7.515 does not list those as the cause of this bounce. Fixing the footer unsubscribe link will not clear a DKIM failure. Do the authentication work this error names. Keep the Gmail and Yahoo unsubscribe work because those providers require it, and say so in the Gmail and Yahoo guides rather than attributing it to this SMTP code.
How to find it in an eCommerce account
Search the bounce or failure event for 5.7.515 and for Outlook.com, Hotmail, Live, or MSN domains. The reason text is the evidence. A campaign “delivery rate” can stay high when Hotmail is a small slice of the list, which is how a store loses order mail to Outlook customers and does not notice until support tickets arrive.
On Klaviyo, open the bounced profile and read the reason. Do not infer the code from a drop in opens. Opens are the wrong instrument, and they are a weak signal even when the mail was accepted.
What to fix, in Microsoft’s order
1. Read the header of a failed message. Confirm the return-path domain (5321.MailFrom) and the visible From (5322.From). Microsoft says that to use SPF for DMARC, those domains need to align.
2. SPF. The host that actually submitted the message must be authorized for the envelope domain. Extra lookup mechanisms past the SPF limit of 10 DNS lookups cause a permerror, which will not pass. The SPF generator is useful when you are rebuilding the record. It does not tell you which of your apps is missing.
3. DKIM. The message must be signed, and the signing domain must align with 5322.From if you are relying on DKIM for DMARC. In Klaviyo that is the branded sending domain under Settings, Email, Sending domains. The Klaviyo authentication guide is the click-path. In SES it is the identity’s DKIM CNAMEs. A signature that uses the ESP’s domain while the From uses yours will not satisfy alignment.
4. DMARC. Publish v=DMARC1; p=none if you have no record. Add an rua address if you want reports. Microsoft’s example does not require rua. The DMARC generator builds the TXT record. What DMARC is is the longer explanation. p=none stops this class of “no record” rejection. It does not quarantine spoofed mail.
5. Every service that sends as that From domain. Review apps, Shopify notifications, a helpdesk, and the ESP all have to be in SPF or DKIM for the domain on the From line. One unsigned source is enough to produce the bounce on the messages that source sends.
PTR records and one-click unsubscribe are real deliverability work. They are not the three checks Microsoft lists for this NDR. Do them so Gmail, Yahoo, and shared-IP reputation do not fail next. Do not expect them to clear 5.7.515 while DKIM is failing.
How to verify
Send a new message to an Outlook.com address you control, from the same From domain and the same platform that bounced. The bounce should be absent, and Authentication-Results should show SPF pass, DKIM pass, and DMARC pass.
InboxEagle’s seed list reports folder placement at Gmail, Yahoo, AOL and Outlook. A 550 5.7.515 is a rejection at SMTP time, not a folder placement, so the seed result cannot prove this rejection is gone. The bounce log can. DMARC monitoring checks your DMARC policy record every 24 hours and alerts when it changes. It does not track alignment or pass/fail on individual messages, so the Authentication-Results header on a test message is still where you confirm alignment.
Where the 2025 requirements overview lives
This page covers the rejection code. If you searched for “Microsoft Outlook bulk sender requirements SPF DKIM DMARC 2025”, the short answer is the table above: SPF and DKIM must both pass, and a DMARC record must be published and pass, for any domain sending 5,000 or more messages a day to Outlook.com, Hotmail, Live and MSN. For Microsoft’s wider 2025 sender rules next to the 2024 Gmail and Yahoo rules, start with the Gmail bulk sender requirements guide and SPF, DKIM, and DMARC explained, then come back here when the bounce text says 5.7.515.
What not to do
- Do not resend the campaign to the same Outlook addresses before a test message passes.
- Do not switch the From domain to a new one to escape the bounce. The new domain has to meet the same rules once it is high-volume, and it has no reputation. Changing a sending domain is a planned cutover, not a same-day escape.
- Do not tell the customer to add you to Safe Senders. That does not bypass this rejection.
When to escalate
Escalate to the ESP when your DNS matches their published records and a new message still shows DKIM fail or SPF fail. The signature they applied does not match the key you published, and only they can see the signed bytes.
Escalate to Microsoft’s sender support only after a message you inspect shows SPF pass, DKIM pass, and DMARC pass and Outlook.com still returns 550 5.7.515. Include the full NDR. The support article’s remedy is still authentication on the sending side.
SNDS (Smart Network Data Services), at the Outlook.com sender support site, is Microsoft’s view of IP-level complaint and trap data for IPs you register. Use it when Outlook filtering continues after this authentication error is gone. It does not replace the header check for 5.7.515.
InboxEagle
Confirm the From domain before you resend
550 5.7.515 is an authentication rejection. Check SPF, DKIM, and DMARC on the domain customers see, then watch the bounce log. Folder placement tests will not show this Outlook refusal, because the message is rejected before it reaches a folder.
Sources
- Fix NDR error 550 5.7.515 in Outlook.com, Microsoft Support. Definition of high-volume sender and the three authentication requirements.
- Outlook.com postmaster announcements, Microsoft. 5 May 2025 authentication enforcement notice.
- Email sender guidelines, Google. Cited only for the Gmail figures this Outlook error does not use.
- Sender best practices, Yahoo. Cited only so unsubscribe and complaint-rate rules stay attributed to Yahoo.