Analyzing SMTP Logs
Why SMTP Logs Matter
SMTP logs are the ground truth of email delivery. While dashboards show aggregated metrics, SMTP logs show exactly what happened to each message: the conversation between your sending server and the receiving server, word for word.
When deliverability drops, SMTP logs are the first place to look. They tell you:
- Whether the receiving server accepted, deferred, or rejected each message
- The exact error code and diagnostic message returned
- Whether the failure was temporary (retry) or permanent (bounce)
- Which specific policy or reputation check caused the failure
The SMTP Conversation
Every email delivery follows a structured SMTP dialogue:
Sending Server → EHLO mail.yourdomain.com
Receiving Server ← 250-mx.google.com Hello
Sending Server → MAIL FROM:<sender@yourdomain.com>
Receiving Server ← 250 OK
Sending Server → RCPT TO:<recipient@gmail.com>
Receiving Server ← 250 OK
Sending Server → DATA
Receiving Server ← 354 Start mail input
Sending Server → [message headers and body]
Sending Server → .
Receiving Server ← 250 2.0.0 OK [message ID]
Each step in this conversation is logged. Failures can occur at any step, and the step where the failure occurs tells you what kind of problem you’re facing.
Connection-Level Failures
Failures before the SMTP conversation begins:
- Connection refused (TCP RST): The receiving server isn’t accepting connections from your IP at all. Check if your IP is blocklisted.
- Connection timeout: The receiving server didn’t respond within the timeout period. May indicate temporary server issues or deliberate throttling.
- TLS handshake failure: Encryption negotiation failed. Check your TLS certificate and cipher compatibility.
Envelope-Level Failures
Failures during MAIL FROM or RCPT TO:
- 550 5.1.1 User unknown: The recipient address doesn’t exist. This is a hard bounce — suppress immediately.
- 550 5.7.1 Relaying denied: You’re trying to send through a server that doesn’t accept relay for that domain.
- 452 4.5.3 Too many recipients: You’ve exceeded the per-session recipient limit. Split into smaller batches.
Data-Level Failures
Failures after DATA, when the message content is evaluated:
- 550 5.7.1 Message rejected: Content, reputation, or policy failure. The diagnostic text usually explains why.
- 421 4.7.0 Try again later: Temporary deferral due to rate limiting, reputation, or server load.
Understanding Response Codes
The Three-Digit Code Structure
SMTP response codes follow a standard structure:
First digit — Category:
| Code | Meaning | Action |
|---|---|---|
| 2xx | Success | Message accepted |
| 4xx | Temporary failure | Retry later |
| 5xx | Permanent failure | Do not retry |
Second digit — Subject:
| Code | Subject |
|---|---|
| x0x | Syntax |
| x1x | Information |
| x2x | Connection |
| x5x | Mail system |
| x7x | Security/policy |
Third digit — Detail: Specific to the context. For example:
- 550 = Transaction failed (permanent)
- 551 = User not local
- 552 = Exceeded storage allocation
- 553 = Mailbox name not allowed
- 554 = Transaction failed (general)
Enhanced Status Codes
Modern SMTP servers include enhanced status codes after the basic three-digit code:
550 5.7.1 [host] Our system has detected that this message is likely spam.
The enhanced code 5.7.1 breaks down as:
- 5 = Permanent failure
- 7 = Security/policy related
- 1 = Delivery not authorized, message refused
Common enhanced status codes:
| Enhanced Code | Meaning |
|---|---|
| 5.1.1 | Bad destination mailbox address (user doesn’t exist) |
| 5.1.2 | Bad destination system address (domain doesn’t exist) |
| 5.2.1 | Mailbox disabled |
| 5.2.2 | Mailbox full |
| 5.4.4 | Unable to route |
| 5.7.1 | Delivery not authorized (policy rejection) |
| 5.7.26 | Authentication failure (DMARC, SPF) |
| 4.7.0 | Temporary failure — rate limiting or reputation |
| 4.4.2 | Connection dropped during transmission |
Provider-Specific Diagnostic Messages
Gmail
Gmail includes detailed diagnostic text that reveals the reason for rejection:
Reputation-based blocks:
421-4.7.28 [IP] Our system has detected an unusual rate of
unsolicited mail originating from your IP address. To protect our
users from spam, mail sent from your IP address has been temporarily
rate limited.
Action: Reduce sending volume. Check for compromised accounts or list quality issues.
550-5.7.1 [domain] Our system has detected that this message is
likely unsolicited mail. To reduce the amount of spam sent to Gmail,
this message has been blocked.
Action: Check Google Postmaster Tools for domain reputation. Review recent campaigns for high complaint rates.
Authentication failures:
550-5.7.26 This message does not have authentication information or
fails to pass authentication checks (SPF or DKIM). To best protect
our users from spam, the message has been blocked.
Action: Verify SPF includes your sending IPs. Verify DKIM signatures are valid. Check DMARC alignment.
Recipient issues:
550-5.1.1 The email account that you tried to reach does not exist.
Action: Hard bounce. Suppress this address immediately.
Microsoft (Outlook.com, Hotmail, Live)
Microsoft uses numeric error codes in their diagnostic messages:
550 5.7.1 Unfortunately, messages from [IP] weren't sent. Please
contact your Internet service provider since part of their network
is on our block list (S3140).
Action: Check if IP is on Microsoft’s internal blocklist. Submit a delist request through Microsoft’s sender support form.
421 4.7.0 [host] Messages from [IP] temporarily deferred due
to user complaints - [reference ID]; see
https://postmaster.live.com/snds/
Action: Reduce sending volume to Microsoft. Check SNDS for complaint data. Investigate recent campaign complaint rates.
Yahoo
553 5.7.1 [BL21] Connections will not be accepted from [IP],
because the ip is in Spamhaus's list
Action: Check Spamhaus. Fix the root cause. Request delisting.
421 4.7.0 [TSS04] Messages from [IP] temporarily deferred due to
unexpected volume or user complaints
Action: Throttle sending to Yahoo. Review recent complaint trends.
Log Analysis Techniques
Calculating Key Metrics from Logs
Delivery rate:
Delivery Rate = (2xx responses at DATA) / (Total RCPT TO attempts) × 100
Bounce rate:
Hard Bounce Rate = (5xx responses) / (Total RCPT TO attempts) × 100
Soft Bounce Rate = (4xx responses) / (Total RCPT TO attempts) × 100
Deferral rate:
Deferral Rate = (4xx responses at connection or DATA) / (Total attempts) × 100
Pattern Analysis
When analyzing logs for deliverability issues, look for patterns:
By provider: Group failures by receiving domain. Is one provider rejecting at a higher rate than others? Provider-specific problems indicate provider-specific reputation issues.
By time: Chart failures over time. Did rejections spike on a specific date? That correlates with a specific event — a bad campaign, a blocklist inclusion, or an authentication change.
By error code: Group all rejections by the 3-digit or enhanced status code. If 80% of rejections are 550 5.1.1 (user unknown), you have a list quality problem. If 80% are 550 5.7.1 (policy rejection), you have a reputation problem.
By IP address: If you send from multiple IPs, compare rejection rates per IP. One IP may have worse reputation than others — possibly due to uneven traffic distribution or a blocklist affecting only that IP.
By sending domain: If you use multiple sending domains, compare rejection rates per domain. Authentication issues may affect one domain but not others.
Sample Log Analysis Workflow
- Export logs for the time period in question
- Filter for non-2xx responses to isolate failures
- Group by receiving domain to identify provider-specific issues
- Group by error code to categorize failure types
- Look for temporal patterns (sudden spikes vs. gradual increases)
- Cross-reference with recent changes (new campaigns, infrastructure changes, DNS modifications)
- Document findings and remediation steps
Using Mailwel’s SMTP Probe
Mailwel’s SMTP Probe tool performs a real-time SMTP connection test to any mail server:
What it tests:
- TCP connectivity to the target MX server
- SMTP banner response
- EHLO capabilities (TLS, authentication methods, size limits)
- MX record resolution and priority ordering
When to use it:
- Diagnosing delivery failures to a specific domain
- Verifying that a provider’s mail server is reachable from your infrastructure
- Checking MX configuration after DNS changes
- Testing whether a specific IP can connect to a specific provider
Interpreting probe results:
- Connection success + normal banner: Server is reachable and functional
- Connection refused: IP may be blocked at the network level
- Connection timeout: Network issue or deliberate blackholing of your IP
- Banner with warning: Some servers include reputation warnings in the SMTP banner
Common Scenarios and Log Signatures
Scenario: Purchased list mailing
Log signature: High rate of 550 5.1.1 (user unknown) across all providers
Plus: 550 5.7.1 with spam trap language from Spamhaus-aware providers
Scenario: IP blocklist inclusion
Log signature: 550 5.7.1 referencing blocklist name
Affects: All or most providers simultaneously
Scenario: Authentication misconfiguration
Log signature: 550 5.7.26 or SPF/DKIM failure messages
Affects: Providers enforcing DMARC (Gmail, Yahoo primarily)
Scenario: Volume spike throttling
Log signature: 421 4.7.0 "temporarily deferred" with rate limit language
Affects: Individual providers that detect the volume change
Scenario: Mailbox provider outage
Log signature: 421 4.0.0 or connection timeouts at one specific provider
Affects: Only one provider; others deliver normally
SMTP logs are the most objective evidence available for diagnosing deliverability issues. They capture the actual server-to-server conversation without interpretation or aggregation. Building the habit of checking logs first — before guessing, before changing things — saves time and prevents misdiagnosis.