Feature

Email Logs — Reading the Delivery Trail on Every Message

Delivery status, SMTP response codes, bounce classification and timestamps for every email you send. This page also explains how to read them — what a 421 means, why a deferral isn't a failure, and why "delivered" doesn't mean "in the inbox".

What email logs are

Email logs are the per-message record of what happened to each email your system sent: when it was queued, which receiving server accepted or rejected it, the SMTP response code returned, whether it bounced or was deferred, and any opens or clicks afterwards.

The distinction that matters is between sent and arrived. Your application knows it handed a message off. Only the log knows whether Gmail accepted it, whether Microsoft deferred it three times before accepting, or whether it was rejected with a 550 because the address stopped existing eight months ago.

Without logs, a user reporting "I never got the OTP" is unanswerable. With them, it takes about thirty seconds.

Logs vs analytics: different questions

These get conflated, and the difference is worth being precise about.

 Email logsEmail analytics
GranularityOne messageCampaign or period
AnswersWhat happened to this email?How did this campaign perform?
Used byEngineers, supportMarketers
Typical triggerA user reports a problemWeekly review
ContainsSMTP codes, timestamps, server responsesRates, trends, comparisons

Analytics tell you something is wrong. Logs tell you what. A bounce rate rising from 2% to 9% is an analytics observation; discovering that it's entirely one domain returning 554 policy rejections is a log finding. See email analytics for the aggregate side.

SMTP response codes explained

Every delivery attempt ends with a numeric response from the receiving server. The first digit carries the meaning, and it's the single most useful thing to know when reading SMTP logs.

  • 2xx — accepted. The receiving server took the message. 250 is the one you want to see
  • 4xx — transient failure. Try again later. The message stays queued and is retried automatically
  • 5xx — permanent failure. Rejected outright. Retrying will not help and repeated attempts damage your reputation

The codes you'll actually encounter:

CodeMeaningWhat to do
250Accepted for deliveryNothing
421Service unavailable, closing channelBack off — usually rate limiting
450Mailbox unavailable, temporarilyRetried automatically
451Action aborted, local errorOften greylisting or throttling
452Insufficient storageRecipient mailbox full
550Mailbox unavailable / user unknownSuppress permanently
552Storage allocation exceededUsually soft — check context
554Transaction failedOften policy or spam rejection

A note on 554: it is the code that most often indicates a reputation problem rather than a bad address. If 554s cluster around one provider, the message text alongside the code usually names the reason — a blocklist, failed authentication, or content filtering.

Hard bounces, soft bounces and deferrals

Three outcomes that get treated as one thing, with very different implications.

Hard bounce. Permanent. The address doesn't exist, the domain doesn't resolve, or the server rejects it outright — typically a 5xx code. That address must be suppressed and never mailed again. Continuing to send to hard-bounced addresses is one of the fastest ways to damage sender reputation, because mailbox providers read it as a sender who doesn't maintain their list.

Soft bounce. Temporary. Full mailbox, server problem, rate limit — usually 4xx. The message is retried on a schedule. A soft bounce that persists across many attempts eventually converts to a hard bounce.

Deferral. The receiving server asking you to slow down. Also 4xx, and this is the one people misread as failure. A message deferred and delivered twenty minutes later reached the recipient. Occasional deferrals are entirely normal, particularly from Microsoft and during volume ramps.

What matters is the pattern rather than the individual event. A sustained rise in deferrals against one provider is a reputation or volume signal worth acting on; a scattering of them across a large send is just how email works.

Tracing a single message

The most common real use of logs: a customer says an email never arrived, and you need the email trail for that one message.

A per-message timeline in neuMails runs:

  • Queued — accepted by the platform, waiting for a delivery slot
  • Sent — handed to the receiving server, with the SMTP conversation recorded
  • Delivered — the receiving server returned a 2xx acceptance
  • Deferred — a 4xx response, with the code, the message and the retry schedule
  • Bounced — a 5xx response, with classification and the server's stated reason
  • Opened / clicked — if tracking is enabled and the recipient's client loaded images

