What does 550 5.7.515 mean?

It is Outlook.com's rejection for a sending domain that does not meet the authentication level required of high-volume senders. The bounce text says the sending domain does not meet the required authentication level. In practice, SPF, DKIM or DMARC, or the alignment between them and your From domain, is wrong.

Does 550 5.7.515 affect me if I only send a few hundred emails a day?

Microsoft's page defines the rule for senders of 5,000 or more messages to its consumer services, all using the same domain in the 5322.From address. A small fleet spread over many domains usually sits below that per domain. But a bounce with this code still tells you one domain's authentication is broken, and fixing it is free.

Is a 5.7.515 bounce the same as landing in spam?

No. A bounce is a hard rejection: the message never reaches the mailbox, junk folder included. Spam placement is a quieter failure that you only see by testing real inboxes. Both can share a root cause, which is why I fix authentication before anything else.

Do I need a strict DMARC policy to stop the bounce?

No. Microsoft's example DMARC record is v=DMARC1; p=none, and the page lists p=none, p=quarantine and p=reject as acceptable. What it requires is a DMARC record plus a message that passes DMARC, meaning SPF or DKIM passes and aligns with the From domain.

550 5.7.515 bounce in cold email: what it means and the fix

A 550 5.7.515 bounce means Outlook.com rejected your email because the sending domain did not meet the authentication level Microsoft requires. The cause is almost always SPF, DKIM or DMARC missing, failing, or not aligned with your From domain.

Here is what Microsoft says it means, which mailboxes it applies to, and the order I would fix things in.

What does 550 5.7.515 actually say?

The bounce text, per Microsoft's support page, reads: "Access denied, sending domain [domain] does not meet the required authentication level." The domain it names is the one in the 5322.From address, the From header your recipient sees.

Microsoft's page says the rule applies to senders of 5,000 or more messages to Microsoft consumer email services, all using the same domain in the 5322.From address. Once you are in that group, mail from that domain should:

have SPF and DKIM published, and both must pass
have a DMARC record at the _dmarc hostname (the example is v=DMARC1; p=none)
pass DMARC, meaning at least one of SPF or DKIM aligns with the From domain

That page gives no enforcement date, so I will not give one either.

Which mailboxes does it hit?

Microsoft's page describes consumer services such as Outlook.com. Most B2B cold email goes to company domains on Microsoft 365, which has its own filtering, so I would not assume a 5.7.515 describes your whole Microsoft-hosted list. What it does tell you is that one of your domains has a real authentication problem. For the wider Microsoft against Google picture, see Google Workspace vs Outlook for cold email.

What is the fix order?

Work down this list and re-test after each step.

Find the domain in the bounce. It is the From domain, not necessarily the one your tool shows in its dashboard.
Read the headers of a delivered message. Send one to an Outlook.com address you control and look at the SPF, DKIM and DMARC results. Microsoft's page recommends exactly this.
Check SPF exists and passes. One SPF record per domain, including your mailbox provider and any tool that sends on your behalf.
Check DKIM signs with your domain. The d= domain in the signature should be your sending domain, not the tool's.
Publish a DMARC record if there is none. p=none meets the requirement.
Check alignment, covered properly in the DMARC alignment checklist.
Resend a small test, and resume the campaign only when the headers show DMARC pass.

Microsoft gives third-party senders their own line: confirm the service uses your domain in the 5321.MailFrom, signs DKIM for your domain, and that your SPF record includes the service.

What does a misaligned domain look like in the headers?

When you read the headers of a test message, match what you see to the likely cause:

What the headers show	Likely cause	Fix
SPF pass, but for the tool's domain; DKIM pass, but `d=` is the tool's domain	Both pass, neither aligns	Publish the tool's DKIM key under your domain, or set a custom return-path
SPF fail, DKIM none	DKIM not set up for this domain	Add DKIM, then re-test
DMARC none	No record at `_dmarc`	Publish `v=DMARC1; p=none`
SPF permerror	Two SPF records, or too many lookups	Merge into one record
Everything passes and aligns	Not an authentication problem	Look at reputation and volume instead

This is the same pattern behind most "everything is green but it still fails" complaints: the dashboard reports that a check passed, and says nothing about which domain it passed for.

Why did it start on a domain that used to work?

Rules change, and reputation moves. A domain that was fine at 50 sends a day can start to hit a threshold when you add inboxes behind the same From domain. If all your inboxes send as the same domain, Microsoft's rule counts them together. That is one more argument for the three-inboxes-per-domain spread rather than stacking mailboxes on one domain.

Do not use bounce codes as a to-do list on their own. Pause the affected domain, fix it, send a small test, and only then bring it back into rotation.

Where this advice stops working

A bounce code only covers mail that was rejected. If your emails are accepted and quietly junked, the answer is not in the bounce log. That is the diagnostic order in why your cold email lands in spam, and the DNS checks sit in the deliverability audit.

It also helps to set every domain up identically. How many inboxes you need covers spreading load across domains, and one badly configured domain in the group is the usual source of a stray 5.7.515.

More field notes like this are on my blog.