Outlook Rejects Mail Now: What 550 5.7.515 Means and How to Fix It

In the Gmail and Yahoo piece, Microsoft got a single paragraph. It earned more than that, because Outlook fails differently from the others. Gmail's failure mode is throttling – a slow bleed you can almost miss. Outlook's is a bounce that says "Access denied," and a chunk of your list simply never gets the email.

If you send to Outlook.com, Hotmail or Live addresses in volume, this is the one to understand. Here's what the rule is, what the error actually means, why it can hit you even when your authentication "passes," and a triage order that gets you to a fix quickly.

Here's the question worth sitting with: do you know what share of your last send bounced at Outlook – and what the bounce code said?

The rule, in plain terms

Microsoft's requirements apply to domains sending 5,000 or more messages a day to Outlook.com consumer mailboxes, judged on the domain in the visible From address (the 5322.From). Direct rejections with error 550 5.7.515 began on May 5, 2025, after Microsoft updated the action it takes on non-compliant messages in late April of that year.

As described in the sources I read, the requirements are:

• SPF and DKIM must both pass.
• DMARC must pass through an aligned SPF or DKIM domain – one of the two is enough. A p=none policy is accepted as the baseline; p=reject gives stronger protection once your monitoring is clean.
• It applies to all mail using that From domain, not just your marketing stream.
• Sending practices count too: a valid From or Reply-To address, a working unsubscribe, list hygiene, accurate subject lines and headers, and ARC for forwarders and mailing lists.

If you read the Gmail piece, none of this is new in kind. It's the same authentication trio. What's different is the failure: a hard rejection, with a code you can search for.

What the bounce looks like

The one you're hunting for reads like this:

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

That's the marker for the high-volume requirement. There's a lookalike worth knowing about, because the two get confused:

Deliverability practitioners have pointed out that early DMARC-reject bounces were easily mistaken for the new requirement. Read the code before you touch DNS.

Why it fails when everything "passes"

This is the part that sends people in circles. SPF can pass. DKIM can pass. Your ESP's dashboard can show green. And you can still get a 5.7.515, because those checks may be passing for the vendor's domain while DMARC – which requires alignment with your visible From domain – fails.

Put simply: DMARC doesn't ask "did a signature validate?" It asks "did a signature validate for the domain the reader sees?" If your ESP signs with its own domain by default and you never set up custom DKIM for your own, the answer is no, no matter how many things say "pass."

The triage order I'd use

Not a 40-point audit. Work top to bottom and stop when you find it.

1. Pull your bounce logs for Outlook.com, Hotmail and Live recipients and filter for 5.7.515 and 5.7.509. Paste a sample into the Bounce Message Decoder to confirm which one you're dealing with.
2. Identify the visible From domain on the mail that bounced. That's the domain being judged – everything else is checked against it.
3. Confirm a DMARC record exists for that domain. p=none with a reporting address satisfies the baseline; plan the move to quarantine and then reject once every legitimate source authenticates cleanly.
4. Confirm SPF or DKIM aligns with the From domain. In most ESPs that means turning on custom DKIM signing and a custom return-path domain on your own domain.
5. Check SPF includes every system that sends as your domain, and that you're inside the 10 DNS lookup limit.
6. Send through the production stream and compare the headers of an accepted message with a bounced one.
7. Run the domain through the Compliance Quick-Check to catch anything you missed in the DNS records.
8. Then check the other half of the rule: a valid Reply-To, a working unsubscribe and honest list hygiene.

One honest caveat: this is a rule Microsoft has adjusted before, and several of the finer details I've described come from vendor write-ups rather than Microsoft's own documentation. Before you make DNS changes, confirm the current requirements against Microsoft's sender guidance – and if you've got the wrong fix in mind, the bounce code will usually tell you before your subscribers do.

If your Gmail and Yahoo setup was already right, this should be a short job: alignment, check, resend. If it wasn't, Outlook is the provider that will tell you the loudest. Fix it once, properly, and it stays fixed.

Stephen Taunt