Search by recipient address, subject, campaign, status or date range. Every entry shows the receiving server's actual response text rather than a generic "failed" label — which is usually where the answer is.

What logs cannot tell you

Worth being straightforward about the limit, because it causes real confusion.

"Delivered" does not mean "in the inbox." It means the receiving mail server accepted the message. What happens next — inbox, promotions tab, spam folder — is decided by the provider's filtering, and that decision is not communicated back over SMTP. No email log from any provider can see past the point of acceptance.

This is why a campaign can show 99% delivery and still perform badly. The mail arrived; nobody saw it.

Closing that gap requires seed list testing — sending to monitored accounts across providers and observing which folder the message lands in. Logs and seed testing answer different halves of the same question.

Open tracking has its own limitation: Apple Mail Privacy Protection pre-fetches images, so a meaningful share of recorded opens never involved a human. Treat opens as directional, and weight clicks instead.

Reading logs when something is wrong

A rough diagnostic order when delivery degrades:

  • Filter by status — separate bounces from deferrals first. They mean different things and mixing them obscures both
  • Group by recipient domain — a problem confined to one provider is a reputation or authentication issue with that provider. A problem across all of them is usually your configuration
  • Read the response text, not just the code. Receiving servers frequently name the reason: a blocklist, a DMARC failure, a rate limit
  • Check the timeline — did this start at a specific hour? Volume spikes and DNS changes both show up as sharp edges
  • Compare against a known-good period before concluding something changed

If the pattern points at authentication, our SPF, DKIM and DMARC wizard will show you whether records are correct and aligned.

Retention, export and API access

  • 10 days of searchable logs on all plans, queryable by recipient, subject, campaign, status or date
  • CSV export for offline analysis and longer archival
  • API access for programmatic retrieval into your own tooling
  • Webhooks pushing delivery, bounce, deferral, open, click and complaint events in real time
  • Extended retention available on request where audit or compliance requirements demand it

If you need history beyond the searchable window, webhooks are the right mechanism: capture events into your own database as they happen rather than relying on retrieval later. That also keeps your suppression state in sync, which matters because your platform suppressing a bounced address doesn't stop your application from queueing another send to it.

Log data is stored on AWS Mumbai (ap-south-1) alongside the rest of your account data. See DPDP compliance for the residency picture, or on-premise deployment where logs must remain inside your own network.

Stop guessing where emails went

Full per-message logs on every plan. Free trial, no credit card required.

Start Free Trial

Frequently Asked Questions

What are email logs?

The per-message record of what happened to each email your system sent — when it was queued, which server accepted or rejected it, the SMTP response code, whether it bounced or was deferred, and any opens or clicks. They're the difference between knowing an email was sent and knowing whether it arrived.

How do logs differ from analytics?

Analytics aggregate: open rate, click rate, bounce rate across a campaign. Logs are per-message: this email to this address at this timestamp got this response. Analytics tell you something is wrong; logs tell you what.

What do SMTP response codes mean?

The first digit carries the meaning. 2xx means accepted. 4xx is transient — try later, and the message is retried. 5xx is permanent — rejected outright, and retrying won't help.

Hard bounce vs soft bounce?

Hard is permanent: the address doesn't exist or is rejected outright, usually 5xx. Suppress it and never mail it again. Soft is temporary — full mailbox, server issue, rate limit, usually 4xx — and is retried automatically.

Should I worry about deferrals?

Not individually. A deferral is a server asking you to slow down, and a message deferred then delivered twenty minutes later reached the recipient. Watch the pattern: a sustained rise against one provider signals a reputation or volume problem.

How long are logs retained?

10 days searchable on all plans, with CSV export for longer archival and API access for retrieval. Extended retention is available on request for audit or compliance requirements.

Can I export logs or reach them via API?

Yes — CSV export and programmatic API access. Webhooks push delivery events into your systems in real time, which is the recommended approach if you need retention beyond the searchable window.

Why does a message show delivered when the recipient says it never arrived?

Delivered means the receiving server accepted it. Where it went next — inbox, promotions, spam — is the provider's filtering decision and isn't reported back over SMTP. Inbox placement testing is what reveals that.