# Outlook 550 5.7.509 vs 5.7.515: two rejections, two fixes

> 550 5.7.509 means your From domain failed DMARC and publishes p=reject. 5.7.515 means a high-volume sender lacks required authentication. Fix each differently.

- Published: 2026-11-04
- Author: Koltrix Team
- Category: Deliverability
- Source: https://koltrix.com/blog/outlook-550-5-7-509-vs-5-7-515-two-dmarc-rejections-two-different-fixes

Two Microsoft bounces look almost the same and are fixed in different places. `550 5.7.509` says a message failed DMARC and the sending domain asked for rejection. `550 5.7.515` says a high-volume sender does not meet Microsoft's required authentication level. If you treat one as the other, you will spend an afternoon editing the wrong DNS record.

## What is the difference between 5.7.509 and 5.7.515?

**5.7.509 is a per-message DMARC failure under a `p=reject` policy. 5.7.515 is a domain-level authentication shortfall for senders above 5,000 messages a day to Outlook.com consumer mailboxes.** The first can hit a domain sending ten emails a day. The second only applies at volume.

| | 5.7.509 | 5.7.515 |
|---|---|---|
| Bounce text begins | `550 5.7.509 Access denied, sending domain ... does not pass DMARC verification` | `550 5.7.515 Access denied, sending domain ... does not meet the required authentication level` |
| Trigger | The message fails DMARC and your DMARC record says `p=reject` | The domain sends more than 5,000 messages a day and lacks SPF, DKIM or a DMARC record with alignment |
| Who is affected | Microsoft 365 recipients and Outlook.com, Hotmail and Live recipients | Outlook.com, Hotmail and Live (consumer) recipients |
| Scope | One message or one sending source | Usually every message from the domain |
| Where to fix | The one source that is not aligned | The domain's whole authentication setup |

The bounce wording above follows Microsoft's own announcements: the [DMARC policy handling post](https://techcommunity.microsoft.com/blog/exchange/announcing-new-dmarc-policy-handling-defaults-for-enhanced-email-security/3878883) for 5.7.509 and the [high-volume sender requirements post](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) for 5.7.515. Check the current text in your own bounce, since Microsoft can change wording and rollout stages.

## What does 550 5.7.509 actually mean?

**DMARC is a DNS policy that tells receivers what to do with mail that fails both aligned SPF and aligned DKIM. 5.7.509 is Microsoft carrying out that policy: your domain published `p=reject`, this message did not pass, so it was refused.** Microsoft said it changed Outlook.com and Microsoft 365 to honor the sender's DMARC policy starting in July 2023, with failing `p=reject` mail rejected and `p=quarantine` mail quarantined by default for Microsoft 365 tenants.

Two things follow from that:

- It is permanent. A 550 is not retried, so the message is gone until you resend it.
- Your policy worked as designed. The real question is why a legitimate message failed DMARC.

DMARC passes when SPF or DKIM passes **and aligns** with the visible From domain. "Passes" and "aligns" are separate tests, which is where most 5.7.509 cases hide. See [DMARC alignment: relaxed versus strict](/blog/dmarc-alignment-relaxed-strict) for the exact rules.

## Why do legitimate messages fail DMARC?

The common causes, most frequent first:

1. **A sending service you forgot.** A CRM, invoicing tool, form plugin or scanner sends as your domain but is not in your SPF record and does not sign with your DKIM key.
2. **Passing, but for another domain.** The vendor's SPF passes for `bounce.vendor.com` and DKIM is signed as `d=vendor.com`. Both pass, neither aligns with your From domain.
3. **DKIM not enabled for your custom domain** on the platform that sends the mail.
4. **Forwarding.** A forwarder changes the connecting IP, so SPF breaks, and any edit to the body can break DKIM. This is explained in [why forwarding to personal inboxes breaks](/blog/why-forwarding-to-personal-inboxes-breaks) and [DMARC, forwarding, mailing lists and ARC](/blog/dmarc-forwarding-mailing-lists-arc).
5. **Moving to reject too early.** The policy went to `p=reject` before every legitimate source was aligned. [A week-by-week DMARC rollout](/blog/dmarc-none-to-reject-rollout) exists to prevent this.
6. **A real spoof.** Sometimes the rejection is the system working. If you do not recognize the source, leave it blocked.

