What is SMTP? How email actually gets delivered

Accepted is not the same as in the inbox#

Every SMTP handover ends with a three-digit reply from the receiving server, and the one that matters most is 250: the server has accepted responsibility for the message. It has not put it in the inbox.^[1] Filtering happens after that reply, and SMTP never reports the folder. That is how a log can say “delivered” while the customer sees nothing.

The sender finds the receiving server through DNS. An MX record (mail exchanger) is the line in a domain’s DNS that names the server accepting its mail: for ana@example.net, the sender looks up example.net’s MX record and connects to the server it names.^[1]

A separate standard defines the message’s From, To and Subject lines.^[2] Between servers, SMTP checks nothing about who the sender claims to be (only the first handover, from your app, asks for a login), and its specification calls SMTP mail “inherently insecure”.^[1][3] The sender checks that make up for it (SPF, DKIM and DMARC) are covered below.

How an email travels: submission, relay, delivery#

A message usually crosses two or more SMTP handovers, and each has its own rules. Think of four steps: two handovers, then filing, then reading.

1. Submission. Your mail app, or your application’s code, logs in to its own outgoing server and hands over the new message. That server may fix small things, such as adding a missing Date line or Message-ID (the message’s unique reference).^[3]
2. Relay. The outgoing server looks up each recipient domain’s MX record and connects to that server.^[1]
3. Delivery. The server that took the relay’s handover holds the recipient’s mailbox: it runs its filters and files the message in the inbox, the spam folder or a tab.
4. Retrieval. The recipient’s mail app fetches it with IMAP or POP3.

At each handover, the 250 moves responsibility to the receiver: it now has to deliver the message, retry it, or send a failure notice back to the sender.^[1] Every server also adds a Received: line to the top of the message, which is how you trace the route later.^[1]

Where the spam filter runs#

At the receiving end, in two places. During the conversation it can refuse the sender, a recipient or the message with a 5xx reply, and you get a bounce. After its 250, it scores the message and picks a folder, with no reply at all. (That is practice, not the standard.) So SMTP can tell you a message was refused, never that it went to spam; staying out of spam is a separate job, covered in why are my emails going to spam?

SMTP vs IMAP vs POP3#

Ports are from each protocol’s specification.^[4][5][6] If you read one mailbox on a phone and a laptop, you want IMAP. Locking IMAP and POP3 down on your own server is further down.

SMTP ports: 25, 465 and 587#

The three ports separate two jobs: relay, which is servers passing mail to each other, and submission, which is an app handing a new message to its own outgoing server. When a tool asks for SMTP settings, it wants a submission port. A port is a numbered door on a server, one per kind of traffic. Two more terms: TLS is the encryption behind https; STARTTLS means the connection starts unencrypted and switches to TLS, while implicit TLS means it is encrypted from the first byte.

Port 25 is where a domain’s MX server listens,^[1] and it has to be 25 because an MX record “has no way to specify a port”.^[6] Some networks block outbound port 25 to stop infected computers sending spam,^[7] so if an app cannot connect out on 25, it should be submitting instead.

Port 587 is reserved “for email message submission”, and the server must by default refuse mail from a session that has not logged in.^[3] “They must not be open relays”: servers that pass on mail from anyone, to anywhere, without a login.^[7]

Port 465 starts encrypted: “a TLS handshake begins immediately”. An early registration was revoked, which is why old guides call it deprecated; RFC 8314 registered it again in 2018 and prefers it to STARTTLS, so those guides are out of date.^[6] There is “no significant difference” in security between 465 and 587 when both sides insist on TLS.^[6]

What goes in each box of an “SMTP settings” form#

The provider can be your mailbox host or an email service provider (a sending service): a company whose servers send mail for your website or app, keep the retry queue, process bounces and look after the sending servers’ reputation. A small business usually needs hosting first, for the mailboxes people write from, and adds a sending service once software sends for it: shop orders, password resets, a contact form or a newsletter. Many end up with both, on the same domain. What to look for in one is in what is an email service provider?

Check your mailbox host’s rules before you set up a printer or scanner with your own address and password. Microsoft has announced it will retire password-only (“Basic”) logins for SMTP in Exchange Online,^[24] so a device that knows only a username and password needs another route there, such as a sending service that takes an API key.

