SMTP PCAP Analysis

Overview

Simple Mail Transfer Protocol (SMTP, RFC 5321) is how mail clients and servers submit and relay email over TCP. From a PCAP/PCAPNG you can reconstruct each mail transaction command by command—EHLO/HELO negotiation, MAIL FROM and RCPT TO envelope addressing, DATA, and QUIT—and read the numeric reply that answers each one. That turns vague reports of "mail isn't going through" into a precise cause: a rejected recipient, a relay denial, greylisting, an authentication failure, or a server that is throttling the sender. The analyzer parses every command and response and lays them out per session, and it flags STARTTLS so you can verify whether the exchange was actually encrypted in transit.

• What you’ll see: per-session command/response flow (EHLO, MAIL FROM, RCPT TO, DATA, STARTTLS, AUTH, RSET, VRFY, NOOP, QUIT), success replies (220/250/354/235), 4xx transient and 5xx permanent failures highlighted, greylisting retries, and STARTTLS upgrade detection
• Best for: Mail troubleshooting and delivery-failure analysis, NOC troubleshooting, SOC triage, incident response
• Works with: relay on 25/TCP, message submission on 587/TCP, implicit-TLS SMTPS on 465/TCP, and STARTTLS-upgraded sessions

What to look for

• Rejected recipients & relay denials: 550 on a RCPT TO (no such user or relay refused), 553 (mailbox name not allowed), 551 (user not local),
• Transaction failures: 554 (transaction failed, often a blocklisted client or a message refused after DATA),
• Greylisting & transient throttling: a 450/451 followed by a later retry that succeeds; 421 (service not available) and 452 (insufficient storage),
• Authentication problems: 530 (authentication required), 535 (credentials invalid)—repeated 535 across many connections can indicate credential-stuffing,
• Transport security: whether STARTTLS was issued, mail sent before STARTTLS, or a full transaction with no STARTTLS at all (cleartext exposure),
• Protocol/sequence errors: 500/501 (syntax), 502/504 (command or parameter not implemented, e.g. VRFY/EXPN disabled), 503 (bad sequence, such as RCPT before MAIL),
• Envelope tracing: the MAIL FROM return path and each RCPT TO recipient, plus ESMTP parameters such as SIZE= advertised in the EHLO reply.

Capture tips

• Capture the right port for the path you’re debugging: 25/TCP for server-to-server relay, 587/TCP for authenticated submission, 465/TCP for implicit-TLS SMTPS.
• Start the capture before the connection opens so you catch the 220 greeting and the EHLO capability list (including whether STARTTLS is offered).
• To read the dialog, capture a path that is cleartext or STARTTLS; on 465/TCP and after a STARTTLS upgrade the exchange is encrypted and only TLS metadata is visible.
• For intermittent delivery failures, capture across a retry window so a 4xx and the later successful attempt both appear—that pairing is what confirms greylisting.
• Take a paired capture (sending host and mail gateway) to tell a client-side problem from a server-side rejection.
• Use a focused time window that reproduces the issue and stays within the 10 MB demo limit.

Example walkthrough

1. Confirm the connection opened with a 220 Service Ready greeting.
2. Read the EHLO reply (250 multi-line) to see advertised capabilities—STARTTLS, AUTH mechanisms, and SIZE=.
3. Check for a STARTTLS command; if it’s missing and mail still flows, note the cleartext exposure.
4. Follow MAIL FROM then each RCPT TO, reading the reply that answers each recipient (250 accepted, 550/553 rejected).
5. At DATA, confirm the 354 Start Mail Input intermediate reply and the final acceptance (250) or rejection (452/552/554).
6. Isolate any 4xx/5xx failures, correlate 4xx with a later retry to spot greylisting, and browse the parsed SMTP view for the full per-session command/response list to export for the ticket.

SMTP FAQ