How SMTP Works: A Developer's Guide to Email Delivery

Have you ever built a signup form, sent a verification email, and wondered what actually happens after your application clicks "Send"?

Sending an email might look like a single operation in your code. Behind the scenes, however, several systems work together to transfer the message from one server to another.

One of the most important protocols involved in this process is SMTP (Simple Mail Transfer Protocol).

SMTP is widely used to send email between mail servers and to submit messages to email services.

In this article, we'll explore how SMTP works, understand its basic commands, interpret common response codes, and look at how developers can troubleshoot email delivery problems.

What Is SMTP?

SMTP stands for Simple Mail Transfer Protocol.

It's a communication protocol used to transfer email messages between systems.

For example, imagine your application sends a verification email to a user who just created an account.

Your application prepares the message and submits it to an SMTP server. That server can then communicate with the recipient's mail server to deliver the message.

A simplified process looks like this:

Application → SMTP Server → Recipient's Mail Server → Inbox

The actual journey may involve multiple servers, security checks, filtering systems, and delivery attempts.

SMTP handles message transfer. It doesn't, by itself, guarantee that a message will reach the recipient's inbox.

SMTP vs. MX Records: What's the Difference?

If you've read about DNS and MX records, you might wonder how they relate to SMTP.

They solve different problems.

MX records tell sending mail systems which servers are responsible for receiving email for a domain.

SMTP provides the protocol used to communicate with those servers and transfer the message.

For example, suppose an application needs to send an email to:

[e-mail]

The sending system can look up the MX records for example.com to discover the appropriate receiving mail server.

It can then use SMTP to establish a connection and attempt to deliver the message.

Understanding this distinction makes email troubleshooting much easier.

How Does SMTP Work?

Let's walk through a simplified example.

Suppose an application needs to send a verification email to:

[e-mail]

The process generally involves the following steps.

1. The application prepares the email

The application creates the message with details such as:

• Sender address
• Recipient address
• Subject
• Message body
• Optional attachments

For example, a web application might prepare an email containing a signup verification link.

2. The application connects to an SMTP server

The application connects to an SMTP server configured to accept outgoing messages.

Depending on the service and configuration, the connection might use port 587 with STARTTLS or port 465 with implicit TLS.

Authentication is commonly required when an application submits messages through a provider's SMTP service.

3. The SMTP conversation begins

After the connection is established, the client and server exchange commands and responses.

These commands help identify the client, specify the sender and recipient, and transfer the message content.

4. The receiving server processes the message

The receiving mail server checks whether it can accept the message.

It may perform recipient validation, authentication checks, spam filtering, and other security checks.

If the server accepts the message, it can continue through its delivery pipeline.

5. The email is delivered or queued for further processing

The message may reach the recipient's mailbox, enter another processing stage, or be temporarily queued for retry.

An SMTP success response means the receiving system accepted responsibility for the message at that stage. It doesn't necessarily mean the message has appeared in the user's inbox.

Understanding the Most Important SMTP Commands

Let's look at some common commands you'll encounter when studying SMTP.

EHLO

EHLO introduces the client to the SMTP server and requests the server's supported extensions.

Example:

EHLO app.example.com

The server responds with information about its capabilities.

Older SMTP conversations may use HELO, while modern SMTP sessions commonly use EHLO.

MAIL FROM

MAIL FROM specifies the envelope sender address used for the SMTP transaction.

Example:

MAIL FROM:<[e-mail]>

The envelope sender is important for delivery handling and bounce processing. It isn't necessarily identical to the address displayed in the email's From header.

RCPT TO

RCPT TO specifies a recipient for the message.

Example:

RCPT TO:<[e-mail]>

The server evaluates whether it can accept the message for that recipient.

A server may accept one recipient and reject another, depending on its configuration and policies.

DATA

DATA tells the server that the client is ready to transmit the message content.

Example:

DATA

The server normally responds with a status indicating that the client can begin sending the message.

The client then transmits the message headers and body, ending the SMTP data with a line containing a single period.

If the server accepts the message, it returns a success response.

These commands are part of the SMTP conversation, not commands that you normally type into your application's email subject or message body.

A Simplified SMTP Conversation

Here's a simplified illustration of a successful SMTP exchange.

S: 220 mail.example.com ESMTP ready
C: EHLO app.example.com
S: 250-mail.example.com
S: 250 STARTTLS
C: MAIL FROM:<[e-mail]>
S: 250 OK
C: RCPT TO:<[e-mail]>
S: 250 OK
C: DATA
S: 354 Start mail input
C: Subject: Verification email
C:
C: Please verify your email address.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Bye

Here, C represents the client and S represents the server.

The response codes and exact wording are illustrative. Real servers can return additional information, advertise different capabilities, or reject a command depending on the situation.

The key idea is that SMTP uses a sequence of commands and server responses to manage the transfer of a message.

Understanding SMTP Response Codes

SMTP response codes help developers understand what happened during a request.

Here are several common examples.

2xx — Success

A response such as 250 generally indicates that the requested action succeeded.

For example, a server may return a 250 response after accepting a message.

3xx — More information required

A response such as 354 indicates that the server expects the client to provide additional input.

