Start with one identifiable message
“Email is broken” is difficult to investigate without an example. Record the sender and recipient addresses, approximate time with time zone, subject and application used. Establish whether the message came from a phone, webmail, accounting software or a website form. Include the message identifier for an authorised administrator if it is available.
Do not circulate the entire conversation to unrelated people or a public forum. Headers and delivery reports can contain addresses, identifiers and message excerpts. Keep the original in a controlled location and provide the support recipient only the material needed for diagnosis.
Distinguish sending from delivery
Check whether the message remains in the Outbox, appears in Sent Items or returned with an error. Sent Items shows what the client did; it does not prove that the recipient saw the message. Determine whether the problem affects one address, one recipient domain or every outgoing message.
The email administrator can inspect message tracing and its events. A service’s delivered status does not mean the message was read. The recipient should check the correct mailbox, junk folder, rules, search and any forwarding. Confirm that both parties are using the intended address and account.
Read the reason, not just the report title
Find the failed recipient, status code and exact server response in the nondelivery report. An unknown address requires a different action from a full mailbox, size restriction or security-policy rejection. Codes beginning with 4 usually indicate a temporary problem, while 5 indicates a permanent rejection of that request; interpret the complete diagnostic text.
For an incorrect address, create a new message and type the confirmed address rather than reusing a stale autocomplete entry. For a temporary delay, inspect the service’s queue and retry schedule. Repeated manual sending can create duplicates when delivery resumes.
Investigate spam and quarantine separately
If the message was held as suspicious, first confirm that it was expected. Contact the sender through an established channel, particularly for invoices, changed bank details or sign-in requests. Do not release an attachment merely because its displayed sender name matches a supplier.
An administrator should examine the classification reason and make the narrowest justified correction. Permanently allowing an entire domain or disabling protection for everyone can remove an important control. After release, confirm the destination folder and report an incorrect classification through the email service’s supported mechanism. Keep the investigation separate from opening potentially unsafe content.
Check sending identity after system changes
A problem beginning with a new website form, invoicing system or sending service may involve domain authentication. Identify the actual sending system, inspect SPF, DKIM and DMARC results, and compare them with the vendor’s configuration. Analyse a specific message because different applications can follow different delivery paths.
Do not add speculative DNS records or disable DMARC simply to suppress an error. Preserve previous values and plan a controlled test before changing configuration. A sudden increase in bounces for messages nobody recognises also warrants checking for account misuse or impersonation, rather than treating every report as a routine delivery failure.
Confirm the repair with a controlled test
Agree one test message without confidential information with the recipient. Check the affected direction, the reply and a comparable attachment type if attachments caused the failure. Compare administrator-side events with the recipient’s confirmation. The absence of another bounce should not be the sole evidence of repair.
Record the cause, change, test time and any dependency on another operator. If unresolved, escalate with the message identifier and diagnostic response. Do not resend a whole batch automatically; establish which messages arrived first. This avoids duplicating business correspondence while leaving a clear record of what still requires investigation.
Sources: Microsoft Learn — Trace an email message in Exchange Online · Microsoft Learn — Email nondelivery reports and SMTP errors in Exchange Online · Microsoft Support — Failed delivery messages from the postmaster