Outlook Rejecting Your Email: 550 5.7.515, 550 5.7.509 and compauth=fail, Explained and Fixed (2026)

פורסם 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

Two different Microsoft systems reject mail. Consumer Outlook.com bounces high-volume senders that fail authentication (550 5.7.515, enforced since May 2025); Exchange Online bounces mail that fails your own DMARC reject policy (550 5.7.509). Of 10,205,070 domains authorising spf.protection.outlook.com, 85.0% have strict SPF but only 21.7% enforce DMARC, according to the Defaults.Exposed census of 261,086,232 domains.

Most “Outlook is rejecting my email” problems aren’t rejections at all — they’re mail silently landing in Junk with compauth=fail in the headers. This guide decodes the Microsoft codes, shows you how to read the Authentication-Results header, and walks the fix in order: confirm SPF, enable DKIM for your custom domain, publish and enforce DMARC, re-test.

Which Microsoft error do you actually have?

Microsoft runs two separate receiving surfaces, and they reject for different reasons. Match your symptom first — the wrong diagnosis wastes a day.

Code / signal	Where it comes from	What it means	Data as of 2026-06-29
550 5.7.515	Consumer Outlook.com / Hotmail / Live	You send >5,000 messages/day to consumer Outlook and fail the authentication requirements (SPF + DKIM + DMARC), enforced since May 2025	—
550 5.7.509	Exchange Online / EOP (business tenants)	The receiving server honoured your own domain’s DMARC `p=reject` — your mail failed DMARC	Only 10.59% of all 261,086,232 graded domains enforce DMARC
550 5.7.511	Exchange Online / EOP	Your sending address or domain is on the recipient organisation’s or Microsoft’s banned-sender list	—
S3140 / S3150	Consumer Outlook.com	Your sending IP has poor reputation — a block, not an authentication failure	—
`compauth=fail` (headers)	Both surfaces — the most common case	Mail was accepted but junked: Microsoft’s composite authentication failed. No bounce, no NDR — just the spam folder	Of 10,205,070 M365-sending domains, only 21.7% enforce DMARC

Exact NDR wording changes; verify the strings you quote against a live bounce before relying on them.

What does 550 5.7.515 mean?

It is the consumer Outlook.com/Hotmail requirement, not a Microsoft 365 tenant error. Since May 2025, senders of more than 5,000 messages per day to consumer Outlook addresses must pass SPF, pass DKIM, and publish a DMARC record (at least p=none) aligned with the From domain. Fail that bar and consumer Outlook rejects with wording like:

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

Two things this is not: it is not a 2026 mandate (if your mail just started bouncing, your volume or your DNS changed, not the rule), and it is not about the recipient’s M365 tenant settings. The fix is the authentication ladder below — and occasional campaign days that cross 5,000/day count.

What does 550 5.7.509 mean?

This one comes from Exchange Online Protection on business tenants, and it means your own DMARC policy is being honoured:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Read that carefully — it is not Microsoft being difficult. Your domain publishes p=reject, this message failed DMARC, and the receiver did exactly what you asked. If the bounced mail is legitimate, some sending source (a newsletter tool, a CRM, a scan-to-email device) isn’t authenticated in an aligned way. Don’t weaken the policy; give that source aligned SPF or DKIM — see fix DMARC and from p=none to p=reject.

Why is Outlook junking my mail with compauth=fail instead of bouncing it?

Most Microsoft deliverability pain never produces a bounce. The message is accepted, scored, and filed in Junk — the only evidence is the Authentication-Results header. In the recipient’s mailbox (or your own outlook.com test mailbox), open the message, choose View message source, and find the line:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth is Microsoft’s composite authentication verdict: even when a domain publishes no DMARC record, Microsoft applies implicit, DMARC-like checks. Commonly seen values:

compauth=fail reason=000 — the message failed explicit authentication: your domain’s DMARC policy is quarantine/reject and the message failed it.
compauth=fail reason=001 — the message failed implicit authentication: your domain publishes no (or not enough) auth records, and the message didn’t look like it came from you. The classic “we never set up DKIM/DMARC” signature.
compauth=fail reason=6xx — implicit-authentication failure variants; 601 specifically means the sending domain is one of your organisation’s own accepted domains (intra-org spoofing, self-to-self).

The lesson: on Microsoft, read the header, not just the NDR. The spf=, dkim= and dmarc= verdicts on that same line tell you exactly which leg to fix.

