How to fix "550 5.7.515 Access denied" from Outlook.com

"550 5.7.515 Access denied" means Outlook.com rejected your message because your sending domain doesn't meet Microsoft's authentication rules for high-volume senders. Since 5 May 2025, Microsoft requires any domain sending 5,000 or more messages to its consumer mailboxes to pass SPF and DKIM, publish a DMARC record (p=none is enough), and align SPF or DKIM with the From domain. Mail that falls short went to Junk first. Now it can be rejected with this code. The fix is always in DNS or in how a sending service is set up.

The full bounce reads:

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

Microsoft's own explanation is at https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com. Below is how to find which check is failing and how to fix each one.

Who the rule applies to

Microsoft applies the rule to domains that send 5,000 or more messages to Microsoft consumer email services, which means addresses like @outlook.com, @hotmail.com and @live.com. The count is per From domain (the 5322.From, the address people see), across everything you send from it.

This matches what Gmail and Yahoo started requiring in February 2024, covered in our Gmail and Yahoo bulk sender requirements guide. If you already meet Google's rules, you probably meet Microsoft's, unless one sending service slipped through.

Microsoft's timeline, from its postmaster pages:

If your mail to Outlook.com started going to Junk before the bounces began, that's the same problem at an earlier stage.

What Microsoft requires

From Microsoft's support page, all mail from the domain must meet all three:

1. SPF passes. The sending server is authorized in the SPF record of the 5321.MailFrom (return-path) domain.
2. DKIM passes. The message carries a valid DKIM signature.
3. DMARC is published and passes. A TXT record at _dmarc.yourdomain with at least p=none, and SPF or DKIM aligned with the From domain.

Alignment is the part people miss. "Aligned" means the domain that passed SPF (the return-path) or the domain that signed with DKIM (d=) is the same as your From domain, or a subdomain of it under DMARC's default relaxed alignment.

In the third row, SPF and DKIM both pass, but for the service's domain, not yours. DMARC fails, and Microsoft rejects the message.

Step 1: Read the headers of a message to Outlook.com

Send a message from the affected system to an Outlook.com or Hotmail address you control. If it's rejected, the bounce tells you the domain. If it lands in Junk, open it and view the message source. Look for the Authentication-Results header:

Authentication-Results: spf=pass (sender IP is 203.0.113.10)
 smtp.mailfrom=bounce.esp.example; dkim=pass (signature was verified)
 header.d=esp.example; dmarc=fail action=none header.from=example.com;
 compauth=fail reason=000

Read it in this order:

• header.from: your From domain. Everything has to line up with this.
• smtp.mailfrom: the return-path domain that SPF checked.
• header.d: the domain that signed with DKIM.
• dmarc=: if it says fail or none, that's your problem.

In the example, neither bounce.esp.example nor esp.example is example.com, so DMARC fails.

Step 2: Check your DNS records

From any terminal:

# SPF: exactly one record starting with v=spf1
dig +short TXT example.com | grep spf1

# DMARC: one record at _dmarc
dig +short TXT _dmarc.example.com

# DKIM: the selector comes from the s= tag in the DKIM-Signature header
dig +short TXT selector1._domainkey.example.com

Common problems at this stage:

• No DMARC record. Add one. v=DMARC1; p=none; rua=mailto:dmarc@example.com meets Microsoft's requirement. Our DMARC setup guide explains the tags.
• Two SPF records. A domain may have only one. Two make SPF fail with a permanent error. Merge them.
• SPF over 10 lookups. Each include: costs lookups, and going over the limit fails SPF. See SPF too many DNS lookups.
• DKIM record missing or mangled. A key split wrongly across strings, or pasted twice, breaks DKIM. Our DKIM guide covers how to publish it cleanly.

Our free bulk sender checker runs these checks for a domain in one go.

Step 3: Fix each service that sends as your domain

Most 550 5.7.515 bounces come from one service, not from your main mailbox. List everything that sends with your domain in the From address: your email provider, newsletter tool, app or transactional provider, CRM, help desk, invoicing tool, website forms. For each one:

1. Turn on custom DKIM for your domain in that service. Most call it "domain authentication" or "verify domain", and give you CNAME or TXT records to publish. Once it's on, the service signs with d=yourdomain, which aligns.
2. Set a custom return-path if the service supports it, usually a subdomain like bounce.yourdomain pointing at the service. That makes SPF align too.
3. Add the service to SPF only if it sends with your domain as the return-path. If it uses its own return-path, adding it to your SPF does nothing for alignment.

DKIM alignment is the one that matters most, because it survives forwarding and doesn't depend on the return-path. If a service can't sign with your domain at all, move that mail to a subdomain with its own records, or to a service that can.

Step 4: Test again, then watch

Send a fresh message to Outlook.com and check that the header now says dmarc=pass. Then send through every system on your list, not just one, since a single unaligned tool is enough to trigger rejections for its mail.

Watch your DMARC aggregate reports for a couple of weeks. They show every IP sending as your domain and whether each one passes, which catches the forgotten tools. Once everything legitimate passes, move toward p=quarantine and p=reject. Our DMARC none to reject guide walks through the steps.

A quick checklist

Before you call it fixed, confirm each of these for the From domain:

• Exactly one SPF record, under 10 DNS lookups, listing every service that uses your domain as the return-path.
• DKIM turned on with your own domain in every service that sends as you, not just your main mailbox.
• A DMARC record at _dmarc, with an rua address so you get reports.
• A test message to Outlook.com showing dmarc=pass for each sending system.
• Hard bounces removed and unsubscribes honoured, so volume to Microsoft is wanted mail.

Microsoft's own sender tools

Microsoft runs two programs for senders. SNDS (Smart Network Data Services) shows how Outlook.com sees the IP addresses you control: volume, complaint rates and spam-trap hits. The Junk Mail Reporting Program (JMRP) sends you a copy when an Outlook.com user marks your mail as junk. Both are free and need you to prove control of the IP or domain. They matter most if you run your own server on your own IP. On a shared provider, ask the provider instead.

If authentication passes and Outlook still rejects you

5.7.515 is specifically about authentication. If dmarc=pass and you still get bounces, read the code again. Other 5.7.x codes from Microsoft mean different things, such as a blocked IP or a reputation problem. Those are fixed through Microsoft's sender support and by improving what you send, not through DNS.

At high volume, the same advice applies to Microsoft as to Gmail and Yahoo. Send only to people who asked for your mail, remove hard bounces straight away, offer one-click unsubscribe in marketing mail, and keep complaints low. Our guide to why emails go to spam covers the reputation side.

When to get help

If you have several tools sending as your domain and can't tell which one is failing, the Deliverability Fix is a one-time audit. We find every sender, fix SPF, DKIM, DMARC and reverse DNS, and test real messages to Outlook, Gmail and Yahoo. If you send from our platform, DKIM and the return-path use your domain from the start, so mail aligns once you've published the records we give you. See pricing.