# 550 5.7.515 “Access denied”: why Outlook rejects your domain and how to clear it

Published: 2026-11-04  
Author: Guanacos Tech (https://guanacostech.com)  
Canonical: https://guanacostech.com/blog/550-5-7-515-access-denied-outlook-fix

> Read the bounce, find which of SPF, DKIM, DMARC or alignment failed on your sending domain, fix them in the right order, and get mail into Outlook again.

**Short answer:** 550 5.7.515 means Outlook.com refused the message because the domain in the From header does not meet Microsoft's authentication requirements for high-volume senders. SPF and DKIM must both pass, a DMARC record must be published with a valid policy, and SPF or DKIM must align with that From domain. Check alignment before touching DNS.

The pattern is always the same. Invoice reminders or order confirmations go out as usual, most of them arrive, and a handful of customers say they never got anything. Those customers all read their mail at `hotmail.com`, `outlook.com` or `live.com`, and the mail log carries one line for each of them:

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

That bounce is not a spam complaint, not a blocklist and not a reputation score. It is a door check. Microsoft looked at the domain in the From header, asked whether that domain authenticates its own mail the way Microsoft requires of high-volume senders, and got an answer it would not accept. Until the answer changes, mail from that domain to a Microsoft consumer address is refused at the edge. Nothing lands in Junk, so nobody on your side sees a pattern until a customer picks up the phone.

This is one of the kinder deliverability failures, because Microsoft says exactly what it wants. The work is finding which of four checks is the one failing, and in our experience most teams guess wrong on the first try.

## What the bounce means, line by line

Three parts of that string matter.

**550** is a permanent rejection. The sending server will not retry, the message is gone, and your customer never saw it. **5.7.515** is the enhanced status code Microsoft uses for a policy refusal based on sender authentication, not on content. And the domain printed in brackets is the one in the `5322.From` header, the sender a human reads in the From line, not the envelope sender your mail server used to hand the message over.

That last detail is where most of the confusion lives. Microsoft's own fix guide for this error asks you to compare the `5321.MailFrom` domain, the return path that SPF is checked against, with the `5322.From` domain that DMARC cares about. Plenty of mail passes SPF cleanly on a return path that has nothing to do with the visible From domain, and that mail still earns a 5.7.515. A green SPF check in a DNS tool proves nothing on its own here.

## Who Microsoft counts as a high-volume sender

The rules apply to mail into Microsoft's consumer services: `outlook.com`, `hotmail.com` and `live.com`. Microsoft's fix guide sets the bar at 5,000 or more messages sent to those services using the same domain in the `5322.From` address. The Outlook.com postmaster policy page puts it as domains sending more than 5,000 emails a day to Outlook.com accounts, in force since 5 May 2025, and the announcement from the Defender for Office 365 team describes the refusal arriving as this exact 5.7.515 string. Both pages checked 4 November 2026.

Two things catch small businesses out.

First, 5,000 is a domain total, not a campaign total. Say a 12-person accounting firm sends 400 statements a month from its mail client: nowhere near the line. The same firm with a billing system, a CRM sequence and a monthly newsletter all sending as `@example.com` can cross it in a week without anyone deciding to become a bulk sender. Nobody signs up for this threshold, they drift into it.

Second, a recipient adding you to their Safe Senders list does not get you past it. The refusal happens before any per-recipient preference is read, so asking customers to allowlist your address is a week spent on nothing. The only fix is on your side of the DNS.

## The four checks, in the order we run them

Microsoft wants four things true at the same time: SPF passes, DKIM passes, a DMARC record exists with a valid policy, and at least one of SPF or DKIM aligns with the From domain. Usually three of the four are already fine. We work the list in this order because each answer tells you whether the next line is worth looking at.

| Check | Where you read it | What a failure looks like | What to change |
| --- | --- | --- | --- |
| **SPF** | `Authentication-Results` in a delivered copy of the same message | `spf=fail`, or `spf=pass` for a domain that is not yours | Add the sending service to the SPF record of the return-path domain |
| **DKIM** | The `DKIM-Signature` header and its `d=` value | No signature at all, `dkim=fail`, or `d=` set to a provider domain | Publish the provider's DKIM key for your domain and turn signing on |
| **DMARC record** | A TXT record at `_dmarc.example.com` | No record, more than one record, or a missing `p=` value | Publish one record with `v=DMARC1` and a policy, reports on |
| **Alignment** | `dmarc=` in the same header block | `spf=pass` and `dkim=pass` but `dmarc=fail` | Make the return path or the DKIM `d=` domain match the From domain |
| **Re-test** | A fresh message to a Microsoft consumer address | The same 550 5.7.515 after DNS has had time to propagate | Read the headers of the new bounce before changing anything else |

Read a real message before you touch DNS. The `Authentication-Results` header written by the receiving side names each verdict and the domain it was applied to, and that is the quickest way to tell a missing record from a misaligned one. Guessing from a DNS lookup tool is how a one-afternoon fix turns into two weeks.

Free tool

Decode the headers of a message that went to spam

Paste the raw headers and see the Received chain plus the SPF, DKIM and DMARC results, line by line.

[Analyze headers](https://guanacostech.com/header-analyzer)

## The three failures we find most often

### Microsoft 365 signing with the wrong domain

A tenant that has never had DKIM enabled for its custom domain still signs outbound mail, but it signs with the tenant's `onmicrosoft.com` domain. DKIM passes. DMARC still fails, because Microsoft's own documentation is explicit that DKIM only satisfies DMARC when the signing domain and the From domain align. The fix is to enable DKIM signing for the exact domain used in the From address, including any subdomain that sends.

That means two CNAME records per domain, `selector1._domainkey` and `selector2._domainkey`, with the targets copied exactly from your own tenant rather than typed from a template. Microsoft's troubleshooting guidance calls out hand-built targets as a common cause of validation failure, asks for both records even though only one selector is live at a time, because the second one is what makes key rotation invisible, and says a TXT record in place of a CNAME is not supported.

### A sending service that owns the envelope

A billing platform or marketing tool sends on your behalf, and by default it uses its own bounce domain as the return path and its own key to sign. Both checks pass, and both of them pass for the provider, not for you. To DMARC that reads as a message that nobody who owns `example.com` vouched for. Every service worth using has a way out of this: a custom return path on your own subdomain, a DKIM key published under your domain, or both. Turn one of them on for every system that sends as you, not just the big one.

### An SPF record that does not list the sender

Microsoft's SPF guidance is worth reading before editing: one SPF record per domain and no more, most Microsoft 365 organisations need `include:spf.protection.outlook.com`, every `include`, `a`, `mx`, `ptr` and `redirect` counts against the DNS lookup limit, and exceeding it makes SPF validation fail outright. Microsoft recommends hard fail, `-all`, and a TTL of at least 3600 seconds. A subdomain does not inherit the parent's record, so a billing subdomain that sends needs its own.

## The records, written out

```
; SPF: one record only, on the domain used as the return path
example.com.           3600 IN TXT   "v=spf1 include:spf.protection.outlook.com -all"

; DMARC: the minimum Microsoft asks for, with reports switched on
_dmarc.example.com.    3600 IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

; DKIM for a Microsoft 365 custom domain: two CNAMEs, targets copied
; from your own tenant, never assembled by hand
selector1._domainkey.example.com.  3600 IN CNAME  TARGET-FROM-YOUR-TENANT
selector2._domainkey.example.com.  3600 IN CNAME  TARGET-FROM-YOUR-TENANT
```

Those are starting points, not a recipe to paste. The SPF record belongs on whichever domain your mail server hands over as the return path, which is not always the one in the From line, and the DKIM targets are specific to your tenant.

## After the fix: what we watch for two weeks

Set the DMARC policy to `p=none` with reports first and leave it there. The bounce clears as soon as SPF or DKIM aligns, so there is no reason to jump to `p=reject` the same afternoon and discover on Monday that the billing system was the one sender you forgot.

Then read the reports. Aggregate reports arrive as daily XML from each receiver and they are the only view you get of every system sending as your domain, including the ones nobody told you about. Two weeks of them is usually enough to see the full list. Once every legitimate sender shows up aligned, tighten the policy in steps. Re-send to a Microsoft consumer address at each step, because that is the test that actually matters.

One honest note on timing: DNS changes take as long as your TTL says they will, and a receiver that cached an old record will keep rejecting until it expires. A clean fix can still bounce for an hour. Do not undo good DNS because the first retry failed.

## How Guanacos Tech helps

We take this as a defined piece of work: read a real bounce, read the headers, map every system that sends as your domain, fix SPF, DKIM and alignment in the order above, then watch DMARC reports for two weeks to confirm nothing else is signing as you. Most of the time it is one afternoon of DNS and one setting inside a sending tool, and the hard part is only knowing which setting. If you would rather not guess at it, that is what our [email deliverability consulting for small business](https://guanacostech.com/email-deliverability) is for. Book a 30-minute call and bring one bounced message, and we will tell you on the call which of the four checks is failing and what clearing it involves.

## Sources

- [Microsoft Support: Fix NDR error “550 5.7.515” in Outlook.com](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com)
- [Microsoft Tech Community: Strengthening Email Ecosystem, Outlook’s new requirements for high-volume senders](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)
- [Outlook.com Postmaster: Policies, Practices and Guidelines](https://sendersupport.olc.protection.outlook.com/pm/policies)
- [Microsoft Learn: How to use DKIM for email in your custom domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)
- [Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)
- [Microsoft Learn: Troubleshoot email authentication in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-troubleshoot)
- [RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc7489)

## Frequently asked questions

### Can I fix 550 5.7.515 myself, or does Microsoft have to unblock me?

You fix it yourself. There is nothing to appeal and no delisting form, because the rejection is a live check on your domain's authentication rather than a block on a list. Once SPF or DKIM passes and aligns with the From domain, and a DMARC record is published, the next message goes through.

### We send far fewer than 5,000 emails a day. Why are we getting this bounce?

Count every system that sends as your domain, not just your mail client: billing software, a CRM sequence, a help desk, a newsletter and an online store all add to the same domain total. It is also worth fixing regardless of volume, since SPF, DKIM, DMARC and alignment are what every major receiver now expects.

### Do I need p=reject to satisfy Microsoft?

No. Microsoft's own fix guide accepts a published DMARC record with a valid policy, and its example uses p=none. Start there with reports switched on, confirm every legitimate sender shows up aligned, then tighten the policy in steps if you want the spoofing protection p=reject gives you.

---

Guanacos Tech is an independent consultancy with Google-certified engineers: email deliverability, Google Workspace and Google Cloud, in English and Spanish. Book a free 30-minute call: https://calendar.app.google/pq2seCCcch9U2GFV8