InboxRatio
Check your domain

Glossary term

What is SMTP? The protocol that moves every email

What SMTP is

SMTP — Simple Mail Transfer Protocol — is the standard that moves email between servers. When you press send, your message does not travel to the recipient in one hop. It passes through a chain of SMTP conversations: your mail client or sending platform hands the message to a submission server, that server looks up where the recipient's mail lives, connects to it, and negotiates the handover line by line in plain text.

The protocol dates back to the earliest days of the internet and is defined today in RFC 5321. Almost nothing about its core grammar has changed since. That longevity is the point: any mail server on earth can talk to any other because they all speak the same few verbs.

SMTP handles transfer only. It does not store your mailbox, it does not decide what folder a message lands in, and it has no built-in way to prove the sender is who they claim to be. That last omission is the one deliverability lives with: everything the industry has bolted on since — SPF, DKIM, DMARC — exists to patch it.

How SMTP differs from IMAP and POP3

The three protocols get lumped together in email client settings, which causes endless confusion. The split is simple: SMTP sends, IMAP and POP3 retrieve.

SMTP carries a message from the sender's infrastructure to the recipient's mail server. Its job ends the moment the receiving server says "250 OK" and takes custody. What happens next — spam filtering, folder assignment, storage — is the receiving system's business, and SMTP has no visibility into it.

IMAP and POP3 operate on the other side of that wall. They let a mail client read messages that have already been delivered to a mailbox. IMAP keeps mail on the server and synchronizes state across devices; POP3 downloads and usually deletes. Neither can send anything.

One practical consequence: an ESP's "SMTP relay" product and your mailbox provider's SMTP submission port do the same fundamental job at different scales. Both accept mail from you and take responsibility for onward delivery. The difference is who answers for the sending reputation afterward.

How SMTP works

An SMTP session is a scripted dialogue. Here is a minimal, real-shaped exchange between a sending server and a receiving one:

S: 220 mx.example.org ESMTP ready
C: EHLO mail.sender-domain.com
S: 250-mx.example.org
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: MAIL FROM:<bounces@sender-domain.com>
S: 250 OK
C: RCPT TO:<person@example.org>
S: 250 OK
C: DATA
S: 354 End data with <CRLF>.<CRLF>
C: (headers and body)
C: .
S: 250 OK: queued as 4F1A2B

A few load-bearing details hide in that transcript.

The envelope is not the message. The address in MAIL FROM — the envelope sender, also called the return-path — is separate from the From: header the recipient sees. Bounces go to the envelope sender, and SPF is evaluated against it, not against the visible From. Most ESPs set the envelope sender to their own bounce domain unless you configure a custom one, which is why SPF alignment under DMARC fails by default on many platforms.

Port matters. Port 25 is server-to-server relay. Port 587 is message submission — the authenticated channel a client or application uses to hand mail to its own provider, defined separately in RFC 6409. Port 465 carries submission over implicit TLS. Residential ISPs and most cloud providers block outbound port 25 precisely because open relay from consumer machines was the spam engine of an earlier era.

Finding the destination is DNS work. Before connecting, the sending server queries the recipient domain's MX records to learn which hosts accept its mail and in what priority order. A quick MX lookup shows you exactly what any sender sees when it tries to deliver to your domain.

Encryption is opportunistic. STARTTLS (RFC 3207) upgrades the plain-text session to an encrypted one, but only if both sides support it. If the receiving server doesn't offer it, classic SMTP proceeds unencrypted rather than failing.

Every hop leaves a trace. Each server that relays the message prepends a Received: header. Reading them bottom-to-top reconstructs the delivery path, which makes an email header analyzer the fastest way to see where a message actually traveled and where it was delayed.

SMTP and your deliverability

SMTP response codes are the first honest signal in the entire delivery chain, and most senders never look at them.

A 5xx code is a permanent rejection. 550 5.1.1 User unknown means the address does not exist — a hard bounce. Repeatedly sending to addresses that return 5xx is one of the fastest ways to signal to a mailbox provider that you do not maintain your list.

