Skip to content
tmail
Get started
Back to blog

What your mail server logs cannot tell you about delivery

A 250 reply means the next hop accepted the message. It says nothing about whether it reached an inbox, a spam folder, or a black hole. Reading logs correctly starts with knowing where your visibility ends.

Someone reports that mail did not arrive. The first instinct is to check the logs, and the logs say the message was delivered. Both statements are true and they describe different things.

Where the log stops

An SMTP transaction ends when the receiving server replies 250 after the body. That is an acknowledgement that the message was accepted and queued. It is not a claim that the message reached a mailbox, and the specification does not pretend otherwise. A 250 response in the DATA phase means the message has been accepted for delivery, which is a statement about the receiving server's responsibility from that moment.

Everything after that point happens inside a system you do not operate: content filtering, spam classification, user-level rules, mailbox quota, forwarding chains, and eventually a human or an application reading or not reading. Your sending log has no visibility into any of it.

So "delivered" in your log means "handed off successfully." The gap between that and "in the inbox" is where most delivery incidents live.

Three layers worth naming separately

Separating them makes diagnosis tractable, because each layer fails differently and is fixed by different people:

  • Sending layer. Your application called SMTP. Fully observable in your own logs. Failures here are your bugs: bad headers, unauthenticated domains, wrong recipient, timeouts.
  • Transport layer. Your MTA or relay talked to the receiving MX. Partially observable. You see the reply codes you received, including 4xx deferrals and 5xx rejections. Failures here are shared: authentication policy, reputation, TLS, greylisting.
  • Inbox layer. The message was accepted and then either surfaced or not. Not observable at all from the sending side, except through feedback that the receiving system chooses to provide.

Most misdiagnosis is a layer-3 question answered with layer-1 evidence.

The feedback that does exist

You are not entirely blind, but what you can see is coarse and delayed:

  • Bounce messages tell you about 5xx outcomes, but only for failures that happen before or during the handoff, and only if the bounce itself is deliverable to you. A bounce to a forged sender goes nowhere.
  • Aggregate complaint feedback from the large mailbox providers reports spam-marking rates above a threshold, with a delay measured in days. It tells you a domain has a reputation problem; it will not tell you which message landed in a spam folder.
  • Verdict headers appear in the received message: Authentication-Results, and provider-specific spam headers. Reading them requires access to the delivered message, which is exactly the thing you do not have for arbitrary recipients.

That last constraint is why a disposable inbox is genuinely useful for diagnostics rather than only for signups: when you control the recipient, you can read the message the receiver actually produced, including the verdict headers, instead of inferring it from the sending side.

What to instrument instead of guessing

Four things, in order of value:

  1. Log the SMTP reply code and the enhanced status code for every attempt. Not just success/failure. A 451 and a 550 mean opposite things for retry logic, and a log line that flattens them teaches nothing.
  2. Log the message identity end to end. One Message-ID that appears in the sending log, the relay log, and (if you have access) the received message is worth more than any amount of retry counting.
  3. Track queue depth and attempt count per message. A message retried eleven times and then abandoned is a failure that a success/failure counter never shows.
  4. Separate "accepted" from "confirmed" in whatever you report. If a status field says delivered when it means accepted, every downstream consumer of that field is being taught something false.

The question that resolves most incidents

When someone says mail did not arrive, the useful first question is not "is the server working". It is which layer. Did our application hand it off? Did the receiving server accept it? Do we have any visibility into what happened after? Almost always the answer to the third is no, and that is the honest end of the investigation, not a prompt to keep reading logs that cannot answer it.

The takeaway

Your log ends at the 250. Name the layers separately, log reply codes and message identity rather than boolean outcomes, treat "accepted" and "delivered" as different words, and be explicit that the inbox layer is only observable when you control the recipient. Which is precisely the case a disposable inbox gives you.

Keep reading

Why AI agents need disposable email addresses to finish a signup

Autonomous coding agents now click through signup forms on their own. The blocker is not the form, it is the inbox they cannot open. Here is how disposable mail closes that loop.

OTP extraction from email: why regex keeps failing and what to parse instead

Pulling a verification code out of a message looks like a regex problem. It is a parsing problem, and the difference shows up the first time a template changes.

The SMTP limits that quietly break your email tests

RFC 5321 puts hard numbers on command lines, local parts, and domains. Test suites violate them constantly, then blame the mail server when delivery fails.