550 5.7.515 in Outlook: What It Means and How to Fix It?

A campaign to Hotmail and Outlook.com came back with 550 5.7.515. The number looks like a broken server. Search results talk about blocklists, the Exchange admin screen, and a Microsoft test tool. Those are the wrong doors.

Here is the short answer. Microsoft bounced the email for good. The domain in the From line sends a lot of mail, and Outlook.com did not trust who sent it. Since May 5, 2025, a domain that sends 5,000 or more emails in one day to Outlook.com, Hotmail, Live, or MSN needs three records working: SPF, DKIM, and DMARC. SPF and DKIM both have to pass. DMARC has to pass too, and the name it checks has to match the From line people see. The fix is in those records. It is not a switch inside Microsoft 365. This guide covers what the bounce says, how it differs from 5.7.1 and from a login error, the three usual causes, and how long a DNS change takes.

What a 550 5.7.515 bounce back actually means

The full line, in Microsoft’s support page, looks like this:

550 5.7.515 Access denied, sending domain example.com does not meet
the required authentication level.

550 means the email is done. The server will not try again. 5.7.515 is Microsoft’s number for this rule. The domain in the line is the From people see, not always the hidden bounce address. The email never reached a mailbox. It did not go to junk. Outlook.com said no while the email was still on the wire.

That bounce notice sits in the sending tool’s log. The sender sees it. The person at Outlook.com never saw the email.

Copy the whole line before changing any record. The domain it names is the one to check next.

Why Outlook blocks outgoing email with 550 5.7.515

Microsoft shared the rule on April 2, 2025 on its Tech Community blog. The hard bounce for big senders started on May 5, 2025. At first the post said junk first, bounce later. A note on April 29 flipped that. The bounce with 550 5.7.515 started on the first date.

Big sender, in Microsoft’s words, is a From domain that sends 5,000 or more emails in one day to personal Outlook, Hotmail, Live, or MSN. After that, Microsoft wants every later email from that From domain to pass this bar:

1. SPF passes for the hidden sending domain.
2. DKIM passes. The email has a real signature.
3. The From domain has a DMARC record. p=none is enough.
4. DMARC passes because SPF matches, DKIM matches, or both.

That is tighter than Gmail’s basic rule, which accepts SPF or DKIM. The Gmail and Yahoo requirements post covers that side. Microsoft wants both checks to pass, and DMARC to match the From line.

The written rule is for personal inboxes. A work Microsoft 365 inbox has its own filter. Mail can fail at Hotmail and still get in at a company, or the other way around. The sending fix is the same: the records on the From domain. SaaS and receipt email can hit 5,000 in one day of receipts or password resets.

550 5.7.515 vs 550 5.7.1 vs SMTP authentication failures

Three different codes. Three different fixes. The table is the fast map:

Code	What it is	Where the fix lives
550 5.7.515	Outlook.com bounced a big sender on a trust check	SPF, DKIM, and matching DMARC on the From domain
550 5.7.1	A mixed group of hard bounces	The words after the code
535 / 5.7.3	The sending tool could not log in	Host, port, and password, before any DNS

550 5.7.1 is a group, not one answer. It already names 5.7.515 as a Microsoft cousin. This post is that cousin, written out.

A login error happens when the sending tool cannot sign in. 5.7.515 happens later, after the email left, when Outlook.com refused the From domain. A new SMTP password does not fix this bounce.

Start with the words after the code. If the line does not say 5.7.515 and authentication level, this page is not the map.

The three causes, ranked

When the bounce is really 5.7.515, these three cover almost every case.

1. Missing or failing SPF, DKIM, or DMARC

This is the most common cause on honest mail. The From domain is missing one of the three records. Or SPF does not list the computer that sent the email. Or DKIM is on, but the sending server does not sign. Microsoft wants both SPF and DKIM to pass, not just one.

The smallest DMARC record Microsoft accepts is one line:

_dmarc.example.com.  TXT  "v=DMARC1; p=none"

p=none is enough for this bounce. A report address (rua=) helps show who sends as the domain. It is not what causes the bounce. The how-to steps live in the SPF, DKIM, and DMARC guides. The SPF failure guide covers a record that exists when the sending IP does not.

Run the email health check on the From domain in the bounce. All three records need to show up. A red result here is already the cause.

2. The From name does not match what passed