A 4xx code is a temporary deferral: try again later. Receivers use 4xx codes deliberately as a filtering tool. Greylisting rejects the first delivery attempt from an unknown sender on the assumption that real mail servers retry and spam cannons do not. Reputation-based throttling works the same way — a provider that distrusts your IP will defer your mail with codes like 421 4.7.0 Try again later rather than reject it outright.

Here is the uncomfortable part: "250 OK" does not mean delivered to the inbox. It means the receiving server accepted custody. The message can still be filed to spam, quarantined, or discarded without any further notice to you. This gap between acceptance and placement is exactly why our deliverability testing measures where messages actually land on a seed list instead of trusting send-time success rates. A platform reporting a clean delivery rate is reporting 250 OKs, nothing more.

The envelope mechanics matter too. Because SPF checks the MAIL FROM domain, and DMARC requires that domain (or the DKIM signing domain) to align with the visible From, decisions made at the SMTP layer — which bounce domain your platform uses, whether you configured a custom return-path — directly determine whether your authentication passes.

Limitations and failure modes

SMTP's failure modes are mostly consequences of its trusting design.

No sender verification. The protocol accepts whatever MAIL FROM and From: values the client asserts. Spoofing is not an attack on SMTP; it is SMTP working as specified. SPF, DKIM and DMARC exist as external corrections, and a domain without them is exactly as forgeable today as in 1982.

Silent loss after acceptance. A receiver that accepts a message takes on a duty to deliver or bounce it, but heavily filtered mail streams sometimes see messages accepted and then dropped by internal policy with no bounce. From the sender's side this is invisible: the log says 250 OK, the recipient has nothing. Seed-list testing is the only way to detect it.

Retry ambiguity. The standard expects senders to retry after 4xx for hours or days, but retry schedules are implementation choices. A sending platform with an aggressive give-up policy converts routine greylisting into permanent non-delivery. If a provider's bounce logs show unusual numbers of "timed out" or "deferred, gave up" entries, this is where to look.

Plain-text fallback. Opportunistic TLS means a downgrade is silent. Unless the receiving domain enforces a stricter policy, mail to it can travel unencrypted and nothing warns either party.

Port 25 blocking. Applications that try to speak SMTP directly from cloud instances usually find that their provider blocks outbound 25. This is by design; the answer is authenticated submission through port 587 to a relay with a managed reputation, not a support ticket asking to unblock the port.

Related terms

MX record, SPF record, DKIM, DMARC, hard bounce, soft bounce, greylisting, inbox placement, sender reputation.

Frequently asked questions

Is SMTP still used today? Yes — universally. Every email between two different providers crosses at least one SMTP session. Proprietary APIs offered by sending platforms replace the submission step only; delivery to the recipient's server is always SMTP.

What port should I use for sending email? Use 587 with STARTTLS (or 465 with implicit TLS) for authenticated submission to your provider. Port 25 is for server-to-server relay and is blocked outbound by most ISPs and cloud hosts.

Does an SMTP "250 OK" mean my email reached the inbox? No. It means the receiving server accepted the message. Spam filtering and folder placement happen after acceptance, and a message can be junked or silently discarded post-250. Placement can only be verified by checking real mailboxes.

What is the difference between SMTP and an email API? Both hand your message to a sending platform. SMTP is the standard protocol and works with any mail-capable software; an HTTP API is proprietary but typically returns richer per-message status. After the handoff, both deliver onward over SMTP.

Why do bounces go to a different address than my From address? Bounces return to the envelope sender (MAIL FROM), which is set during the SMTP session and is usually your platform's bounce domain. This separation is deliberate — it routes delivery failures to the system that can process them.

What is the difference between SMTP relay and SMTP submission? Submission (port 587) is you handing mail to your own provider, with authentication. Relay (port 25) is that provider passing it to the recipient's server. Same protocol grammar, different trust relationships.

Understand the envelope and the response codes and most "mysterious" delivery behavior stops being mysterious. Start by checking what receivers see when they resolve your domain with the email DNS check.

Sources