SMTP reply codes: what 2xx, 4xx and 5xx mean#

The first digit of every reply tells the sender what to do next.^[1]

A reply is 4xx if the same command could succeed later “without any change in command form or in properties of the sender or receiver”; a 5xx will fail again if repeated unchanged.^[1] The sender should wait at least 30 minutes between retries and keep trying for at least 4–5 days before giving up,^[1] so a 4xx can delay a message by hours without losing it.

Many servers add an enhanced status code after the three digits, and its middle number says what kind of problem it is: x.1.x the address (5.1.1, no such mailbox), x.2.x the mailbox (x.2.2, full), and x.7.x security or policy (5.7.1, delivery not authorised).^[13] A 5.7.x is a policy refusal. It can be about your sending (authentication, reputation, volume) or the recipient’s own rule, such as a mailbox that takes only internal mail, and the text after the code says which.^[13]

The Gmail lines are from Google’s list of its codes;^[21] 530 and 535 are from the login extension^[9] and the size refusal from the size extension.^[12] A full mailbox can come back as a 5xx, but its x.2.2 is a condition the recipient can clear.^[13] Greylisting refuses an unfamiliar sender with a temporary code until it retries after a delay, because real servers retry and most spam software does not.^[22] How replies become hard and soft bounces is in hard bounce vs soft bounce.

When an email did not arrive, the last reply in your sending service’s log says which of these cases you are in. Tracing it from there, step by step, is in emails not being delivered.

The envelope and the message are different things#

Think of a paper letter: the post office reads the envelope, the reader reads the letter inside. SMTP works the same way: it carries a mail object that “contains an envelope and content”. The envelope is two commands: MAIL FROM, the address “to which error reports should be directed”, and one RCPT TO per recipient. The content is the message itself, header lines and body.^[1]

The two do not have to agree. The From: line the reader sees is in the content,^[2] while the envelope sender (also called the bounce address or return path) is often an address at the sending service. The envelope recipients decide where it goes, whatever To: says: that is how Bcc works, and how a forged From gets through. You can see the envelope sender afterwards: the receiving server records it in a Return-Path: line at the top of the delivered message.^[1]

Why the bounce address should be on your own domain is in custom return path, explained.

Where SPF, DKIM and DMARC plug into SMTP#

Three DNS-based standards check the sender from outside SMTP. In plain words:

• SPF is a list, in your DNS, of the servers allowed to send for your domain. The receiver compares the connecting server with the list published by the bounce address’s domain (the envelope sender, above).^[18] It needs only the envelope, so it can run before the message arrives; many receivers run it afterwards.
• DKIM is a signature inside the message, which the receiver checks with a key the signer publishes in its DNS once the message has arrived.^[19] It survives forwarding as long as nobody edits the signed parts; SPF usually fails on forwarded mail.
• DMARC asks whether SPF or DKIM passed for the domain in the From: line, or by default one in the same organisation such as a subdomain (that match is called alignment), and lets that domain’s owner ask receivers to quarantine or reject mail that fails.^[20]

If you send from your own domain, set all three up before you send: your sending provider gives you the records. Whoever manages the DNS should know two SPF rules that break most setups: a domain may publish only one SPF record, so merge every service into it, and checking it may take at most 10 DNS lookups, or SPF fails.^[18] What each record looks like is in DKIM, SPF and DMARC explained, and moving DMARC to enforcement, under its current standard (RFC 9989, May 2026), in DMARC p=reject: how to move from p=none.

The SMTP conversation, line by line#

Here is an app submitting one message on port 587: C is the client, S the server. The server lines are an example; real servers word replies and list extensions differently, but the codes and the order are what the standards require.^[8][9]

S: 220 smtp.example.com ESMTP ready
C: EHLO app.example.com
S: 250-smtp.example.com
S: 250-PIPELINING
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
   (TLS handshake. Everything below is encrypted.)
C: EHLO app.example.com
S: 250-smtp.example.com
S: 250-PIPELINING
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-ENHANCEDSTATUSCODES
S: 250 AUTH PLAIN LOGIN
C: AUTH PLAIN AGFwcEBleGFtcGxlLmNvbQBleGFtcGxlLXBhc3N3b3Jk
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<bounces@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<ana@example.net>
S: 250 2.1.5 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Example Shop <orders@example.com>
C: To: ana@example.net
C: Subject: Your order has shipped
C: Date: Fri, 16 Oct 2026 09:30:00 +0000
C:
C: Your parcel is on its way.
C: .
S: 250 2.0.0 OK: queued as 7A1F3
C: QUIT
S: 221 2.0.0 Bye

