Mail not received: submission, rejection, or visibility?

Understand the likely causes

• A typo or stale address, recipient policy, quota, filtering, authentication, routing, synchronization, or search/folder context may explain the report. Some conditions need a messaging administrator or security owner.
• Repeated resending can create duplicates, leak confidential content, or add load while the original condition remains. Raw message bodies and private conversations are usually unnecessary for initial technical escalation.

Identify the message and the failed stage

Record a sanitized message identifier, relevant UTC or time-zone context, intended sender/recipient scope, exact diagnostic, and where the failure was observed. Distinguish a missing client display from a server-generated rejection. Do not collect passwords, MFA codes, or unrelated mailbox contents. Unexpected notices or attachments may need the security-reporting process. This guide sends no message, accesses no mailbox, queries no trace service, and changes no account.

A status class is not the complete diagnosis

SMTP reply classes help distinguish success-class, temporary failure, and permanent failure, but the command stage, enhanced code, vendor text, and policy still determine meaning. A success response for one protocol step does not prove the recipient read a message. The fixed classifier below is deliberately limited to three authored numeric strings; it is not an SMTP client, NDR parser, or full delivery-state machine. Preserve the actual response instead of replacing it with a broad label.

labels = {'2': 'success-class', '4': 'temporary-failure-class', '5': 'permanent-failure-class'}
for reply in ('451', '550', '250'):
    print(reply + '=' + labels.get(reply[0], 'unclassified'))

451=temporary-failure-class
550=permanent-failure-class
250=success-class

Preserve who reported and who rejected

A useful escalation keeps the generating/reporting system separate from the system that rejected the transaction, along with message id, status, time, intended route, scope, and approved comparison results. The following fictional handoff lacks the rejecting-system field. Its structural check does not certify every other value or prove the actual error source. Use the service’s current official documentation and required role for further investigation; a familiar code does not grant authority to inspect another user’s mailbox or change recipient policy.

handoff = {'message_id': '<lab-ndr-1@example.test>', 'reported_utc': '08:00',
           'status': '550 5.1.1', 'recipient_domain': 'example.test'}
required = {'message_id', 'reported_utc', 'status', 'recipient_domain', 'rejecting_system'}
print('missing=' + ','.join(sorted(required - handoff.keys())))

missing=rejecting_system

Route a narrow remedy through the responsible owner

A verified address issue, client synchronization problem, recipient restriction, service failure, or security event needs a different correction path. Confirm address changes through trusted sources instead of guessing another recipient. Do not disable filtering, release quarantined content, modify forwarding, or reset accounts as a generic mail fix. Any approved reproduction should use permitted test content and scope. Preserve original evidence and distinguish restoration from root-cause confirmation. No operational remedy is executed by this guide.

Keep it from recurring

• Keep mail-stage terminology, trusted address maintenance, approved evidence retention, and messaging/security escalation clear. Review product-specific documentation and role requirements before interpreting traces or changing policy. Use synthetic examples for training and avoid forwarding private conversations merely to demonstrate that a support ticket contains evidence.