A Deep Dive into a Mailinator SMTP Transaction Log

Did you know that Mailinator provides a detailed SMTP transaction log for all inbound (public and private!) messages?

If you use Mailinator to test email delivery, these logs can help you understand exactly how (and how quickly) your emails are moving from the sending server to the Mailinator inbox.

Here’s why it’s useful:

• Troubleshooting: Pinpoint where and when delivery issues occur.
• Performance Tracking: Track how long it takes from initial connection to final message acceptance.
• Transparency: See SMTP in action—no more “email is a black box” mysteries.

Do you want to understand how (and when) your email was delivered to the system? Obviously, there are a lot of steps to email sending on the side of your Email sender before Mailinator gets involved. But once that Sender opens a socket to our system, the SMTP transaction logs serve as a timeline of every step. 

From the moment the sending server connects to when the mail is stored in the public Mailinator inbox, you can see each command and response, with precise timestamps. If you suspect an email took a particularly long time to deliver, the log is your “smoking gun.”

For instance, if your email typically arrives in under one second, but you see a multi-second or multi-minute gap in the timestamps, you’ll know exactly which step is causing the delay:

• Is it the server greeting?
• The TLS handshake?
• The data upload?
• A final confirmation step?

Armed with logs, you can prove (or disprove) any delay and then use that data to address the underlying cause.

Below is an example transaction log from Mailinator. We’ll annotate each stage:

CopyEdit0ms   SOCKET_OPEN       Connection from: 199.15.224.156
0ms   OUTGOING   -->    220 Mailinator.com ESMTP MailinatorSMTP
68ms  INCOMING   <--    EHLO mta-15-224-156.sparkpostmail.com
68ms  OUTGOING   -->    250-mail.mailinator.com 250-8BITMIME 250-STARTTLS 250 Ok
137ms INCOMING   <--    STARTTLS
137ms OUTGOING   -->    220 Ready to start TLS
280ms TLS_ACTIVE
349ms INCOMING   <--    EHLO mta-15-224-156.sparkpostmail.com
349ms OUTGOING   -->    250-mail.mailinator.com 250-8BITMIME 250-STARTTLS 250 Ok
417ms INCOMING   <--    MAIL FROM:<msprvs1=...@bounces.joesender.com>
417ms OUTGOING   -->    250 Ok
486ms INCOMING   <--    RCPT TO:<joe@mailinator.com>
486ms OUTGOING   -->    250 Ok
554ms INCOMING   <--    DATA
554ms OUTGOING   -->    354 End data with <CR><LF>.<CR><LF>
554ms DATA              [ Data Delivery Starts ]
828ms DATA              [ 125256 data bytes received ]
828ms MSG_SAVED         Public Message Stored: joe-1738839940-013585898
829ms OUTGOING   -->    250 Ok
5897ms INCOMING   <--    QUIT
5897ms OUTGOING   -->    221 Bye
5898ms SOCKET_CLOSED

Key Highlights

1. Socket Open to Message Stored in Under One Second
   Notice that the socket opens at 0ms, and by 828ms, the message is fully received and stored.  This example is actually above average. SMTP is a very chatty protocol so with all the back and forth, typical delivery averages around ~350ms.
2. STARTTLS and Secure Handshake
   At 137ms, the server advertises STARTTLS, and the client takes it up immediately. By 280ms, the connection is fully encrypted, and a second EHLO command is sent to re-negotiate capabilities (which is normal after STARTTLS). This step ensures that the rest of the conversation, including the message data, is encrypted in transit.
3. MAIL FROM and RCPT TO
   The sending server identifies the sender as msprvs1=20132smSlHjAC=bounces-280172-1669@bounces.joesender.com. This is a typical SparkPost-style variable address for tracking bounces. The recipient is <joe@mailinator.com>. Both are accepted with 250 Ok.
4. Data Delivery
   At 554ms, the server says “Go ahead, send the message data” (354 response). About 125 KB of data is received by 828ms, at which point Mailinator confirms the message is saved (250 Ok).
5. Lingering Socket (Why 5898ms?)
   Notice that the QUIT command doesn’t arrive until 5897ms—about 5 seconds after the message was saved. This is not unusual. Many sending servers keep the connection open briefly to see if they have more mail to send through the same connection. Closing and reopening sockets repeatedly is more expensive (in terms of both time and resources) than reusing an existing connection if multiple messages are queued for the same domain.In this particular example, there wasn’t an additional message to send, so after 5 seconds (an idle timeout or final decision by the sender), the client issues QUIT and Mailinator closes the socket at 5898ms.

---

Conclusion

By reviewing the transaction log, you can see:

• Exactly when a message arrived,
• How fast it was processed (in this case, under a second), and
• When the sender decided to drop the connection.

If you ever suspect a delay on your emails, these logs are a goldmine for spotting exactly where the holdup occurred—whether it’s a slow TLS handshake, a large data upload, or a delay between commands.

Pro tip: When diagnosing email delivery issues, always compare logs from the sending side with logs from the receiving side. That way, you can piece together a complete timeline and quickly pinpoint any discrepancies.

And if you’re ever curious about how SMTP works in the real world—this is it! One glance at a transaction log tells you everything you need to know about the journey your email takes before it’s visible in your recipient’s inbox.

Happy emailing, and may your logs always be short and sweet!