550 5.7.515 from Microsoft — Access denied, authentication level

Microsoft's 550 5.7.515 Access denied is the bounce you get when the domain in your visible From address does not meet Microsoft's authentication requirements for its consumer mail services — Outlook.com, Hotmail, Live and MSN. The full text reads that the sending domain "doesn't meet the required authentication level" and that "the sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender." It is the Microsoft member of the same family as Gmail's 5.7.26 and Yahoo's 5.7.9 — but it is the strictest of the three, and it is the only one that hands you a precise breakdown of what failed.

What the error says

A typical bounce looks like this, and the detail at the end is the part worth reading carefully:

550 5.7.515 Access denied, sending domain EXAMPLE.COM doesn't meet
the required authentication level. The sender's domain in the
5322.From address doesn't meet the authentication requirements
defined for the sender.
Spf= Pass , Dkim= Fail , DMARC= Pass

The 5322.From is the address your recipient sees — the From header, in RFC terms the P2 sender — as distinct from the envelope sender used for bounces and SPF. Microsoft judges the requirement against that visible domain. The bounce also carries a go.microsoft.com/fwlink link to Microsoft's own support article on the error, which restates these requirements but rarely tells you which check failed on your specific message. And unlike Gmail and Yahoo, Microsoft prints the per-mechanism result right in the NDR: the Spf= / Dkim= / DMARC= line tells you exactly which check passed and which did not, so you are never guessing.

The key difference: both SPF and DKIM must pass

This is what catches people who already fixed Gmail and Yahoo. For senders past its volume threshold, Microsoft's published requirement is that both SPF and DKIM checks must pass, the domain must publish DMARC, and at least one of SPF or DKIM must align with the 5322.From. That "both must pass" bar is stricter than DMARC alone, which is satisfied by a single aligned mechanism. It is why a bounce can read Dkim= Fail, DMARC= Pass and still be rejected: DMARC passed because SPF aligned, but Microsoft refused the mail because DKIM did not pass. Gmail would have accepted that message; Microsoft does not.

Use the decoder to turn your NDR's breakdown into the exact cause and fix. Set each check to what your bounce shows, and it tells you why Microsoft rejected the message. It runs entirely in your browser.

When Microsoft enforces it, and who it hits

Microsoft turned this on for its consumer services on 5 May 2025, and notably it did not copy Gmail's gentle ramp. Where Gmail spent months returning temporary deferrals before switching to hard rejections, Microsoft went straight to bouncing non-compliant mail with 5.7.515. So there was no grace period in which slightly-misconfigured mail merely slowed down — it began failing outright on day one of enforcement. The rule is framed around high-volume senders to Outlook.com, Hotmail, Live and MSN, with the same rough 5,000-messages-a-day shape as the Gmail and Yahoo thresholds, but the wording matters: once a domain crosses that bar, Microsoft expects every message from the domain to meet the requirements, not merely the bulk runs.

In practice the error also reaches senders who do not think of themselves as bulk. A domain that occasionally sends a large run, a shared platform where many tenants share a reputation, or simply a domain whose authentication is broken can all surface 5.7.515. Arguing about whether you are "really" a high-volume sender is the wrong response; the productive one is to meet the bar regardless, because doing so is the same work that fixes deliverability everywhere else. There is no path to clearing the error that does not involve publishing and aligning SPF, DKIM and DMARC for the sending domain.

Why you get it even with DMARC= Pass

The most common 5.7.515 in the real world shows SPF passing, DMARC passing, and DKIM failing — and the sender, reasonably, assumes a passing DMARC means they are done. Under Gmail's and Yahoo's rules they largely would be. Microsoft treats DKIM as non-optional for high-volume senders, so a failing DKIM is fatal regardless of the DMARC verdict. The practical consequence: if your NDR shows Dkim= Fail, that is the line to fix, even though every DMARC checker tells you the domain is fine. Do not be reassured by the DMARC pass; Microsoft is asking a stricter question.

A worked example: Dkim= Fail, DMARC= Pass

A team sends transactional mail from [email protected] through PowerMTA. Their SPF record lists the sending IPs correctly, so SPF passes and aligns with example.com. They set up DKIM months ago, but the selector they rotated to never had its public key published in DNS — the MTA signs, but verification fails. Every DMARC checker reports the domain as passing, because DMARC is satisfied by the aligned SPF alone. Mail flows fine to Gmail and Yahoo. Then orders to Outlook.com and Hotmail customers start bouncing: 550 5.7.515 ... Spf= Pass , Dkim= Fail , DMARC= Pass.

The breakdown is the whole story. SPF passed, DMARC passed on SPF alignment, but DKIM failed because the published key for the active selector is missing — and Microsoft requires DKIM to pass. The fix is narrow and specific: publish the public key at the selector PowerMTA is actually signing with, confirm it matches, and re-test. Nothing about SPF or DMARC needed touching; the green DMARC was a distraction. Within the TTL of the new DNS record, Outlook.com begins accepting the mail. The lesson is to trust the NDR's per-check line over a DMARC checker — Microsoft told them precisely what was wrong, while every DMARC tool insisted everything was fine.

Fixing DKIM= Fail

DKIM is the check that fails most often in 5.7.515 bounces, and on a self-hosted setup the causes are specific. The public key may never have been published at the selector your MTA signs with; the selector in DNS may not match the one PowerMTA or KumoMTA is using; the signing d= domain may be wrong; or the message body may have been altered after signing, so the body hash no longer matches and verification fails. Confirm that the selector and key published in DNS are exactly what your MTA signs with, and that nothing downstream rewrites the message after it is signed. A body-hash mismatch is a distinct failure mode with its own causes, covered in the DKIM body-hash fix. Once DKIM verifies and aligns, this variant clears.

