Outlook's 550 5.7.515: the rejection that means your mail is simply gone.

What is 550 5.7.515, and why is the message gone instead of in junk?

On 5 May 2025, Microsoft began rejecting bulk mail that does not meet its authentication requirements with a specific error: 550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level. The 550 marks it as a permanent failure, and that single digit changes everything about how you should respond. 550 is a 5xx permanent rejection — the message is refused outright, not deferred or retried, and never reaches the recipient. There is no junk-folder fallback at the enforcement stage.

This is a deliberate shift away from the older model, where failing mail was quietly accepted and dropped into the junk folder. Microsoft decided that silent junking confused both sender and recipient — neither could tell why a message had been filtered — so it replaced the ambiguity with a hard, legible answer. The result feels harsher, but it is more honest: instead of a message sitting unseen in a spam folder, you get an immediate, unmistakable signal that something in your authentication is wrong.

The scope is specific. Microsoft consumer mailboxes only: Outlook.com, Hotmail.com, Live.com, MSN — over 500 million active mailboxes. Not Microsoft 365 / Exchange Online tenant mail. Senders of more than 5,000 messages per day to Microsoft consumer mailboxes. The 5,000/day count is per sending domain. If your mail to Microsoft consumer addresses is failing and the bounce code is 5.7.515, this is the bulk-sender authentication gate rather than a content filter or a reputation block — which matters, because the fix is completely different from what you would do for a spam-score or reputation problem.

Why alignment, not presence, is usually the culprit

When a sender insists their records are correct and the mail is still rejected, the answer is almost always alignment. The 550 5.7.515 text does not say which of SPF, DKIM, DMARC, or alignment failed — only that the bar was not met. Diagnosis means checking each in turn. Alignment is the requirement that SPF or DKIM must not only pass but must authenticate under the same domain that appears in the From address the recipient sees, and it is easy to miss because the individual checks can all show green while alignment quietly fails.

The classic case is mail sent through an email service provider. Your campaign authenticates cleanly — SPF passes for the ESP's sending domain, DKIM is signed with the ESP's key — but the envelope and signing domains belong to the platform, not to you, so DMARC sees a mismatch with your From domain and records a fail. Microsoft then rejects it. The fix is to configure a custom return-path and a DKIM signing domain that match your own domain, which every reputable ESP supports, so that the passing mechanism aligns.

This is also where the earlier deliverability work pays off. The third major enforcement action in 18 months after Gmail and Yahoo (Feb 2024). Together these providers cover the majority of consumer inboxes, closing the last big gap where authentication could be treated as optional. A domain that already moved DMARC to a published policy, kept SPF under its lookup limit, and aligned DKIM for Gmail and Yahoo will sail through the Microsoft gate without a single change, because the requirements overlap almost entirely. The teams hit hardest by 5.7.515 are the ones that had treated Microsoft as the one provider they could still ignore.

Does 5.7.515 apply when I send through an ESP?

Yes, and the platform you send through does not exempt you — it is your From domain that Microsoft judges, not your provider's reputation. Sending through a large, well-regarded email service provider does not automatically clear the bar, because the gate is about whether authentication aligns with the domain in your From header, which is yours regardless of whose servers carry the message. A reputable ESP gives you the tools to align, but it does not align for you by default.

The practical implication is that you have to do the alignment configuration in your ESP's settings, not assume it is handled. That usually means verifying your domain, enabling DKIM signing with your own domain's selector rather than the platform's, and setting a custom return-path (sometimes called a custom MAIL FROM or bounce domain) so the envelope domain matches your From domain. Every major platform documents this; the step is easy to skip because mail appears to send fine right up until Microsoft rejects it.

It is also why a single organisation can see some of its mail rejected and some delivered. If your transactional mail goes through one correctly-aligned service and your marketing mail through another that was never configured for alignment, only the second stream collects 5.7.515 errors. Auditing each sending service separately — every platform that sends as your domain — is the only way to be sure you have covered them all.

Where we stand

We will say the reassuring thing first, because the coverage of this change has been alarmist: if you have done the authentication work that Gmail and Yahoo already required, the Microsoft gate is not a new project. The requirements overlap almost completely, and a correctly authenticated, aligned domain passes 5.7.515 without any Microsoft-specific configuration. Most of the panic around this error comes from senders discovering, all at once, that authentication they had postponed was overdue across every major provider — Microsoft was simply the last to enforce it.

The honest cautions are two. First, do not suppress the addresses this error rejects: they are good recipients behind a sender-side problem, and deleting them quietly erodes your list while you think you are cleaning it. Second, the 5,000-per-day threshold is a starting line, not a safe harbour — Microsoft has said full rejection of all non-compliant mail (beyond the 5,000/day threshold) will follow on a date to be announced — the 5,000/day line is the current trigger, not a permanent ceiling. If you send to Microsoft mailboxes at all, the right move is to get authentication and alignment correct now, at whatever volume, rather than to wait for the threshold to come down to you. We host sending infrastructure and set up SPF, DKIM, DMARC, and aligned return-paths as part of onboarding; if you send through an ESP, the same alignment work applies, and we are glad to tell you when your existing setup already clears the bar.