SMTP Flow Simulator
Visualize how SMTP email delivery works from app submission through EHLO, STARTTLS, AUTH, MAIL FROM, RCPT TO, DATA, SPF, DKIM, DMARC, recipient MX relay, temporary failures and retries, auth failures, and inbox placement. Sponsored by SMTPfast.
Category: Networking
Topics covered: smtp, email, deliverability, spf, dkim, dmarc, dns, networking, educational, interactive
// simulator
SMTP Flow Simulator
Visualize how SMTP email delivery works from app submission through EHLO, STARTTLS, AUTH, MAIL FROM, RCPT TO, DATA, SPF, DKIM, DMARC, recipient MX relay, temporary failures and retries, auth failures, and inbox placement. Sponsored by SMTPfast.
Open submission connection
AcceptedGoal: Send one email all the way to 250 OK. Press Play, or Next through each step, on the successful scenario until 250 OK.
Successful transactional email, step 1 of 9: Open submission connection. 220 smtpfast ESMTP ready
Open submission connection
1/9 · 42msApps usually submit mail to a provider over port 587. Port 25 is mostly for server-to-server relay.
The server greeting starts every SMTP session.
Client
C: TCP connect smtp.example.net:587
Server
S: 220 smtpfast ESMTP ready
About this SMTP simulator
What you'll learn
- How SMTP submission differs from server-to-server relay
- Why EHLO, STARTTLS, AUTH, MAIL FROM, RCPT TO, and DATA happen in order
- How SPF, DKIM, and DMARC affect sender trust and deliverability
- Why 4xx SMTP responses retry while 5xx responses usually fail permanently
- Where provider queues, logs, webhooks, and bounce handling fit into delivery
Key concepts covered
- Submission: authenticated app-to-relay sending, usually on port 587
- Relay: queued delivery from sender relay to recipient MX
- Authentication: TLS, SMTP AUTH, SPF, DKIM, and DMARC
- Delivery: remote acceptance, retry, bounce, and mailbox placement
Sponsored by SMTPfast
SMTPfast is a developer-first email platform for transactional and marketing email. It provides SMTP/API sending, detailed logs, webhooks, and embeddable signup forms for teams that want to ship email without running their own mail infrastructure.
Overview
Sending an email from an application is a conversation between servers, and most delivery problems happen at a specific step of it. This simulator follows a message from your app through an SMTP relay to the recipient mail server and into the mailbox. In the successful scenario you watch the client open a submission connection, discover the server extensions with EHLO, upgrade to an encrypted connection with STARTTLS, authenticate, send the envelope sender and recipient, and stream the headers and body. The relay signs the message with DKIM, looks up the recipient MX record and hands the message over, and the receiving server checks SPF, DKIM and DMARC before it lands in the inbox. Two more scenarios show what goes wrong. In greylisting, the remote server asks for a retry, the relay queues the message and tries again with backoff, and the second attempt is accepted. In an authentication failure, a bad credential is rejected at submission and the message is never accepted at all. Each step shows whether the result is accepted, retry later or a permanent failure.
Try this
- Play "Successful transactional email" and follow the message from the app to the mailbox, step by step.
- Switch to "Temporary greylisting retry" and watch the relay queue the message and retry with backoff.
- Run "Authentication failure" to see a bad credential stop the message before it is ever queued.
Frequently asked questions
- What is the difference between ports 25, 587 and 465?
- Port 25 is used between mail servers. Port 587 is for clients submitting mail, starting in plain text and upgrading with STARTTLS. Port 465 is submission over implicit TLS, encrypted from the first byte.
- What do SPF, DKIM and DMARC do?
- SPF lists the servers allowed to send for a domain, DKIM adds a cryptographic signature to each message, and DMARC tells receivers what to do when neither SPF nor DKIM passes in alignment with the visible From domain.
- What is greylisting?
- A spam defense where the receiving server temporarily rejects mail from an unknown sender with a 4xx code. A legitimate server retries later and is accepted, while many spam senders never retry.
Try next
// simulator
Email Authentication Lab: SPF, DKIM and DMARC
Publish SPF, DKIM and DMARC records, send mail directly and through a forwarder or mailing list, and inspect the receiver’s authentication verdict, alignment and disposition.
// simulator
HTTP/1.1 vs HTTP/2 vs HTTP/3 Lab
Load one page over HTTP/1.1, HTTP/2, and HTTP/3. Compare connection setup, multiplexed streams, TCP head-of-line blocking, and QUIC loss recovery in a request waterfall.
// simulator
CDN Edge Cache Lab
Set HTTP cache headers, send traffic through Frankfurt, Virginia and Singapore CDN edges, deploy, purge and inspect shared-cache hits, misses and 304 revalidation.