Fixing SPF= Fail

When the breakdown shows Spf= Fail, the sending IP is not authorised in the From domain's SPF record. On a self-hosted MTA the usual reason is an SPF record that names an old host, a control-panel server, or a previous provider rather than the actual PowerMTA or KumoMTA egress IPs — or a record that has grown past the lookup limit and returns a PermError, which counts as a failure. Publish an SPF record that names every IP your MTA sends from, and keep it within the lookup limit; the SPF PermError fix covers the lookup trap. Because Microsoft wants both mechanisms passing, a passing DKIM does not excuse a failing SPF here — fix the SPF even if DKIM is green.

Fixing alignment (DMARC= Fail)

If both SPF and DKIM pass but the breakdown shows DMARC= Fail, the problem is alignment: neither passing mechanism matches the 5322.From domain. A DKIM signature on a different d= domain, or an SPF pass on an envelope domain that differs from the visible From, authenticates something other than the From identity DMARC measures. Set your DKIM d= to the From domain and make the envelope domain match it, so at least one aligns. This is the same alignment fix behind Gmail's and Yahoo's codes, detailed in the p=reject troubleshooting guide — the difference is only that Microsoft also insists both mechanisms pass on top of alignment.

Fixing it on a self-hosted PowerMTA or KumoMTA

On your own MTA the checklist is short and entirely yours. Publish an SPF record naming your sending IPs so SPF passes. Sign with DKIM whose d= matches your From domain and publish the public key so DKIM passes and aligns — PowerMTA does this through its domain-key directive, KumoMTA in its Lua policy. Publish a DMARC record for the From domain. The point Microsoft enforces that the others do not is that you cannot lean on a single mechanism: both SPF and DKIM have to pass, so a setup that signs DKIM but never fixed SPF, or vice versa, will clear Gmail and bounce at Microsoft.

PowerMTA operators have a small advantage in diagnosis: PowerMTA tags these rejections in its accounting with a category of policy-related, so a cluster of policy-related bounces to Microsoft destinations points straight at 5.7.515 in the logs. Wire feedback loops into suppression through the bounce and FBL handling setup, and use the authentication guide for the record and signing details. Because no ESP is doing this for you, getting both SPF and DKIM passing and aligned is the whole job.

Verify before resending

5.7.515 is permanent, so resending the same message bounces it again and adds a negative signal. Fix the check the NDR names, then send a single seed to an Outlook.com or Hotmail address you can inspect and read both the Microsoft breakdown on any bounce and the Authentication-Results header on a delivered message — confirm SPF and DKIM both pass and that DMARC aligns with the 5322.From. Microsoft's Smart Network Data Services and the Outlook.com postmaster pages show your domain and IP reputation over time, worth checking after a fix. Let DNS changes propagate within their TTL, confirm a real message passes, then resume volume gradually. The SMTP code lookup helps confirm you are reading the response correctly.

The way to keep 5.7.515 from recurring is to treat both SPF and DKIM as load you carry permanently, not a one-time fix. A signing selector you rotate without publishing the new key, a sending IP added to a pool but never added to SPF, or a new From subdomain that was never set up to sign — each reintroduces the error the moment it ships, and each is invisible until a Microsoft recipient bounces. Make a two-line check part of bringing any new domain, subdomain or IP online: does SPF list this IP, and is DKIM signing with a published key on the From domain? Confirming that before the first send to an Outlook.com address is far cheaper than tracing a bounce across a live campaign, and it is the same discipline that keeps the Gmail and Yahoo codes away too.

The strictest of the three rejection codes

The three big providers reject unauthenticated mail with their own codes, and seeing them side by side explains why mail can pass two and fail the third.

Provider	Code	What it requires	NDR detail
Gmail	550 5.7.26	At least one of SPF or DKIM, aligned	Names the protocol or DMARC policy
Yahoo	554 / 550 5.7.9	DMARC pass under the From domain's policy	"Policy reasons" — no per-check breakdown
Microsoft	550 5.7.515	Both SPF and DKIM pass, plus one aligned	Prints Spf= / Dkim= / DMARC= result

Gmail's 5.7.26 wants at least one of SPF or DKIM, aligned. Yahoo's 5.7.9 centres on the DMARC policy of the From domain. Microsoft's 5.7.515 wants both SPF and DKIM to pass and at least one aligned — the highest bar — and uniquely reports the per-check result so you can act on it directly. The implication for a self-hosted sender is to build to Microsoft's bar from the start: if both SPF and DKIM pass and align to your own From domain, you clear all three at once. The bulk sender requirements lay out the shared rule set the codes enforce.

The bottom line

Microsoft's 550 5.7.515 means your visible From domain did not meet its authentication level, and the NDR's Spf= / Dkim= / DMARC= line tells you exactly which check to fix. The trap that catches careful senders is that Microsoft requires both SPF and DKIM to pass, so mail with a perfectly healthy DMARC still bounces when DKIM fails. Read the breakdown, fix the named check, make sure both mechanisms pass and at least one aligns with the 5322.From, and verify on a seed before resending. On a self-hosted PowerMTA or KumoMTA those records and signatures are yours to set — build to Microsoft's stricter bar and Gmail and Yahoo come along for free. And because the NDR names the failing check outright, 5.7.515 is, paradoxically, the easiest of the three to act on once you know to read that line: it removes the guesswork the other two providers leave you to do on your own.