Outlook 550 5.7.515: what it means and how to fix it

550 5.7.515 is Outlook.com telling you it refused a message because the domain in the From address does not meet the authentication level it requires. In practice one of four things is wrong: SPF fails, DKIM fails, there is no DMARC record, or neither SPF nor DKIM aligns with the From domain. Fix the one that your message headers show, then send a new message, because the failure is permanent for the message that was rejected.

The exact text, as Microsoft documents it, is:

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

What the code says

An SMTP enhanced status code has three parts, class, subject and detail (RFC 3463). Here the class is 5, a permanent failure, which RFC 3463 describes as one “not likely to be resolved by resending the message in the current form”. The subject is 7, security or policy status. RFC 5321 adds that after a 5yz reply the client must not repeat the same command. So the rule is simple: retries will not help, and a mail system that keeps retrying is wasting volume.

Two consequences follow for list handling, and they are our recommendations rather than Microsoft’s:

• This is a rejection of your domain, not of the recipient. The mailbox may be fine. Do not treat it like a “user unknown” bounce, and do not remove the recipient from your list because of it.
• It will repeat across Outlook.com addresses. If one message is rejected for authentication, the next hundred to the same provider will be too. Pause sending to that provider until you have fixed the cause.

When Microsoft applies it

Microsoft announced the requirement on April 2, 2025 for domains that send more than 5,000 emails per day. The announcement was updated on April 29, 2025 to say that non-compliant messages would be rejected, not routed to the Junk folder, with the change taking effect on May 5, 2025. The page still contains the earlier text about Junk, struck through. This is easy to misread, so read the page itself rather than a summary of it.

The support page that documents the error describes the trigger like this: you send 5,000 or more messages to Microsoft consumer email services, such as Outlook.com, Hotmail, Live.com and MSN, and all those messages use the same domain in the 5322.From address. Two details to note:

• The count is by From domain. If you send from ten mailboxes under one domain, they are added together.
• It concerns consumer services. The pages we read describe Outlook.com and related consumer services. They do not describe the same enforcement for Microsoft 365 business tenants, and we did not find a statement either way, so do not assume.

If you send fewer than 5,000 a day, Microsoft’s FAQ says the same practices still protect your reputation, and the cost of meeting them is small.

What must pass

Microsoft’s two pages give the same three requirements:

Alignment is the part that most often trips cold senders. SPF authenticates the domain in the envelope sender, also called 5321.MailFrom or Return-Path. DKIM authenticates the domain in the signature’s d= tag. DMARC asks whether at least one of those domains matches the domain in the visible From address (5322.From). Passing SPF for a domain that is not yours does not satisfy DMARC.

Diagnose it in four steps

1. Read the bounce. It names the domain Outlook evaluated, which is the From domain. Confirm it is the domain you intended and not, for example, a service’s shared domain.

2. Get the authentication headers of a real message. Send a test message from the same mailbox and path to an Outlook.com address you control, open the message headers, and find the Authentication-Results line. Microsoft’s own steps start by checking that the Return-Path domain aligns with the From domain.

3. Read the three results. Here is an illustrative header, with example domains:

   Authentication-Results: spf=pass smtp.mailfrom=bounce.sendservice.example;
     dkim=pass header.d=sendservice.example;
     dmarc=fail header.from=example.com
   

   SPF and DKIM pass, but for sendservice.example, not for example.com. DMARC fails because nothing aligns with the From domain. This is the classic result of sending through a service without setting up your own domain with it.

4. Check the DNS records yourself with a lookup tool of your choice:

   dig +short TXT example.com
   dig +short TXT _dmarc.example.com
   dig +short TXT s1._domainkey.example.com
   

The usual causes and their fixes

On the SPF line: RFC 7208 says an implementation must limit the number of DNS-lookup terms to 10, and a record over the limit produces a permanent error. Microsoft’s FAQ makes the same point.

An example of the records for a sending domain you control. The values are placeholders:

example.com.                  IN TXT  "v=spf1 include:_spf.sendservice.example -all"
s1._domainkey.example.com.    IN CNAME s1.dkim.sendservice.example.
_dmarc.example.com.           IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
bounce.example.com.           IN CNAME return.sendservice.example.

The last line is a custom Return-Path for services that offer one, which makes SPF align with the From domain. Exact record names come from your provider.

Test after the change

1. Wait for the DNS records to propagate, then send a new test message to an Outlook.com address.
2. Confirm spf=pass, dkim=pass and dmarc=pass in the headers, with the domain after header.from= equal to your From domain.
3. Resume at a low volume to Outlook.com addresses and watch for the code again before returning to your usual pace.

Microsoft does not publish how long it takes for a corrected domain to be accepted, so we do not give a number.

Monitor the reputation side

Authentication gets you past this check. It does not decide whether mail lands in the inbox. Microsoft lists two free services for senders: SNDS, which describes how users are rating the mail they receive from your IPs, and JMRP, which reports mail that Outlook.com users mark as junk. Both are tied to sending IP addresses, so they help most when you control the IPs. The deliverability audit checklist shows where they fit, and Gmail and Yahoo bulk sender requirements covers the other two major providers.

How Dooxout handles this

Dooxout’s preflight checks DNS for SPF, DKIM and DMARC and the sending identity before a campaign starts, and the first message can also be tested through DeliverProbe, which analyzes headers, authentication, content and blocklists. If authentication is broken, you see it before you send, not in a bounce.

Preflight is a check, not a guarantee, and a result of this kind is shown to you with the reasons, so you decide what to do. The platform does not promise inbox placement at Outlook or anywhere else. Bounce and complaint thresholds pause sending automatically, and you set them. Addresses that unsubscribe or complain are suppressed, and that rule cannot be turned off. More on the product side: email deliverability and cold email infrastructure.