How do you fix Outlook rejections and junking?

Run the free scan first. It grades your SPF, DKIM and DMARC in one pass and shows which leg is failing before you touch DNS.
Confirm SPF — usually already fine on Microsoft 365. The standard record is v=spf1 include:spf.protection.outlook.com -all, and M365 setup puts it there: 85.0% of the 10,205,070 domains authorising spf.protection.outlook.com already end in strict -all (data as of 2026-06-29). One guardrail: receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, not the From header — so a newsletter tool can pass SPF on its bounce domain while doing nothing for yours. That’s why steps 3 and 4 matter more.
Enable DKIM for your custom domain — two selector CNAMEs. M365 signs with an unaligned onmicrosoft.com default until you switch on custom-domain signing: publish selector1._domainkey and selector2._domainkey CNAMEs pointing at your tenant’s keys, then enable signing in the Defender portal. Full click-path: set up DKIM on Microsoft 365. If DKIM shows “pass” but DMARC still fails, you’re in the default-signature trap.
Publish DMARC, then enforce it. Start with v=DMARC1; p=none; rua=mailto:... to get reports, fix every legitimate source it reveals, then ratchet to p=quarantine and p=reject — the staged path is in fix DMARC. This is the step most Microsoft shops skip: only 21.7% of M365-sending domains enforce DMARC.
Re-test by reading the header. Send to a consumer outlook.com mailbox, open the message source, and confirm spf=pass, dkim=pass, dmarc=pass and compauth=pass.
High-volume senders: meet the consumer-Outlook bar. Over 5,000/day you also need a valid, monitored From/reply-to, working unsubscribe, and clean lists — authentication clears 5.7.515; complaint rate keeps you out of S3140/S3150 IP blocks. If you’re already IP-blocked, fixing SPF/DKIM/DMARC does not lift the block: request delisting through Microsoft’s sender support, and treat authentication as the reason you won’t be back.

Why do so many Microsoft 365 domains still fail?

Because the default does the first step for you and none of the rest. Among the 10,205,070 domains that authorise spf.protection.outlook.com, 85.0% carry strict SPF — the record M365 hands you at setup — but only 21.7% enforce DMARC, according to the Defaults.Exposed census of 261,086,232 domains. M365 gives you strict SPF by default, then most tenants stop there — the exact population compauth was built to catch (though still ahead of the 10.59% DMARC enforcement across all graded domains). Full provider comparison: our email-provider SPF league table.

Frequently asked questions

Is 550 5.7.515 a Microsoft 365 error? No. It comes from consumer Outlook.com/Hotmail and targets senders of >5,000 messages/day, enforced since May 2025. Business Exchange Online rejections use different codes — most commonly 550 5.7.509 (your DMARC reject policy) or 5.7.511 (banned sender).

We got 550 5.7.509 but the mail was legitimate — should we drop p=reject? No — your policy caught an unauthenticated source, which is it working. Find the source in the header or your DMARC reports and give it aligned DKIM (or aligned SPF). Weakening to p=none reopens exact-domain spoofing for everyone.

Does compauth=fail mean someone is spoofing us? Not necessarily. reason=001 usually means your own mail can’t prove it’s yours — no aligned DKIM, no DMARC. Only 21.7% of the 10,205,070 M365-sending domains enforce DMARC (data as of 2026-06-29), so Microsoft applies implicit checks to everyone else, and unauthenticated legitimate mail fails them too.

I send fewer than 5,000 emails a day — can I ignore this? You’ll dodge 550 5.7.515, but not the Junk folder: compauth applies at any volume. Gmail runs the same play — see the Gmail 550 5.7.26 guide. The fixes are free; the barrier is awareness, not cost.

Send the owner the report

If you fix email for someone else — a client, your boss, the firm whose invoices were bouncing — finish the job with proof. Re-run the free scan after DNS settles and forward the graded report. It shows SPF, DKIM and DMARC going green in plain language a business owner can read, and it’s the artefact they’ll need next time the cyber-insurance renewal or a customer security questionnaire asks whether their email is authenticated. Fixed is good; provably fixed is what gets you paid and them covered.

Check your domain free

See which leg Microsoft is failing you on — SPF, DKIM, DMARC — privately and owner-only.

Check your domain → · Fix DMARC → · DKIM passes but DMARC fails → · How we grade → · Aggregate data only. Data stored and processed in the EU.