What is SMTP?

SMTP (Simple Mail Transfer Protocol) is an Internet standard used to send and relay email across networks, most commonly the Internet. Operating at the application layer of the TCP/IP protocol suite, SMTP is responsible for pushing emails from a client to a mail server or between mail servers until delivery is complete.

How does SMTP power email communication?

SMTP enables smooth email communication by allowing email clients (such as Gmail or Outlook) to connect with SMTP servers to send messages. When you hit send, your email client contacts an SMTP server, which verifies your identity, checks the recipient's address, and transmits the email. If the recipient’s server isn’t directly reachable, SMTP can route the message through other servers until it arrives. This relaying ability ensures emails are delivered globally across various systems, making SMTP a crucial part of how email works.

How has SMTP evolved over the years?

SMTP has come a long way since it was introduced in 1982 by Jon Postel in RFC 821. Back then, it could only handle plain text emails and used a simple store-and-forward model. As email quickly grew in popularity, the protocol had to adapt. In 1995, Extended SMTP (ESMTP) arrived through RFC 1869, making room for larger messages and add-on features. Security soon became critical: in 1999, STARTTLS was introduced so emails wouldn’t travel across the internet in plain text, and later SMTP AUTH helped stop open relays — a common way spammers abused early mail servers. Today, SMTP supports encryption, authentication, and even internationalized email addresses, making it flexible enough for modern, global communication while still serving the same purpose it had from the start: getting your message delivered.

What is the SMTP infrastructure made of?

At the heart of email delivery are SMTP servers. These servers handle sending, receiving, and relaying messages using the Simple Mail Transfer Protocol. Depending on configuration, the same server can play multiple roles — as a submission agent, a transfer agent, or even a relay. A relay, for example, comes into play when one SMTP server needs to forward mail to another, especially across different domains or external networks.

Here are the main building blocks of the infrastructure:

Mail User Agent (MUA): This is the app you use to write and read emails — like Outlook, Thunderbird, Apple Mail, or Gmail’s web interface.

Mail Submission Agent (MSA): The first stop for outgoing emails. It receives your message from the MUA, checks your authentication, applies policies like SPF/DKIM signing, and gets it ready for transfer. Think of it as the gatekeeper ensuring the email is legitimate before letting it onto the network.

Mail Transfer Agent (MTA): The workhorse of email delivery. It moves messages across networks, using SMTP to talk to other MTAs and DNS lookups to figure out where the message should go. For example, if you send mail from Gmail to someone on Outlook, MTAs on both sides handle the routing

Domain Name System (DNS): Every time an MTA needs to deliver mail, it checks DNS for MX (Mail Exchange) records of the recipient’s domain. MX records say which server should receive the message. If there are multiple servers, priority rules kick in, which keeps delivery reliable even if one server is down.

Mail Delivery Agent (MDA): The final stop. The MDA accepts the email from the MTA, filters it for spam if needed, and then stores it in the recipient’s mailbox so it’s ready for their MUA to fetch.

Common SMTP commands and what they do

SMTP commands are the instructions your email client or server sends to an SMTP server when sending an email. They usually happen in three phases: handshake, message transfer, and session end. Here’s a breakdown of the key commands:

• HELO / EHLO – Start the conversation.
  • HELO is the classic version where the client introduces itself.
  • EHLO is for Extended SMTP (ESMTP) and allows extra features like authentication, encryption, and size limits. If the server doesn’t support EHLO, the client can fall back to HELO.
• MAIL FROM – Tells the server who the email is from.
• RCPT TO – Tells the server who the email is going to. Repeat for multiple recipients.
• DATA – Signals that the actual email content is coming (subject, body, attachments). The server responds with 354 to allow sending. The email ends with a single period (.) on a line.
• AUTH – Used to log in to the server. Supports methods like PLAIN, LOGIN, and CRAM-MD5. Some modern servers also use XOAUTH2.
• STARTTLS – Switches the connection to encrypted TLS. After this, the client restarts the handshake with EHLO to continue securely.
• VRFY – Checks if an email address exists on the server. Usually turned off for security.
• RSET – Resets the current mail transaction without closing the connection.
• QUIT – Ends the session. Server responds with 221.
• HELP – Asks the server for help or a list of supported commands.

Other useful commands in ESMTP include:

• SIZE – Tells the server the size of the email.
• EXPN – Expands a mailing list (often disabled for security).
• BDAT – Sends email in chunks or binary form (used in some Microsoft servers).

SMTP ports

SMTP communicates over specific TCP ports, each commonly used for different purposes like server-to-server relay, client submission with authentication, or secure SSL connections.

SMTP ended up with different ports as email evolved: port 25 for server-to-server relays, port 587 for sending from email clients, and port 465/587 with encryption for secure messages. Port 587 is the preferred port for sending emails securely with authentication and encryption. Port 25 remains important for server-to-server email delivery but is often restricted for client use.

SMTP error codes and responses

SMTP servers respond to commands with numeric codes that indicate the status of each request. Knowing what each code means makes it easier to diagnose problems, handle errors programmatically, and optimize email workflows. Common SMTP response codes include:

Sending an email may seem instantaneous, but behind the scenes, your client and the recipient’s server are having a detailed conversation. Here’s a peek behind the scenes when one server talks to another to deliver your email.

Client                                      Server
------                                      ------
EHLO client.net   ---------------------->   250 Hello client.net
                                           250-SIZE 35882577
                                           250-STARTTLS
                                           250-AUTH LOGIN PLAIN
                                           250 HELP
// Client introduces itself; server replies with supported features (size limit, TLS, authentication, help).

AUTH LOGIN       ---------------------->   334 Username:
dGVzdEBjbGllbnQubmV0 ---------------->   334 Password:
cGFzc3dvcmQ=      ---------------------->   235 Authentication successful
// Client logs in securely. Server requests username and password (encoded), then confirms authentication.

MAIL FROM:<[email protected]> ------------>   250 OK
// Client specifies sender email address; server confirms receipt.

RCPT TO:<[email protected]> ------------>  250 OK
// Client specifies recipient email address; server confirms.

DATA             ---------------------->   354 Start mail input
Subject: Hello
This is the body of the email.
.                ---------------------->   250 Message accepted for delivery
// Client sends the email content. Server signals when ready, then confirms successful message acceptance.

QUIT             ---------------------->   221 Bye
// Client ends the session; server closes the connection.

You might consider directly interacting with SMTP when you want manual control, programmatic access, or integration with apps and automation. This gives you benefits like:

• Debugging and troubleshooting delivery issues using server responses.
• Automating email sending from apps, scripts, or workflows.
• Customizing authentication and security (TLS, SPF, DKIM).
• Tracking delivery and handling errors more reliably than relying solely on a client.

Methods to send emails via SMTP

Use an email client (manual setup):
Configuring SMTP in apps like Gmail, Thunderbird, or Apple Mail is the simplest approach for sending emails manually. You just enter the SMTP server, port, and login credentials. This method is ideal for small businesses or individual users who want direct control over which server sends their emails.

Command-line tools (for testing):
You can use basic command-line tools such as Telnet or Netcat to interact directly with an SMTP server, primarily for testing or debugging. These tools are useful for manual testing and debugging, but they have drawbacks. They are not ideal for automation or real-world applications and lack encryption.

Code-based integration (programmatic SMTP):
Libraries like Python’s smtplib, PHP’s PHPMailer, or Node.js nodemailer let you send emails from applications or scripts. This approach supports advanced features such as attachments, HTML content, multiple recipients, logging, and error handling. It’s ideal for automated notifications, signup confirmations, or backend workflows.

Third-party email services (SendGrid, Mailgun, Amazon SES, etc.):
These platforms provide SMTP endpoints or APIs with built-in deliverability, analytics, and compliance features. They handle authentication, throttling, and spam filtering, which reduces developer overhead and improves inbox placement rates. Using them allows you to track opens, clicks, and bounces easily.

Set up your own SMTP server (Postfix, Sendmail, etc.):
Running your own server gives full control over email delivery, configuration, and security policies. This method is best for organizations or advanced users needing private or internal email flows. However, it requires careful management of TLS certificates, authentication, and spam prevention (SPF, DKIM, DMARC), as misconfigurations can result in blacklisting or delivery failures.

Common SMTP email service providers

An SMTP email service provider manages the server infrastructure, authentication, deliverability, and reputation for you, making sure your emails reach inboxes safely and consistently.

Choosing the right provider depends on factors like volume, ease of integration, pricing, and deliverability guarantees. Some services are developer-focused and API-friendly, while others offer all-in-one marketing and transactional solutions. Below are some of the most widely used SMTP providers:

• Brevo (formerly Sendinblue): All-in-one SMTP server for marketing and transactional emails, offering powerful marketing automation, SMS marketing, and a user-friendly platform.
• Amazon SES (Simple Email Service): Ideal for tech-savvy, high-volume senders who want a cost-effective, pay-as-you-go SMTP service. It requires manual setup and coding but offers excellent scalability and pricing.
• SendGrid: Suitable for large businesses needing scalable SMTP or API-driven email delivery, with integrated marketing tools.
• Postmark: Focused on fast, reliable email delivery with excellent customer support and transparent pricing. It is highly regarded for deliverability and simplicity, with plans starting at $15/month for 10,000 emails.
• Mailgun: Developer-focused SMTP service with strong API support, scalable plans, and a pay-as-you-go pricing model. It is popular among businesses needing reliable transactional and bulk email sending.

Running your own server vs a third-party email service

Running your own SMTP server gives you complete control, but it also means taking on a lot of technical responsibility. While some teams still do this—mainly for internal systems, learning purposes, or strict compliance—it’s becoming increasingly rare for public-facing email.

Deliverability is tricky, ISPs often block outgoing port 25, and managing security, encryption, and authentication takes ongoing effort. For most apps, businesses, and developers, a third-party SMTP service is faster, easier, and more reliable, handling everything from scaling to reputation management.