## How do you fix 5.7.509?

**Find the one source that failed alignment, make it sign with your own domain, and resend.** Work through it in this order.

1. **Read the headers in the bounce.** Many NDRs include the original message headers. Look for `Authentication-Results` and note which of `spf`, `dkim` and `dmarc` failed, and what domain each used (`smtp.mailfrom`, `header.d`, `header.from`).
2. **Identify the sender.** The `Received` lines and the From address tell you whether it was your app, a SaaS tool or a forward.
3. **Fix the aligned leg.** Prefer DKIM, because it survives more situations than SPF. Publish the DKIM record the service gives you under your domain so the signature carries `d=yourdomain.com`.
4. **Set a custom return-path** if the service offers one, so SPF aligns too.
5. **Send a test** to a mailbox you control at Outlook.com and confirm `dmarc=pass` in the delivered headers.
6. **Resend the bounced message by hand.** Microsoft will not retry it.
7. **Keep `p=reject`.** Do not drop to `p=none` to make an error disappear. That removes protection for everyone.

A quick way to see everything still failing is your aggregate reports. [Reading DMARC aggregate reports](/blog/reading-dmarc-aggregate-reports) shows how to pull the unaligned sources out of the XML.

## What does 550 5.7.515 mean, and how is the fix different?

**5.7.515 means Microsoft judged your whole domain, not one message.** In April 2025, Microsoft announced that domains sending more than 5,000 messages a day to its consumer services must pass SPF and DKIM and publish a DMARC record that aligns. Non-compliant mail was first routed to Junk from May 5, 2025, with rejection described as a later stage and the date to be announced. The 5.7.515 bounce is that rejection stage. The details are in [Outlook.com's requirements for high-volume senders](/blog/outlook-high-volume-sender-requirements).

The fix is a checklist for the domain, not a hunt for one source:

| Check | What to confirm |
|---|---|
| SPF | Record exists, authorizes every sender, stays under the 10-lookup limit |
| DKIM | Every stream signs with your domain, with a modern key length |
| DMARC | A record exists, at least `p=none`, with SPF or DKIM aligned on every stream |
| Streams | Marketing, transactional and support mail all pass, not only the main one |
| Reachable From | The From or Reply-To address can receive replies |

Counting matters. The 5,000 figure is for the domain across all your senders, so a marketing tool plus a product app plus a support inbox can add up faster than you expect.

## How do you tell which one you hit in two minutes?

Ask three questions in order:

1. **Does the bounce text say "does not pass DMARC verification"?** Then it is 5.7.509. Find the unaligned source.
2. **Does it say "does not meet the required authentication level"?** Then it is 5.7.515. Audit the domain.
3. **Do you publish `p=reject` and send under 5,000 a day?** Then 5.7.509 is the only one of the two that can apply to you.

If it is 5.7.509 and only one tool is affected, you have a single misconfigured source. If it is 5.7.515 and everything bounces, the problem is the domain's setup, and starting at SPF, DKIM and DMARC records in DNS is the right move.

## Where does Koltrix help?

Koltrix signs mail for each custom domain with its own 2048-bit DKIM key, so mail sent through Koltrix carries your domain in the signature, which is the aligned leg DMARC needs. After you verify a domain, check the DNS records Koltrix shows and confirm your test message reads `dmarc=pass`. The setup steps are in [docs.koltrix.com](https://docs.koltrix.com). Your other senders, such as a CRM or an invoicing tool, still need their own aligned DKIM on the same domain.

## Bottom line

- 5.7.509 is DMARC doing its job under `p=reject`. Find the single unaligned source, fix it, resend.
- 5.7.515 is Microsoft's high-volume rule. Audit SPF, DKIM and DMARC for the whole domain.
- Read the bounce text before touching DNS, and check the `Authentication-Results` lines in the headers.
- Never lower your DMARC policy just to clear an error.
- Both are permanent 550 failures, so resend after the fix.