Tracing a Single Email: Message Logs, Events and the Delivery Lifecycle

When a customer says an email never arrived, the fastest way to an answer is to read the email message logs for that one message and follow it from your application to the receiving mail server. Guessing at DNS records or sending rates before you have seen the timeline wastes hours. This guide shows us how to identify a message across systems, read the events in the right order, tell a temporary deferral from a permanent bounce, write a trace that support can act on, and build a small internal event store so that the next investigation takes minutes instead of days.

The three identifiers: message ID, queue ID and SMTP transaction ID

Most confusion in a trace comes from treating three different identifiers as one. They live at different layers, they are created by different systems, and they answer different questions. If you collect the right one at send time, a later search is simple. If you did not, you will be searching by recipient and time, which is slower and less certain.

Identifier	Created by	Scope	Best use
Message ID	Your platform when it accepts the message, or the Message-ID header the sender or server writes	The message across its whole life	Primary search key across platform logs, webhooks and your own records
Queue ID	One mail server for its own queue	That server only, and only while the message is queued there	Matching lines in a single server log, or quoting a remote server answer
SMTP transaction ID	The sending or receiving server for one connection and one delivery attempt	One attempt, which may carry one or more recipients	Showing exactly which attempt got which response
Your correlation ID	Your application, before it calls the platform	Your own business action, such as one order confirmation	Linking your logs, your database row and the platform events

The message ID is the one to build around. The Message-ID header is defined in RFC 5322 and is meant to be unique for each message. Many receiving servers also write their own queue or transaction ID into the text of their reply, for example the words queued as followed by a short string. That string is valuable because the recipient administrator can search for it, so keep the full reply text in the trace. Our guide on reading email headers shows where each of these appears in a delivered message.

The lifecycle of one email, step by step

A message passes through a series of states. The SMTP conversation itself is defined in RFC 5321, and the status codes that come back are structured by RFC 3463 and the delivery reports by RFC 3464. Platforms turn those steps into named events. The names below are generic, so check your MigoSMTP account for the exact event names, fields and retention.

1. Your application builds the message and writes a log line with your correlation ID, recipient and template.
2. The platform accepts it over SMTP or the API. From this point the platform owns the message and returns a message ID.
3. The message is queued and waits for a delivery slot, shaped by rate limits and the recipient domain.
4. A delivery attempt is made. The platform connects to the receiving server and walks through the SMTP commands.
5. The receiver answers. A 2xx reply means accepted, a 4xx reply means try later, and a 5xx reply means refused.
6. The message ends as delivered, or as bounced after a permanent refusal or after the retry window closes.
7. Recipient signals follow later, such as an open, a click, a complaint or an unsubscribe.

Event types and what each one tells you

Event names differ between platforms, but the meanings are stable. Use the table to translate whatever you see into one of these stages, and to know how much weight to put on it.

Event	Meaning	Final or interim	How much to trust it
Accepted	The platform took responsibility for the message after validating the request	Interim	High. It proves hand-off to the platform, nothing more
Queued	The message is waiting for a delivery attempt	Interim	High. A long stay here points to rate limits or a paused stream
Deferred	The receiver or the network asked us to try later, with a 4xx reply or a timeout	Interim	High. Read the reply text, because it names the reason
Delivered	The receiving server accepted the message with a 2xx reply	Final for delivery	High for hand-off, none for folder placement
Bounced	A permanent refusal, or the retry window ended	Final failure	High. Look at the enhanced status code
Complained	The recipient marked the message as spam and the mailbox provider reported it	Signal after delivery	Medium. Not every provider reports complaints
Opened	A tracking image was requested	Signal after delivery	Low to medium. Privacy features distort it
Clicked	A tracked link was followed	Signal after delivery	Medium. Security scanners can click links too
Unsubscribed	The recipient used an unsubscribe link or header	Signal after delivery	High. Must update your suppression data

Notice that only two of these events end the delivery story, and the rest are interim or happen afterwards. A ticket that says the email was accepted is not saying it was delivered, and a ticket that says delivered is not saying it was read. Keeping those claims separate prevents a lot of back and forth. For what to do with bounces, complaints and unsubscribes after the trace, see suppression list management.

Correlating your application logs with platform events

A trace only works if the two sides share a key. The simplest design has three parts: write the correlation ID before sending, capture the message ID in the send response, and log both on one line. After that, every webhook event carries the message ID, so a join on that field links your business action to the whole timeline.

What to log in your application

• Correlation ID. A random unique value, such as a UUID, created once per business action and reused on retries of the same action.
• Message ID returned by the platform. Store it in the same log line and in the database row for the order, user or ticket.
• Recipient and template name. Enough to search, without logging the message body.
• Time with a time zone. Use UTC everywhere, and write the offset explicitly.
• The API or SMTP response. A success response means accepted by the platform, so log it under that name and not under delivered.

Here is an invented example of the two sides of one send. The application log line and the platform events share the message ID. All names, addresses and values are made up for illustration.

