Skip to content
Mailwel
Theme
Contents
Playbooks & Diagnostics · updated 2026-10-02

Analyzing SMTP Logs

Decode SMTP logs to spot delivery issues before they become major problems.

When your server hands an email to Gmail or Outlook, the two servers have a short conversation, and your server writes down how it went. That record is the SMTP log. This playbook shows you how to read its reply codes, see where delivery fails, and find the pattern behind a problem.

Why logs come first

SMTP is the set of rules mail servers use to pass email to each other. A dashboard shows totals. The log shows what happened to each email, in the receiving server’s words: accepted, delayed or refused, with the exact code and reason. When delivery gets worse, read the logs before you change anything.

The SMTP conversation

Here is a normal delivery from shop.example to a Gmail user. C: lines come from your server (the client). S: lines come from Gmail’s server.

C: EHLO mail.shop.example
S: 250-mx.google.com at your service
C: MAIL FROM:<orders@shop.example>
S: 250 2.1.0 OK
C: RCPT TO:<alex@gmail.com>
S: 250 2.1.5 OK
C: DATA
S: 354 Go ahead
C: (the headers and body of the email)
C: .
S: 250 2.0.0 OK
  • EHLO: your server says hello and gives its name.
  • MAIL FROM: the address that bounces go back to (the “envelope sender”).
  • RCPT TO: the recipient, one line per recipient.
  • DATA: your server asks to send the email. 354 means “go ahead”.
  • A line with only . ends the email. The final 250 means Gmail accepted it.

“Accepted” means the server took responsibility for the email. It can still go to spam.

Where things go wrong

The step where delivery fails tells you what kind of problem you have.

Connect network and TLS Envelope MAIL FROM, RCPT TO Content DATA, then the email Accepted 250 OK No connection Address refused Email refused IP blocked server down TLS failed unknown address too many recipients relaying denied spam or policy low reputation sending too fast Accepted is not the same as inbox points to IP block or outage points to Mostly your list points to Reputation, content
The step where delivery fails points to the cause.

While connecting, before the conversation starts:

  • Connection refused: the server may be blocking your IP address (the number that identifies your sending server), or it may be down.
  • Connection timed out: an outage, a network problem, or a server ignoring you on purpose.
  • TLS failure: the servers couldn’t agree on encryption. Check your certificate and TLS settings.

At MAIL FROM or RCPT TO, the addresses:

  • 550 5.1.1 user unknown: the address doesn’t exist. This is a hard bounce. Remove it from your list now.
  • 550 5.7.1 relaying denied: this server won’t pass mail on for that domain. You are probably sending to the wrong server.
  • 452 4.5.3 too many recipients: send fewer recipients per connection.

After DATA, when the server has read the email:

  • 550 5.7.1 message rejected: refused for its content, your reputation or a policy. The text usually says which.
  • 421 4.7.0 try again later: often you are sending too fast or your reputation is weak. A 421 can arrive at any step.

Reading a reply code

Every reply has a three-digit code. Most servers then add an enhanced status code (a more precise code in the form class.subject.detail) and a line of text.

550 5.1.1 Recipient address does not exist

550 is the basic code, 5.1.1 is the enhanced code, and the rest is the server’s explanation. The explanation is often the most useful part.

550 5.1.1 Recipient address does not exist Basic code Enhanced code Explanation from the server often names the real cause First digit 2xx Accepted 4xx Try again later 5xx Refused for good Enhanced code: three parts 5 1 1 Class: 5 permanent, 4 temporary Subject: 1 address, 2 mailbox, 7 policy Detail: 1 bad mailbox address
The first digit says whether to retry, the enhanced code says why, and the text gives details.

The basic code

The first digit matters most:

First digit Meaning What your server does
2 Success Moves on
3 Keep going Sends the next part (354 after DATA)
4 Temporary failure Keeps the email and retries later
5 Permanent failure Gives up and reports a bounce

The second digit gives the area: x0x syntax, x1x information, x2x the connection, x5x the mail system. The third narrows it down. 550 (mailbox unavailable or action refused) is the most common rejection and covers many reasons. You’ll also see 551 (user not local), 552 (mailbox over its limit), 553 (mailbox name not allowed) and 554 (transaction failed).

The enhanced code

  • Class: 2 success, 4 temporary, 5 permanent. It matches the first digit of the basic code.
  • Subject: 1 address, 2 mailbox, 3 mail system, 4 network and routing, 5 mail protocol, 6 content, 7 security and policy.
  • Detail: the specific reason.

So 5.7.1 reads: permanent, security or policy, delivery not authorised. Common codes:

