Outlook.com 550 5.7.515 Rejection: Authentication Triage
Triage Outlook.com 550 5.7.515 with the exact reply, emitted headers, and documented authentication requirements.
Product & Engineering · September 25, 2026 · 2 min read
A 550 5.7.515 response is a durable rejection signal that warrants authentication and policy investigation before retrying. Preserve the exact response, distinguish Outlook.com from Microsoft 365, and verify what the message actually emitted.
Preserve the rejection
Save the complete SMTP reply, enhanced code, UTC time, sender domain, IP, recipient environment, and message ID. Do not repeatedly retry a permanent-looking rejection while changing several variables.
Check whether the affected recipients are Outlook.com consumer accounts and whether the pattern is provider-specific.
Verify authentication and alignment
Inspect SPF authorization for the envelope identity, DKIM signature and d= domain, DMARC result and alignment, From domain, and any Microsoft authentication context. Use full headers from a delivered sample or controlled test.
Compare the evidence with Microsoft’s current high-volume sender guidance. Authentication pass is necessary evidence, not an inbox guarantee.
Retest and escalate
After one controlled correction, send a test and retain its response and headers. If rejection remains, prepare the Sender Support evidence packet rather than assuming a retry will clear it.
Quick checklist
- Label the provider and environment rather than guessing.
- Preserve UTC time, message ID, exact SMTP text, and full headers.
- State the denominator for every acceptance, placement, or reply rate.
- Change one variable, retest, and retain the before/after evidence.
Edge cases and next action
A Microsoft 365 tenant policy can produce a different event path. Do not apply an Outlook.com error code to every Microsoft receiver. Use the provider-specific triage model as the hub; related evidence paths include microsoft 365 email delivery diagnostics, read authentication results.
Where RepMail fits
RepMail can preserve controlled test identifiers and sender-side results; the provider’s response and headers remain authoritative for this error.
Verify the sender path, not only DNS
List every system that can emit the message and identify which one supplied the Return-Path and DKIM selector. A DNS record may be correct for one relay while another relay sends with a different identity. Use a full delivered header or controlled test to connect the rejection to the actual path.
Do not repeatedly submit the same rejected message while changing volume, content, and authentication together. Preserve the original response, make one correction, and retest. If the response persists, keep the Outlook.com label and prepare a focused support packet rather than extending retries.
Keep the error code tied to the original recipient environment and date. Similar-looking Microsoft responses can follow different paths in Outlook.com and Microsoft 365. If only one relay or domain fails, compare its emitted headers with a passing path before changing the shared DNS design. A controlled retest should use a fresh message ID and record the complete response.
Sources
Resources in this guide
| Evidence | What it can show | What it cannot prove |
|---|---|---|
| SMTP reply | Acceptance, deferral, or rejection context | Inbox placement |
| Full headers | Authentication and routing context | Provider algorithm |
| Provider dashboard | Delayed aggregate signal | One recipient outcome |
Common mistakes to avoid
- Treating acceptance as inbox placement or a dashboard as a mailbox-level verdict.
- Mixing consumer and tenant environments or guessing an unknown provider cohort.
- Changing several variables before preserving a before/after comparison.
Frequently asked questions
Is provider-specific evidence proof of universal deliverability?
No. It describes the tested provider, identity, environment, and time window. Keep other providers and unknown cohorts separate.
Should I change DNS as soon as one provider reports a problem?
Not before preserving the exact response and message headers. First identify whether the issue is authentication, acceptance, placement, tenant policy, list quality, or timing.
What should I record for a useful diagnosis?
Record provider and environment, UTC time, sender identity, recipient cohort, message ID, SMTP response, headers, campaign version, and the denominator used for any rate.
Continue learning
Review provider-specific triage
Route the next diagnostic step without mixing receiver environments.