app.log
2026-03-12T09:14:02Z INFO mail.send corr=ord-88213-confirm to=jo@example.org template=order_confirmation
2026-03-12T09:14:03Z INFO mail.accepted corr=ord-88213-confirm msg_id=m-5f2a91c0 status=accepted

platform events (JSON, one per line)
{"event":"accepted","msg_id":"m-5f2a91c0","rcpt":"jo@example.org","ts":"2026-03-12T09:14:03Z"}
{"event":"queued","msg_id":"m-5f2a91c0","rcpt":"jo@example.org","ts":"2026-03-12T09:14:03Z"}
{"event":"deferred","msg_id":"m-5f2a91c0","rcpt":"jo@example.org","attempt":1,"code":"451","enhanced":"4.7.1","reply":"Greylisted, try again later","ts":"2026-03-12T09:14:05Z"}
{"event":"delivered","msg_id":"m-5f2a91c0","rcpt":"jo@example.org","attempt":2,"code":"250","reply":"2.0.0 OK queued as 7Hq91","ts":"2026-03-12T09:19:06Z"}
{"event":"opened","msg_id":"m-5f2a91c0","rcpt":"jo@example.org","ts":"2026-03-12T09:41:50Z"}

Read the example from the top. The application handed over the message at 09:14:02 and got an acceptance a second later. The first delivery attempt was deferred with a 451 reply, which means try later. The second attempt, five minutes afterwards, got a 250 reply and the message was delivered. The customer then opened it. If the customer complained at 09:15 that nothing had arrived, the trace shows a normal retry and nothing to fix.

Matching on events your platform sends you

Platform events usually reach you through webhooks. Our guide to email webhooks and signature verification explains how to receive them safely, and reliable webhook handling explains duplicates and ordering. For tracing, the important rules are to verify each request, store the raw event before you transform it, and index on the message ID and the recipient.

Reading a deferral versus a bounce

The most useful skill in a trace is separating a message that is still in progress from one that has failed. The first digit of the SMTP reply code decides this. A 4xx reply is a temporary failure, and a 5xx reply is a permanent failure. RFC 3463 adds an enhanced status code of three numbers, such as 4.7.1 or 5.1.1, where the first number repeats the class, the second names the subject, and the third gives the detail.

Signal	Deferral	Bounce
SMTP class	4xx, or a connection timeout	5xx
Enhanced code starts with	4.	5.
What the receiver is saying	Not now. Try again later	No. Do not try again
What we do next	Retry on a schedule with growing gaps	Stop, record the failure and update suppression data
Typical causes	Greylisting, rate limiting, mailbox busy, temporary DNS or network trouble, reputation throttling	Unknown user, invalid domain, policy block, authentication failure, message too large
What you do	Wait, watch the trend, slow down if the reply asks for it	Read the code, fix the address or the cause, and do not resend blindly

A deferral can turn into a bounce when the retry window ends, and in that case the final reason is often the last deferral reply, so read the whole history. A single deferral is normal. Many deferrals for one receiving domain at the same time point to throttling, and our guide to rate limits, retries and backoff explains how to respond. For a catalogue of codes and fixes, see SMTP bounce codes explained.

A worked example: the missing invoice email

A customer writes at 15:00 that the invoice email for invoice 4471 did not arrive. Support has the customer address and an approximate send time of 14:30. They follow the steps in this guide with invented numbers, shown here to illustrate the method.

1. Support searches the application log for the recipient and finds correlation ID inv-4471-send with message ID m-c3d870aa, logged at 14:31:10 UTC.
2. They search the platform events for that message ID and find five events: accepted at 14:31:11, queued at 14:31:11, deferred at 14:31:14, deferred at 14:46:15, and bounced at 15:02:40.
3. Both deferrals carry code 452 with enhanced code 4.2.2 and the reply text mailbox full. The bounce carries code 552 with enhanced code 5.2.2 and the reply text over quota.
4. They classify the case. The message was accepted by us and attempted three times. Two attempts were temporary refusals and the third was a permanent one, all pointing to the recipient mailbox being over quota.
5. They conclude that this is not a sending problem and not an authentication problem. The cause sits at the recipient end.
6. They reply to the customer with the facts and the time of each attempt, ask for an alternative address, and send the invoice there. They also check that the original address is now in the suppression data so that the next invoice is not attempted until it is updated.

The whole investigation took four searches and a few minutes, because the identifiers were stored at send time. Without the message ID support would have searched by recipient and time, found the same events, and still needed to be sure it was the right message when the customer had received several that day.

A support-ticket-ready trace template

Whether the ticket goes to your own operations team or to us, the same template saves time. Fill every line you can, and write unknown where you do not have the value. Do not paste message bodies or full headers that contain private content unless asked, and remove anything the reader does not need.

TRACE REPORT
Summary: One sentence on what the sender or recipient expected and what happened.
Account / stream: sending account name and stream, for example transactional
Message ID: m-5f2a91c0
Correlation ID: ord-88213-confirm
Recipient (or domain only, if sensitive): jo@example.org
Sent (UTC): 2026-03-12T09:14:02Z
Template / message type: order_confirmation
Timeline (UTC, in order):
  09:14:03 accepted
  09:14:03 queued
  09:14:05 deferred  451 4.7.1  Greylisted, try again later
  09:19:06 delivered 250 2.0.0  OK queued as 7Hq91
