Draw the route before changing it

Start with a single event, such as a password reset requested at 14:02 UTC. Draw six boxes: application, queue, sending service, DNS-controlled identities, receiving SMTP system, and mailbox. Add an owner and an observable identifier to each box. The same message may have an application job ID, a provider message ID, and a receiver-side message ID; record the relationship without assuming the values are interchangeable.

The application decides that a message should exist. A queue may delay or retry the work. The sending service creates the SMTP envelope and message headers, signs the message, and connects to a receiver selected through DNS. The receiver evaluates the SMTP conversation and may add trusted authentication results before later filtering into a mailbox.

Mark the evidence at each boundary

Use a simple timeline:

14:02:03  application created reset event reset_123
14:02:05  queue started job job_456
14:02:06  sender accepted submission provider_789
14:02:08  remote MX returned 250 for recipient
14:02:10  authorized test account observed message in inbox

The host that returned the SMTP reply matters. So do the envelope sender used for SPF, the DKIM signing domain and selector, and the visible From domain used by DMARC. DNS publishes information used by these systems; DNS itself does not deliver the message.

Locate the break accurately

If no application event exists, an SPF edit cannot help. If the job never left the queue, contact the application owner. If the sending service rejected the submission, use its documented error. If the remote system rejected SMTP, capture the complete response and timestamp. If it accepted the message but the monitored mailbox cannot find it, investigate receiver-side placement and confirm that the test account and search are functioning.

Avoid treating a dashboard’s final label as the only evidence. Preserve a correlation map with the minimum personal data needed, and redact addresses before sharing it outside the authorized team.

Confirm the map

Run one fresh test through the normal path. Ask each owner to point to their evidence and state where responsibility transferred. The map is useful when it reveals an unknown boundary or missing identifier before the next incident, not when it merely produces a polished diagram.