Trace and choose the complete email path

Draw one outgoing path: mail app → authenticated submission → sending MTA → DNS MX lookup → receiving MTA → delivery → mailbox → reading client.

Label the protocol at every arrow. Include the ports and TLS mode. Mark where the SMTP envelope ends and where the RFC 5322/MIME message begins.

Provider HTTP APIs and webhooks can be excellent application interfaces, but they are provider contracts rather than universal mail transport. Keep SMTP at the interoperability boundary unless both ends explicitly share another system.

Finally, capture one real message’s headers and identify its Message-ID, MIME type, and Received trace without publishing addresses, tokens, or private content.

Build the trace as an evidence table:

Stage	Protocol or format	Success evidence	Common failure evidence
Submission	SMTP on 587 or 465	final 250 and queue ID	535, 552, TLS error
Relay	SMTP on 25	remote final 250	4xx, 5xx, timeout
Delivery	SMTP or LMTP	mailbox delivery result	quota or policy reply
Storage	provider mailbox	UID or object ID	missing or rebuilt state
Access	IMAP, POP3, JMAP	tagged OK, +OK, method result	protocol or sync error

Do not use one layer’s success as proof for the next. A webhook stating “accepted” may correspond to local queueing. A delivered event may still precede client synchronization. Define status names from the evidence you actually receive.

Redact raw traces before sharing them. Authentication tokens, internal hostnames, mailbox addresses, message content, and unique provider IDs can all be sensitive. Keep timestamps, reply classes, and a stable internal correlation ID where possible.

Trace one test message to an account you control. Record a submission ID, the oldest and newest Received fields, the envelope result if available, the MIME tree, and the mailbox identifier. Explain every gap instead of filling it with a guess.