SMTP (Simple Mail Transfer Protocol) is the behind-the-scenes protocol that lets you send and receive emails. Not sure what it does or how it works? You've come to the right place.
Emails play a big role in how we communicate, but what happens when we send an email?
The process of sending an email is similar to mailing a physical letter: through a series of steps, an organized system takes care of the envelope and drops it off to the recipient. However, with emails, the SMTP server acts like the post carrier—though that’s just the beginning.
If you’re just dipping your toe into the how-email-gets-sent world, it’s easy to feel overwhelmed. To help you navigate your email sending—using an SMTP server to send email—we’ve put together a list of the most common SMTP server questions we receive, so you’ll be an SMTP expert in no time.
Curious about the SMTP meaning?We’re glad you asked. The Simple Mail Transfer Protocol (SMTP) is an application used by mail servers to send, receive, and relay outgoing email between senders and receivers.
As the technology behind email communication, SMTP is the protocol that allows you to send and receive emails. Without it, email communication would be nonexistent since SMTP determines which servers will receive your relay messages.
As the “T” in its name indicates, SMTP is a transport protocol: All it does is move messages from point A to point B.
Like many other Internet protocols, SMTP is intended to be used on top of the Transmission Control Protocol (TCP), which guarantees reliable delivery of the individual packets that make up a conversation.
The use of IP means that we can depend on SMTP to eventually get the message contents to a server, but what happens to it after that is up to the server.
Imagine what happens when a delivery driver leaves a package at your office on a Saturday. What happens to it after delivery isn’t his problem.
Deliverability, monitoring, tracking, authentication, and encryption are all examples of services that SMTP doesn’t necessarily provide itself but that are still very valuable.
An outgoing mail server is a generalized term to describe a system that collects, processes, and serves email. Much like a mail carrier, every email message passes through the mail server before reaching its destination. Without servers, you would only be able to send emails to people whose addresses matched your domain—Gmail.com to Gmail.com, for instance.
Because an SMTP email server pertains to outgoing email, it’ll have an address (or addresses) that the mail client or application you use can set that generally looks like this: smtp.serveraddress.com. For example, the SMTP server Gmail uses is smtp.gmail.com, and Twilio SendGrid’s is smtp.sendgrid.com. You can generally find your SMTP email server address in the account or settings section of your mail client.
Using a store and forward process, SMTP works with the mail transfer agent to move your email across networks to the right computer and email inbox.
So when you send an email with SMTP host Gmail or AOL, the SMTP server processes your email, decides which server to send the message to and relays the message to that email server. The recipient’s inbox service provider, such as Gmail or AOL, then downloads the message and places it in the recipient’s inbox.
You can find more details to help you understand the SMTP meaning on our docs page.
Like most servers, the SMTP server processes data sent to another server, but it has the specific purpose of processing data related to the sending and relaying of email. An SMTP server also isn’t necessarily on a machine butcan be an application constantly running in anticipation of sending new mail.
When communicating over email, it's crucial to send email to your recipient safely and on time. However, without an SMTP server, your email can’t make it to its destination.
Once you hit Send, the email transforms into a string of code sent to the SMTP server, which processes that code to pass the message. Without the SMTP server to process the message, the message wouldn’t translate.
Additionally, the SMTP server verifies that the outgoing email is from an active account. In other words, the email server checks whether an active or working email account sent the outgoing message, protecting your inbox from illegitimate email.
If the email is undeliverable, the SMTP ensures the email will bounce back to the sender, letting them know they have an incorrect email address or the receiving email server blocked the email for whatever reason.
Your mail client connects to the SendGrid SMTP server, smtp.sendgrid.net, using port 25 (by default).
Your mail client has a conversation with our server, first verifying that the username and password used for authentication correspond to an active account, then relaying the message information, such as sender address, recipient, and message content.
Our server takes the message information we gathered from your request, then repeats the conversation process in step 2 with the recipient’s mail server.
Your recipient’s mail server checks the sending address, recipient address (to ensure it’s a valid recipient), and message content. It also checks the sending domain for any potential DNS issues, such as invalid DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) signatures. As long as there are no issues, the recipient’s mail server will use the protocols POP3 or IMAP to retrieve the email and deliver the message to its intended recipient.
Take a look at the diagram below for a visual of the SMTP email delivery process.
SendGrid offers free accounts that you can enable without a credit card. With a free SendGrid account, we give you access to the SendGrid SMTP server and allow you to send up to 100 emails per day—effectively giving you an SMTP server for testing.
Active free account customers can also use their account to send test messages and test their email deliverability before upgrading and sending significantly more email.
All you need is an active SendGrid account and the ability to use basic username and password authentication within your email client or application to send an email using our SMTP server.
SMTP was built to be a lightweight, easy-to-implement means to transfer plain-text messages between devices. The original SMTP standard distinguished between a mail transport agent (MTA)—what modern administrators would call a server—and mail user agents (MUA), which most people refer to as clients.
SMTP’s goal was to provide a way for two MTAs to pass message traffic back and forth. The protocol doesn’t define any standards for storing messages, giving clients access to them, or carrying complex content types such as audio or image data. It’s just a set of rules for moving a properly structured message from point A to point B.
The original Internet grew from ARPANET, a closed research network that was designed for academic and government use.
ARPANET and the early implementation of the Internet were designed around the assumption that only a limited number of trusted users would be able to connect to the network.
The competing X.400 protocol was intended to be a more robust message transfer protocol that would be suitable for commercial use; X.400 included features for guaranteed reliable delivery, message tracking, and other security and authentication features. However, it was complex to implement, and it ultimately lost out to the simpler, less complex, less expensive SMTP implementations.
The version of SMTP that we use today still shows a number of design influences that trace back to its origins:
The protocol itself didn’t provide for authentication or encryption, which weren’t especially important on a trusted network with trustworthy users. (Since SMTP’s appearance, a series of extensions to the standard have added these features.)
The ability to get return receipts or delivery notifications is dependent on which client recipients use; servers are required to send delivery status notifications (DSNs) only for messages that are permanently undeliverable.
There’s no enforced mechanism for classes of service; for example, FedEx and UPS both let you choose from multiple delivery speeds according to how much you’re willing to pay.
Email filtering often seems capricious, and users have learned through experience that important messages may be filtered arbitrarily by the spam filters in their client, in their server, or somewhere in the cloud. (And now of course, recipients can filter messages within their own inboxes through features like Gmail’s “tabs”.)
SMTP (or email in general) often falls back to using web-based technologies (i.e. img and anchor tags) to archive click and open tracking metrics.
As the Internet spread, businesses were allowed to connect to it. However, they were informally banned from using it for commercial purposes.
A few large companies (notably IBM, DEC, and Control Data) built corporate email systems for large-company use, and as time passed, smaller companies—including Novell, Lotus (now IBM Lotus), and Microsoft—saw the business value in email systems and began building and delivering intra-company systems that broadened the email market.
None of these systems provided much in the way of interoperability, although after the SMTP standard was defined a few forward-looking vendors began adding SMTP support through gateways or connectors that linked MTAs from different vendors.
The difficulty of getting interoperability to reliably work across multiple MTA vendors and their individual connectors put a lot of market pressure on vendors to come up with a simpler, more robust solution, so native SMTP began to gather real momentum in the mid-1990s.
Now, it is the de facto standard for transferring mail between servers. Even products that once used proprietary protocols rely on SMTP both for message transport.