Code Meaning
5.1.1 The address doesn’t exist
5.1.2 The domain doesn’t exist or can’t receive mail
5.2.1 The mailbox is disabled
4.2.2 or 5.2.2 The mailbox is full
5.4.4 No route to the domain’s mail server
5.7.1 Refused for policy or reputation reasons
5.7.26 Authentication failed (Gmail uses it for SPF, DKIM and DMARC)
4.7.0 Temporary policy refusal, often rate limiting
4.4.2 The connection dropped during delivery

What the big providers say

[IP] stands for your server’s IP address. Gmail splits long replies over several lines: a dash after the code (421-) means more lines follow.

Gmail

421-4.7.28 Our system has detected an unusual rate of unsolicited mail
originating from your IP address. ... temporarily rate limited.

Mail from your IP looks like spam. Send less, and check for a hacked account or a bad list.

550-5.7.1 Our system has detected that this message is likely
unsolicited mail. ... this message has been blocked.

Refused as spam. Check your spam rate in Google Postmaster Tools (Google’s free dashboard for senders) and the complaints from recent campaigns.

550-5.7.26 This message does not have authentication information or
fails to pass authentication checks (SPF or DKIM). ...

Authentication failed. SPF (a DNS record listing the servers allowed to send for your domain), DKIM (a signature proving the email came from your domain) or DMARC (your policy for failed checks) isn’t passing. Find which with the DNS lookup and header analyzer.

550-5.1.1 The email account that you tried to reach does not exist.

A hard bounce. Remove the address.

Microsoft (Outlook.com, Hotmail, Live)

550 5.7.1 Unfortunately, messages from [IP] weren't sent. ... part of
their network is on our block list (S3140).

Your IP is on Microsoft’s own blocklist. Fix the cause, then ask for removal through Microsoft’s sender support form.

451 4.7.650 The mail server [IP] has been temporarily rate limited
due to IP reputation.

Send less to Microsoft and check SNDS (Microsoft’s free dashboard for your IPs).

Yahoo

553 5.7.1 [BL21] Connections will not be accepted from [IP],
because the ip is in Spamhaus's list

Your IP is on a Spamhaus blocklist. Fix the cause, then request removal from Spamhaus.

421 4.7.0 [TSS04] Messages from [IP] temporarily deferred due to
unexpected volume or user complaints

Your volume jumped or people complained. Send to Yahoo more slowly and check complaints.

Finding the pattern

One rejection tells you little. A pattern across many tells you the cause.

Three numbers

Count each email once, by what finally happened to it:

Delivery rate = emails accepted (250)               ÷ emails sent
Bounce rate   = emails refused (5xx)                ÷ emails sent
Deferral rate = emails that got a 4xx at least once ÷ emails sent

Step by step

  1. Export the logs for the period in question.
  2. Keep only replies that are not 2xx.
  3. Group by receiving domain. If one provider refuses you, the problem is your reputation there.
  4. Group by code. Mostly 5.1.1 means dead addresses on your list. Mostly 5.7.1 means reputation or policy.
  5. Group by IP and by sending domain. One may be blocklisted or have broken authentication.
  6. Check the timing. A sudden spike points to one event: a campaign, a blocklisting, a DNS change.
  7. Compare with your recent changes, and write down what you find.

Testing a server with the SMTP probe

Mailwel’s SMTP probe checks a domain’s mail server. Enter a domain such as example.com. It looks up the MX records (DNS records naming the servers that receive the domain’s email), connects, and shows the server’s greeting and features, such as STARTTLS encryption. It also checks whether the server accepts mail for any address (a “catch-all”).

Use it when mail to one domain fails, or after you change MX records. The probe connects from Mailwel’s servers, not yours, so it can’t tell you whether that server blocks your IP. Your logs answer that.

Common patterns

What the logs show Likely cause
Many 550 5.1.1 everywhere, then blocklist refusals days later An old or bought list. Spam traps (addresses that exist to catch bad lists) don’t bounce, so the blocklisting is often the first sign.
5.7.1 naming a blocklist, at most providers at once Your IP or domain is blocklisted
5.7.26 or text about SPF or DKIM failing Broken authentication
421 or 451 “rate limited” at one provider after a volume jump Sending too fast for that provider
Timeouts or 421 at one provider while others work An outage at that provider

Checklist

  • Read the logs before you change anything.
  • 4xx means wait and watch. 5xx means act.
  • Read the enhanced code and the text, not just the three digits.
  • Remove addresses that return 5.1.1 straight away.
  • Group failures by provider, code, time, IP and domain.
  • For blocks, follow the block bounce playbook. For delays, follow the soft bounce playbook.