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.
On this page(8 sections)
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 for 5.7.509 and the high-volume sender requirements post 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 for the exact rules.
Why do legitimate messages fail DMARC?
The common causes, most frequent first:
- 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.
- Passing, but for another domain. The vendor's SPF passes for
bounce.vendor.comand DKIM is signed asd=vendor.com. Both pass, neither aligns with your From domain. - DKIM not enabled for your custom domain on the platform that sends the mail.
- 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 and DMARC, forwarding, mailing lists and ARC.
- Moving to reject too early. The policy went to
p=rejectbefore every legitimate source was aligned. A week-by-week DMARC rollout exists to prevent this. - 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.
- Read the headers in the bounce. Many NDRs include the original message headers. Look for
Authentication-Resultsand note which ofspf,dkimanddmarcfailed, and what domain each used (smtp.mailfrom,header.d,header.from). - Identify the sender. The
Receivedlines and the From address tell you whether it was your app, a SaaS tool or a forward. - 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. - Set a custom return-path if the service offers one, so SPF aligns too.
- Send a test to a mailbox you control at Outlook.com and confirm
dmarc=passin the delivered headers. - Resend the bounced message by hand. Microsoft will not retry it.
- Keep
p=reject. Do not drop top=noneto 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 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.
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:
- Does the bounce text say "does not pass DMARC verification"? Then it is 5.7.509. Find the unaligned source.
- Does it say "does not meet the required authentication level"? Then it is 5.7.515. Audit the domain.
- Do you publish
p=rejectand 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. 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-Resultslines in the headers. - Never lower your DMARC policy just to clear an error.
- Both are permanent 550 failures, so resend after the fix.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
