Outlook rejecting your email, 550 5.7.515 and 5.7.509
Two Microsoft systems reject mail, and they mean opposite things. Consumer Outlook.com, along with Hotmail and Live, bounces you with 550 5.7.515 when you send more than 5,000 messages a day and fail its authentication bar. Exchange Online, the business side, bounces you with 550 5.7.509 because your own DMARC record says p=reject and the message didn’t pass, so the receiver did what you asked it to.
Most of the trouble, though, arrives with no bounce at all: the message is accepted, scored and filed in Junk, and the only trace is compauth=fail in the Authentication-Results header. All three end at the same fix, aligned SPF or DKIM plus an enforced DMARC record, and the fix is free.
Which Microsoft surface hit you
Match the string in the non-delivery report before you touch DNS. Each code points at a different fault, and the two most searched ones call for opposite responses.
| Code or signal | Where it comes from | What it means |
|---|---|---|
| 550 5.7.515 | Consumer Outlook.com, Hotmail, Live | You send more than 5,000 messages a day to consumer addresses and the mail fails SPF, DKIM or aligned DMARC |
| 550 5.7.509 | Exchange Online Protection, business tenants | The receiver honoured your own p=reject and the message failed DMARC |
| 550 5.7.511 | Exchange Online Protection | Your sending address or domain is on the recipient organisation’s banned-sender list, or on Microsoft’s |
| S3140, S3150 | Consumer Outlook.com | Your sending IP has poor reputation; an IP block that no DNS change lifts |
| compauth=fail in the header | Both surfaces, and the most common case | The mail was accepted and junked, and there is no bounce to read |
Exact NDR wording changes from time to time, so match the gist of the string rather than its punctuation. If your bounce carries a code that isn’t in this table, the email delivery router covers the rest of the Microsoft, Google and Yahoo strings.
This is a large audience. Of the 173,425,856 domains that publish an MX record in the September 2026 census, 14,697,578 route mail to Microsoft 365.
Whichever row you matched, the next question is which leg is failing: SPF, DKIM or DMARC alignment. The free scan reads all three records for your domain and names the one that’s missing, which saves you guessing at DNS.
Path A: consumer Outlook.com and 550 5.7.515
The consumer requirement is 5.7.515, and it has nothing to do with a Microsoft 365 tenant, yours or the recipient’s. Since May 2025, anyone sending more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses has to pass SPF, pass DKIM, and publish a DMARC record of at least p=none that aligns with the From domain. Miss any of the three and the bounce reads:
550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.
Two corrections, because search results get both wrong. This isn’t a 2026 mandate: if your mail started bouncing last week, your volume crossed the line or your DNS changed, and the rule stayed where it was. And nothing in the recipient’s tenant settings caused it, because consumer Outlook has no tenant. A campaign day that pushes you over 5,000 counts, even if your usual volume sits well under it.
Under 5,000 a day you dodge 5.7.515, and you can still be junked for the same missing records. That case has its own section below.
Path B: Exchange Online and 550 5.7.509
Exchange Online Protection on business tenants sends 5.7.509, and it’s the code people misread at the highest cost. The string says what happened in plain words:
550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.
Your domain publishes p=reject, this message failed DMARC, and the receiver did exactly what your record told it to do. Of the 316,600,902 domains in the September 2026 census, 16,714,260 (5.3%) publish p=reject, and that’s the only population that can produce this bounce. If you’re holding one, you’re holding proof that your policy fired.
If the bounced mail was legitimate, some sending source isn’t authenticated in an aligned way: a newsletter tool, a CRM, a scan-to-email device on the office copier. Find it in the header or in your DMARC aggregate reports and give it aligned SPF or DKIM. Don’t weaken the policy. Dropping to p=none to stop one bounce reopens exact-domain spoofing for anyone who receives a message claiming to be you, and the ladder from p=none back up to p=reject is laid out on the DMARC pillar.
The case that never bounces
Most Microsoft deliverability trouble produces no NDR. The message is accepted, scored and filed in Junk, and the only evidence is one header line. Open the message in the recipient’s mailbox, or in a test outlook.com mailbox you control, choose View message source, and look for:
Authentication-Results: spf=pass … dkim=fail … dmarc=fail action=none … compauth=fail reason=001
compauth is Microsoft’s composite authentication verdict. Where a domain publishes no DMARC record, Microsoft applies implicit, DMARC-like checks of its own, so a missing record doesn’t exempt you. The reason code tells you which kind of check failed.
reason=000means explicit authentication failed: your domain’s DMARC policy is quarantine or reject and the message failed it.reason=001means implicit authentication failed: your domain publishes no auth records, or not enough, and the message didn’t look like it came from you. This is the signature of a tenant where nobody switched on DKIM or published DMARC.reason=6xxcovers the implicit-authentication variants.601means the sending domain is one of the receiving organisation’s own accepted domains, which is intra-organisation spoofing, a message claiming to be from you arriving at you.
The spf=, dkim= and dmarc= verdicts on that same line name the leg to fix, which is why reading the header beats waiting for a bounce that will never come. compauth applies at any volume, so a sender well under 5,000 a day dodges 5.7.515 and still gets junked.
Two blocks that DNS will not lift
550 5.7.511 means the sending address or domain is on a banned-sender list, either the recipient organisation’s own or Microsoft’s. Authentication won’t move you off it; the recipient’s admin or Microsoft has to.
S3140 and S3150 come from consumer Outlook.com and mean the sending IP has poor reputation. They are IP blocks, so fixing SPF, DKIM and DMARC leaves them in place. Delisting goes through Microsoft’s sender support, and the authentication work below is what stops you going back on the list once you’re off it. If you send through shared infrastructure, the IP is the provider’s problem to raise, while the records stay yours.
One fix, three records
All three paths converge on the same three records for your domain, in this order.
SPF
The standard Microsoft 365 record is v=spf1 include:spf.protection.outlook.com -all, and tenant setup normally puts it there, so on Microsoft 365 SPF is rarely the missing leg. The platform hands you strict SPF at setup and most tenants stop there.
The guardrail most people get wrong is where receivers evaluate it: SPF is checked against the Return-Path domain (RFC5321.MailFrom), the address bounces go to, and the visible From header plays no part. A newsletter tool can pass SPF on its own bounce domain while doing nothing for yours, which is why DKIM and DMARC carry the weight.
DKIM
Microsoft 365 signs your mail from day one with the tenant’s onmicrosoft.com default signature, and that signature doesn’t align with your domain, so DMARC can’t count it. Publish two CNAMEs, selector1._domainkey and selector2._domainkey, pointing at the tenant’s keys, then enable signing for the custom domain in the Defender portal. Until you flip that switch, DKIM shows pass and DMARC still fails; the DKIM pillar covers alignment and the selector CNAMEs in full.
DMARC
Publish v=DMARC1; p=none; rua=mailto:... with a mailbox you’ll read. p=none changes nothing about delivery and starts the aggregate reports arriving. Read them, find every legitimate source they reveal (the CRM, the office copier), and authenticate each one with aligned SPF or DKIM. Then move to p=quarantine, and when the reports run clean, to p=reject. If you arrived here from a 5.7.509 bounce you’re already at reject, and your job is the middle step: the one source that was left unauthenticated.
Re-test by reading the header
The test is a header read, and a bounce watch tells you little. Send a message to a consumer outlook.com mailbox, open View message source, and confirm four verdicts on the Authentication-Results line: spf=pass, dkim=pass, dmarc=pass and compauth=pass. If one of the first three still says fail, that’s the leg, and the section above names the record.
Above 5,000 messages a day to consumer Outlook there’s a rider. You also need a valid, monitored From address and reply-to, a working unsubscribe, and a clean list. Authentication clears 5.7.515; complaint rate is what keeps you out of S3140 and S3150. None of it costs money. The records are DNS edits, the Defender toggle is a click, and the aggregate reports are free to receive.
Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.