Outlook delivery problems: choose the right investigation

Outlook can name the application someone reads mail in, a consumer mailbox service or part of a business Microsoft 365 environment. The app's name does not identify the server that handled your message. Start with the recipient domain, actual delivery route and available administrator evidence.

Microsoft's consumer sender-support route covers Outlook.com and related services such as Hotmail, Live and MSN. A business mailbox hosted in Microsoft 365 has its own tenant administration and policies. Keep those investigation paths separate instead of sending every problem to the same form.

Open one incident record with the sending address, affected recipient or bounded recipient group, sending IP when available, message identifier and UTC time. Preserve the unedited diagnostic privately. Give the incident an owner and state what remains unknown; a screenshot saying not delivered is not enough to choose a repair.

Keep the SMTP reply, enhanced status and diagnostic wording together. A temporary failure and a permanent rejection call for different queue decisions. An acceptance response shows a transport milestone; it does not show which folder the recipient later saw.

Use the desk below to choose the next evidence-gathering action. It does not inspect a mailbox or diagnose a campaign. If you have only a lack of replies or an open-tracking result, record placement as unknown and obtain stronger evidence before choosing the Junk branch.

Microsoft documents 550 5.7.515 for consumer-service messages whose From domain does not meet the required authentication level. Its high-volume requirements include passing SPF and DKIM, a DMARC record and alignment sufficient to pass DMARC. Diagnose the actual failing route rather than assuming a published record proves every message meets those conditions.

Collect a controlled message from the same sender and sending path. Compare the visible From domain, envelope-sender domain, DKIM signing domain and receiving authentication results. If only one application fails, ask its owner to inspect that route before changing unrelated senders.

Do not use a new subject line or a different contact list as an authentication repair. Equally, an authentication fix does not settle every reputation, content or receiving-policy question. Record which condition was corrected and what the new evidence demonstrates.

If another enhanced code appears, follow its own documentation and diagnostic wording. A familiar numeric prefix is not enough to identify the underlying cause.

Microsoft's current SNDS portal is at substrate.office.com/ip-domain-management-snds/snds. Its notice updated 22 September 2026 identifies it as the replacement for the old sendersupport.olc.protection.outlook.com/snds site. The portal describes IP-level reporting and includes the Junk Email Reporting Program for reports generated when users mark messages as junk.

Access requires a Microsoft account and authorization for the IPs you are responsible for. Microsoft states that network access expires ten months after approval or migration unless renewed. If a bookmark or feed stops working, check the current portal, access status and responsible network owner before concluding the reporting service has disappeared.

A mailbox user may not control the underlying sending IP. Ask the infrastructure owner for the relevant evidence instead of trying to enroll an unrelated network. Record the covered IPs and reporting period with any exported information.

Treat absent feedback as an evidence gap. It may reflect scope, access, reporting or the traffic observed; it does not establish that nobody complained. Handle any received complaint through the appropriate suppression and review process.

For a business Microsoft 365 recipient, ask an authorized administrator in the relevant tenant to locate the specific message and inspect its events. An external sender cannot obtain that tenant's private trace merely by knowing the recipient address. Provide precise identifiers and times so the administrator can find the right event.

Microsoft's trace guidance warns that Delivered can include messages sent to Junk or quarantine. Read the event details and action rather than treating that top-level status as an inbox receipt. Trace evidence also has limits; a missing result needs investigation rather than a conclusion that nothing happened.

Preserve the authentication results and documented anti-spam headers. Microsoft now explains that SCL alone does not determine the cloud filtering verdict or action; categorization and other signals matter. Ask what action the applicable policy actually took instead of turning one number into a universal diagnosis.

Where a message was incorrectly filtered, use the recipient or administrator's supported submission process. Avoid broad allow-listing as the default repair: the responsible administrator should assess the specific message and relevant policy.

This fictional exercise contains four separate controlled messages from two sending routes. It is a diagnostic comparison, not a deliverability test or a measured success rate. Each row supplies the evidence needed for a different next action.

Case A supports a route-specific authentication repair. Case B requires checking an existing queue before another submission. Case C gives a business administrator a policy event to investigate. Case D supports only that one message reached the observed folder; it does not clear the other cases.

Keep the sending path attached to each result. If A and D used different applications, D cannot verify A's repair. After changing A's signing configuration, send a new controlled message through A's route and record its authentication and observed delivery. Close that finding only to the extent the new evidence supports.

Write the finding as an observable condition: a particular route fails authentication, a message remains queued after a stated response, or a tenant policy quarantined the supplied item. Then identify the owner, proposed change and observation that would show whether it worked.

For unresolved consumer-service issues, use the sender-support path linked from Microsoft's current guidance. For business Microsoft 365, follow the actual NDR instructions or work with the receiving administrator. A removal or support request is not a promise of future inbox placement.

Provide a concise packet: affected service, domain and IP where relevant, recent timestamps, exact responses, bounded scope, authentication evidence and changes already made. Share message contents and personal information only through the appropriate support channel.

Verify the queue state before any corrective send. Keep the original evidence and the post-change result together. If the problem persists, narrow the next question using that comparison instead of changing several unrelated settings at once.

Use one record per bounded problem and link related cases when the evidence supports a connection. This keeps a single address typo from being described as a platform outage and a wider route defect from being closed after one unrelated successful message.

Finish with a current state and review time. It is reasonable for an investigation to end this stage with a specific unanswered question, provided somebody owns the evidence needed to resolve it.