For example, a server commonly returns 354 after the client issues DATA.

4xx — Temporary failure

A response such as 451 or 421 can indicate a temporary problem.

Depending on the error and the sending system's retry policy, the message may be attempted again later.

5xx — Permanent failure

A response such as 550 can indicate a permanent rejection for the particular request.

For example, a recipient might not be accepted by the receiving server.

However, don't classify every error based on the number alone. The complete response, SMTP stage, server policy, and provider documentation matter.

Practical tip: When troubleshooting SMTP, record the full response code and message, along with the command that triggered the response.

That information is much more useful than simply recording "email failed."

Why Do SMTP Emails Fail?

An application can generate an email correctly and still fail to deliver it.

Here are some common causes.

1. Incorrect SMTP credentials

The application may be using an incorrect username, password, or authentication configuration.

Providers commonly return a 535 authentication error in this case.

Check the credentials and authentication requirements of your SMTP provider.

2. TLS or connection problems

The application may use the wrong port or an incompatible TLS configuration.

Check the provider's connection instructions and confirm that the server can establish a secure connection.

3. Sender or recipient rejection

The SMTP server may reject a sender address or recipient based on its configuration and policies.

Inspect the response returned for MAIL FROM or RCPT TO.

4. DNS configuration problems

When sending to another domain, the sending mail system needs to discover the destination mail server, typically through MX records.

Incorrect DNS configuration can prevent the sending system from locating the expected destination.

5. SPF, DKIM, or DMARC issues

These email authentication mechanisms help receiving systems evaluate messages.

Incorrect configuration can contribute to delivery problems or cause messages to be rejected or filtered.

They serve different purposes from SMTP itself.

6. Rate limits or temporary server failures

An SMTP provider may temporarily reject messages because of rate limits, maintenance, or other conditions.

Your application should distinguish temporary failures from permanent ones and apply an appropriate retry policy.

7. The message was accepted but never appeared in the inbox

An SMTP server accepting a message doesn't guarantee inbox placement.

The message may be filtered, quarantined, rejected later by another system, or delivered to another folder.

Check the available delivery logs and the receiving mailbox before assuming the SMTP transaction was the problem.

How Developers Can Debug SMTP Problems

When email delivery fails, avoid changing several settings at once.

Instead, investigate the delivery process one stage at a time.

Step 1: Check application logs.

Confirm that your application attempted to send the message and record any exception or provider error.

Step 2: Check the SMTP connection.

Verify the hostname, port, TLS settings, and authentication configuration.

Step 3: Inspect the SMTP response.

Identify which command failed and record the complete response code and message.

Step 4: Check DNS when delivering to another domain.

Confirm that the destination domain has the expected MX records and that the advertised mail servers resolve correctly.

Step 5: Check message acceptance and delivery logs.

Determine whether the server rejected the message, accepted it, or queued it for further delivery.

Step 6: Investigate authentication and filtering.

If the message was accepted but doesn't appear in the inbox, review relevant SPF, DKIM, DMARC, spam-filtering, and mailbox logs.

This method helps narrow down the problem without guessing.

What About SMTP in Temporary Email Systems?

SMTP is also important when building systems that receive incoming email.

For example, a temporary email platform may provide addresses such as:

[e-mail]

When another system sends an email to that address, the receiving infrastructure must accept the message and route it to the correct inbox.

A simplified incoming-email process looks like this:

Sender → DNS/MX Lookup → Receiving Mail Server → SMTP Transaction → Message Processing → Temporary Inbox

After the mail server accepts the message, the application may need to:

• Identify the intended temporary address
• Parse the email headers and body
• Extract the sender and subject
• Detect verification codes or OTPs
• Process HTML content
• Handle attachments
• Store the message
• Apply expiration and deletion rules

These steps illustrate the difference between receiving a message at the mail-server level and making it available to a user in an application.

While building InboxOro, a temporary email and email infrastructure platform, I've been exploring how mail-server behavior and application-level processing work together.

The important lesson is that a successful SMTP transaction is only one stage in the overall email workflow.

SMTP Is One Part of a Larger System

SMTP doesn't work in isolation.

A typical email infrastructure may involve:

• DNS and MX records to discover receiving mail servers
• SMTP to transfer messages
• TLS to protect connections in transit
• SPF, DKIM, and DMARC for email authentication and policy evaluation
• Message-processing systems to parse and route email
• Queues and retry mechanisms to handle temporary failures
• Storage systems to make messages available to applications

When these components work together correctly, email applications become easier to operate and troubleshoot.

Understanding the boundaries between them is especially useful when building authentication flows, SaaS products, notification systems, or email infrastructure.

Conclusion

SMTP is a fundamental protocol in email delivery.

Understanding its commands, response codes, connection requirements, and failure modes helps developers build more reliable email features.

When an email doesn't arrive, the most useful question isn't simply, "Why did sending fail?"

Instead, focus on identifying where the process failed: connection, SMTP transaction, message acceptance, or downstream delivery.

That approach gives developers a clearer starting point for debugging.

I'm continuing to explore email infrastructure while building InboxOro, and I'll share more about email processing, APIs, and developer tooling in future posts.