• EHLO, twice. The reply to EHLO lists the server’s extensions.^[1] After STARTTLS both sides forget what they learned in plain text, so the client says EHLO again, and STARTTLS is not offered a second time.^[8]
• AUTH only after TLS. The AUTH PLAIN token is the username and password in base64, which anyone can reverse, so many servers list AUTH only after the upgrade.^[9]
• One recipient at a time. Each RCPT TO is accepted or refused on its own, and a server must take at least 100 per message.^[1]
• The full stop. The message ends at a line holding only a dot, so a body line starting with a dot gets a second one, which the receiver removes.^[1]

Two extensions cut round trips when the server advertises them. PIPELINING sends MAIL FROM and every RCPT TO in one batch and reads the replies in order; DATA may only end a batch.^[10] CHUNKING replaces DATA with BDAT 4096, then BDAT 812 LAST: pieces of stated size, so nobody scans for the closing dot.^[11] A client may use either only when the server lists it in its EHLO reply, so the same library code can pipeline against one server and not another.^[10]

Encryption between servers: STARTTLS, MTA-STS and DANE#

This section is for whoever runs a domain’s receiving mail server. If you only send through a provider, nothing here is yours to set up.

Between servers, STARTTLS is used only if both sides offer it, so an attacker who deletes the “250 STARTTLS” line sends the mail in plain text.^[8] Two standards let a receiving domain insist on encryption, and a third reports failures:

In enforce mode a sending server must not deliver to a host that fails certificate validation or lacks STARTTLS.^[14] DANE requires DNSSEC and resists downgrades, while MTA-STS relies on certificate authorities “at a cost of risking malicious downgrades”.^[14][15] Each TLS-RPT report covers a UTC day.^[16] Google documents that mail sent from a Workspace domain follows the receiving domain’s MTA-STS policy when that domain publishes one in enforce mode.^[17]

What breaks a DANE-protected MX#

Two things, and both stop mail rather than send it unencrypted. The first is a key change: RFC 7672 says two TLSA records “MUST be published before employing a new” key or certificate. Publish the record for the next key, wait out its TTL, then switch. With the common 3 1 1 record, a renewal that keeps the same key needs no DNS change, but a renewal that makes a new key does, and some certificate tools make one by default.^[15]

The second is DNSSEC itself. If the signatures on your zone expire, or the DS record at your registrar no longer matches your keys, validating senders get a “bogus” answer for your MX lookup. RFC 7672 treats that as a lookup failure and makes a DANE sender delay delivery, and any sender whose resolver checks DNSSEC fails the same lookup, so mail from every validating sender stops until it is fixed.^[15] Before moving DNS to another host that will not share keys with the old one, remove the DS record, wait out its TTL while the old host still signs, move, sign at the new host, then add its DS. DANE is off for that window, so do not combine it with a key change.

An MTA-STS rollout you can back out of#

The policy file is four kinds of line. Every mx: line names a host your MX records may point at (a *. wildcard covers one label), and a sender in enforce mode refuses an MX host the list does not match.^[14]

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

_mta-sts.example.com.   TXT  "v=STSv1; id=20261018T0900"
_smtp._tls.example.com. TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

1. Publish TLS-RPT and read a few days of reports.
2. Publish MTA-STS in testing mode with a short max_age such as 86400 (one day). Senders cache a policy for up to max_age seconds.
3. Switch to enforce once the reports are clean, then raise max_age. Every change goes in two places: update the policy file first, then the id in the TXT record, so senders refetch it.
4. To back out, publish mode: none with a short max_age and a new id. Senders that see the new id stop enforcing; any that have not looked again keep the old policy until its max_age runs out, so keep the old MX hosts working until then. Only after that remove the records.^[14]

Changing MX hosts without losing mail#