SPF can pass on the sending tool’s bounce domain. DKIM can pass on the tool’s name. The From people read is still yours. DMARC looks at that From. If the names do not match, DMARC fails, and Microsoft says no.

A common header for this case:

Authentication-Results: outlook.com;
       spf=pass (sender IP is 203.0.113.10)
         smtp.mailfrom=bounce.esp.example;
       dkim=pass header.d=esp.example;
       dmarc=fail action=oreject
         header.from=yourdomain.com

The first two pass. The third fails. The DMARC fails when SPF passes post walks this line. The fix is a bounce address on your domain, or a DKIM signature that uses your domain, or both.

Open a test in the header analyzer. Compare smtp.mailfrom, header.d, and header.from. If the first two belong to the tool, the health check can be green and the bounce can still happen.

3. Another tool sends without your domain’s records

The newsletter tool, the help desk, the receipt app: each one has to be in SPF and has to sign DKIM with the From domain. Microsoft says this in the support page. A missing include:, or custom-domain DKIM left off in the tool, makes this 5.7.515 on one part of the list.

The clue is the split. Mail from Microsoft 365 itself arrives. The newsletter from the new tool bounces. The From domain is the same. The sending path is not.

Turn on the setting the tool calls custom sending domain. Publish every record it shows. Then send from that path again.

The fix, and how to check it

The bounce stops when a new email passes Microsoft’s four checks. Changing DNS and resending the same email proves nothing.

A one-person shop on Microsoft 365 and an IT admin do the same work. There is no 5.7.515 switch in Exchange admin. Custom-domain DKIM on Microsoft 365 still needs the selector1 and selector2 records in DNS. If a connector changes From to a domain without those records, the whole account can bounce. The unit is the From domain, not the Microsoft 365 account.

The Remote Connectivity Analyzer tests whether Outlook can connect. It does not read this bounce. The right checks are the health check, plus a header from a test mailbox you own.

Send the test after the wait time. On the header, look for spf=pass, dkim=pass, and dmarc=pass on the From the bounce named.

How long the error lasts after a DNS change

The internet keeps the old answer until the record’s wait time ends. A 3600-second wait is up to one hour. A 86400 wait is up to one day. Seeing the new value on a laptop does not mean Microsoft has seen it yet.

5.7.515 does not “clear.” It just stops. The email that failed stays failed. Only the next send, after the wait, answers the question.

If the bounce comes back after a day, and the new headers pass, another path is still broken. A tool without the include. A signature the server does not add. Or a From that is not the domain that was edited.

What this error is not

Three common searches lead to the wrong fix.

A Microsoft blocklist. A listed IP, or a bad Outlook score, often puts mail in junk. Or it uses a different 5.7.x code. Emails going to spam in Outlook but not Gmail covers that. The spam hub covers the case when many inboxes fail at once. 5.7.515 is a trust check. A blocklist lookup on this bounce burns an afternoon and does not change the notice.

Exchange admin. There is no mail rule with this number. A search for 5.7.515 there comes up empty because the rule sits on Outlook.com, on the receiving side.

Remote Connectivity Analyzer. Right tool for “Outlook will not open.” Wrong tool for this bounce.

If the bounce is a different code, treat that code. This page only maps 5.7.515.

Cost at scale

A health check on one domain answers today’s question. It cannot say that a new tool joined on Tuesday without the include. Or that a DKIM key died. Or that Outlook.com volume crossed 5,000 on one receipt send. 5.7.515 shows up as a Hotmail slice, then drops out of the chat until the next campaign.

That is why the watching is automatic. LitInboxes checks records, blocklists, and reputation on every watched domain every six hours. It keeps dated history, so a bounce spike can be matched to the day a record changed. It can alert by email, Slack, Discord, or a webhook. There is a walkthrough if that is worth seeing on a live domain.

Checklist

1. Copy the whole bounce. Confirm 550 5.7.515 and the From domain.
2. Run the email health check on that domain. Publish anything missing.
3. Send a test and read Authentication-Results. Want SPF pass, DKIM pass, and DMARC pass with a matching name.
4. If DNS looks fine and DMARC fails, fix the name match in the sending tool.
5. Wait for the old record’s timer. Then send a new email. The old bounce stays.
6. If the code comes back on one sending path, that path is still missing SPF or DKIM.