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.
SMTP Flow Simulator
Watch a message move from application code to an SMTP relay, through TLS and AUTH, across DNS and recipient MX checks, and finally into a mailbox.
// active trace
Successful transactional email
App
SMTP relay
DNS auth
Recipient MX
Mailbox
C: TCP connect smtp.example.net:587
S: 220 smtpfast ESMTP ready
App
Open submission connection
Apps usually submit mail to a provider over port 587. Port 25 is mostly for server-to-server relay.
// protocol note
The server greeting starts every SMTP session.
1/9
Steps seen
42ms
Trace time
Sender IP allowed by domain policy
Message signed with domain key
Visible From aligns with SPF or DKIM
The server accepted the command or took responsibility for the message.
Temporary failure. A relay should queue the message and retry with backoff.
The attempt should stop until the sender, recipient, or credentials are fixed.
SMTPfast handles transactional and marketing email with SMTP/API sending, logs, webhooks, and embeddable signup forms.
Try SMTPfastAbout 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, the receiving side checks the sender identity with SPF, DKIM and DMARC, the relay looks up the recipient MX record and hands the message over, and 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
Bounce Triage Simulator
Read a real SMTP bounce and decide what it is and what to do about it. Twelve genuine failures from Gmail, Outlook, Postfix and Proofpoint: hard bounces, soft bounces, content blocks, rate limits and spam complaints. Learn why the 4xx and 5xx class digit is a hint rather than the answer, which bounces to suppress permanently, which to retry, and what each mistake costs you in lost subscribers or lost sending reputation.
// simulator
DNS Resolution Simulator
Learn how DNS works with an interactive step-by-step simulator. Visualize the DNS hierarchy, understand caching at different levels, and see the difference between recursive and iterative queries.
// simulator
Kubernetes Networking / CNI Simulator
Visualize Kubernetes networking and CNI packet paths with an interactive simulator. Learn Pod-to-Pod routing, same-node and cross-node traffic, ClusterIP Services, EndpointSlices, headless Services, LoadBalancer, NodePort, kube-proxy, eBPF service routing, Ingress, NetworkPolicy, and internet egress.