• Senders try the MX with the lowest preference number first and fall back to the others,^[1] and each MX must name a host with its own address records, never a CNAME.^[23]
• At least one current TTL before a cutover (check it; 24 hours is common), lower the MX record’s TTL to 300 seconds, say, so a rollback takes minutes. Keep the old hosts accepting mail for a few days after, for senders that cached the old MX or resolve it slowly.
• Under MTA-STS, add the new host to the policy’s mx: lines, with a new id, before the MX record points at it, and give the new host a publicly trusted certificate for that name first. An enforce sender will not deliver to a host it does not list, or one whose certificate fails.^[14]

TLS protects each hop, not the message, which is stored readable at every server; real security “lies only in end-to-end methods involving the message bodies”, such as S/MIME or PGP.^[1]

Sending from your app: SMTP relay, API or your own server#

If the software already speaks SMTP and you cannot change its code (a CMS, an auth service, a printer), use an SMTP relay. If you write the code, use an HTTP email API: failures come back as HTTP statuses your code can branch on, and an idempotency key makes a retry safe. The full decision, by situation, is the table in email API vs SMTP.

Is SMTP slower than an API at high volume?#

Not by protocol. With PIPELINING, a client may send one message’s content and the next message’s MAIL FROM, RCPT TO and DATA in a single batch,^[10] so a busy connection needs about one round trip per message, though not every library batches that far. Both kinds of sender can also open several connections at once, so what sets your throughput is the provider’s limits, not the protocol.

On Rasket that limit favours the API. Each relay message counts once against the 10 a second per team that the relay shares with the API,^[25] while one POST /emails/batch request carries up to 100 messages for the same one count.^[26] The daily and monthly quotas apply to both.

import nodemailer from "nodemailer";

const transporter = nodemailer.createTransport({
  host: "smtp.rasket.com",
  port: 465,
  secure: true,
  auth: { user: "rasket", pass: process.env.RASKET_API_KEY },
});

const message = {
  from: "Example Shop <orders@send.example.com>",
  to: "customer@example.com",
  subject: "Your receipt",
  text: "Thanks for your order.",
  // The same key on every attempt, so a retry cannot send twice.
  headers: { "X-Rasket-Idempotency-Key": "receipt-1042" },
};

// Nodemailer does not queue: a 4xx rejects sendMail, and the
// message is lost unless you retry it yourself. The relay's 4xx is
// its rate limit, so seconds are enough here; mail that must outlast
// a long outage belongs in a job queue that survives a restart.
for (let attempt = 1; ; attempt++) {
  try {
    const info = await transporter.sendMail(message);
    // "250 2.0.0 Queued as <email id>": the id webhook events carry.
    console.log(info.response);
    break;
  } catch (err) {
    const permanent = err.responseCode >= 500;
    if (permanent || attempt === 5) throw err;
    await new Promise((r) => setTimeout(r, 2 ** attempt * 1000));
  }
}

The same message through the API is one request, and its reply is the email id or a named error. Every request needs a User-Agent, or it is refused with a 403.^[28]

curl https://api.rasket.com/emails \
  -H "Authorization: Bearer $RASKET_API_KEY" \
  -H "User-Agent: acme-billing/1.0" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: receipt-1042" \
  -d '{"from": "Example Shop <orders@send.example.com>",
       "to": ["customer@example.com"],
       "subject": "Your receipt",
       "text": "Thanks for your order."}'

If you run your own mail server#

Rasket is the wrong tool if a device can only send plain SMTP on port 25, or if your policy says mail must leave from servers you run. Then the server needs, at least:

• An EHLO name that is a real host name resolving to an address.^[1]
• A PTR (reverse DNS) record for its IP address whose name points back to that IP. Gmail defers (451 4.7.23) or rejects (550 5.7.25) mail from addresses without one.^[21]
• SPF, DKIM and DMARC for the domain, and TLS on every port it listens on.
• If it also holds mailboxes: IMAP on 993 and POP3 on 995, encrypted from the first byte, which RFC 8314 recommends over upgrading a plain connection. If 143 or 110 stay open, require STARTTLS before any login there and refuse logins without TLS; the RFC asks providers to retire unencrypted access “as soon as practicable”.^[6]
• No open relaying (the FAQ shows how to test it), and a slow start: see how to warm up a new domain or IP.

Before your app depends on the settings, send one test message to an address you can read and check its Received: lines and authentication results.