Final state: delivered
Exact reply text from receiver: 250 2.0.0 OK queued as 7Hq91
What has already been checked: address spelled correctly, not in suppression data, SPF/DKIM/DMARC pass
Impact: one customer, one message, no pattern seen
Question / request: Please confirm the retry schedule that applied.

Retention and privacy of logs

Logs are useful because they are detailed, and that same detail makes them sensitive. A message log can include an email address, an IP address, a user agent string, a location inferred from an IP, a subject line and the time a person read a message. In many places that is personal data, and the rules about collecting, keeping and deleting it apply to you as the controller. Our guide on GDPR and email records covers the consent side of this.

Platform retention

Every sending platform keeps event and message data for a limited time. Check your MigoSMTP account for the exact retention period, which fields are stored, and whether you can export data before it expires. Do not assume a long window. If a policy question needs you to answer something from six months ago, plan to keep your own record instead of relying on the platform.

Your own retention rules

• Keep what you need. A minimal record, with message ID, recipient hash or address, event type, code and timestamp, answers most questions.
• Do not store bodies. Message content can include invoices, codes and personal details that make a log a risk. Store the template name and a version instead.
• Set a deletion schedule. For example, keep detailed events for a short window and a reduced record for longer, and write down your reasons.
• Restrict access. Support may need to search events, but few people need raw exports.
• Handle erasure. When you delete a person, delete or anonymize their events in your event store too, and keep a suppression entry that does not expose the address if you can.
• Protect secrets. Never log passwords, API keys, one-time codes or full password reset links. See our guide to API key security for the wider rules.

Building a searchable internal event store

Relying on a dashboard works until you need to answer a question the dashboard was not built for. A small internal event store, fed by webhooks, gives you your own history, your own retention and your own search. You do not need a large system to start. A single database table with the right indexes handles a lot of traffic.

Field	Purpose	Index it?
event_id	Unique ID from the platform if present, used to drop duplicates	Yes, unique
msg_id	The message ID, the primary join key	Yes
corr_id	Your correlation ID, copied from your send log or metadata	Yes
rcpt_hash	A hash or the address of the recipient, depending on your privacy rules	Yes
event_type	Normalized type such as accepted, deferred, delivered, bounced	Yes, with time
event_ts	Time reported by the platform, in UTC	Yes
received_ts	When your handler received the request	No
smtp_code and enhanced	The reply code and the enhanced status code	Optional
reply_text	The receiver text, truncated to a safe length	No
raw	The original payload, for replay and audit, kept for a shorter time	No

Design rules that save you later

1. Verify, then store raw. Check the signature, write the untouched payload, and only then parse it. If your parser has a bug, you can replay.
2. Be idempotent. The same event can arrive twice. Use a unique key so that the second insert does nothing.
3. Sort by event time. Use the platform timestamp for the timeline and your receive time only for debugging your handler.
4. Normalize event names. Map the platform names into your own small set, so that a future change of platform does not break reports.
5. Derive a current state. Keep a second table or view with one row per message and recipient holding the latest state, so support sees the answer at once.
6. Reconcile. Compare your store with the platform data on a schedule, and fill gaps if a webhook failed.

Once the store exists, it also feeds the numbers you care about. Deferral rates by domain, time to deliver and bounce reasons are all queries over the same table, and our guide to deliverability metrics explains which of them matter.

Common tracing mistakes

• Treating accepted as delivered. Acceptance by the platform is the beginning of the story.
• Searching only by recipient. It works until the same person receives several messages in the same hour.
• Mixing time zones. A two-hour offset can make a normal retry look like a failure.
• Ignoring per-recipient events. One message to several people is several outcomes.
• Trusting opens. A missing open is not a missing email.
• Dropping the reply text. The code says what class of problem happened, and the text says why.
• Resending before reading. A repeated send to a permanently failing address hurts your reputation and teaches you nothing.

A short checklist

1. Every send creates a correlation ID and stores the platform message ID next to it.
2. Application logs say accepted for a platform success and never say delivered.
3. Webhook events are verified, stored raw, deduplicated and indexed by message ID and recipient.
4. Timelines are sorted by event time in UTC.
5. Deferrals and bounces are separated by the status code class and read with the full reply text.
6. Tickets use the trace template, with exact reply text and what has been checked.
7. Retention, access and erasure rules for logs are written down and match your privacy policy.
8. Message bodies, secrets and one-time codes are never written to logs.

Further reading and sources

• RFC 5321: Simple Mail Transfer Protocol
• RFC 5322: Internet Message Format
• RFC 3463: Enhanced Mail System Status Codes
• RFC 3464: An Extensible Message Format for Delivery Status Notifications
• RFC 6522: The Multipart/Report Content Type for Reporting of Mail System Administrative Messages