What Is SMTP? How Email Sending Works

What SMTP Is and Why It Exists

SMTP — Simple Mail Transfer Protocol — is the foundational standard that governs how email messages are transmitted across the internet. Defined originally in RFC 821 (1982) and substantially updated in RFC 5321, SMTP operates as a push protocol: the sending mail server initiates a connection to the receiving mail server and delivers the message. Every email you send, whether from Gmail, Outlook, or a custom business domain, travels over SMTP at some point in its journey.

The protocol works on a straightforward client-server model. When you click "Send," your email client hands the message to your outgoing mail server (the SMTP server). That server looks up the destination domain's MX (Mail Exchange) DNS records to find where to deliver the message, opens a TCP connection on port 25 (or 587 for client submission), and transfers the message using a series of text-based commands.

SMTP is deliberately simple — each command and response is plain ASCII text, which is part of why the protocol has lasted over four decades with relatively few fundamental changes. Understanding SMTP is essential for anyone diagnosing email delivery failures, configuring a mail server, or investigating spam and phishing campaigns.

The SMTP Handshake: Step by Step

An SMTP session follows a precise conversational structure. Here is what happens when a mail server delivers a message:

1. TCP Connection: The sending server opens a TCP connection to port 25 of the receiving server.
2. Greeting: The receiving server responds with a 220 status code and its hostname.
3. EHLO/HELO: The sender introduces itself: EHLO mail.example.com
4. MAIL FROM: Declares the envelope sender: MAIL FROM:<user@example.com>
5. RCPT TO: Specifies the recipient: RCPT TO:<recipient@destination.com>
6. DATA: The sender issues the DATA command, then transmits headers and body, terminated by a lone period on its own line.
7. QUIT: The session closes cleanly.

Each step returns a three-digit status code. Codes in the 200s are successes, 400s are temporary failures (try again later), and 500s are permanent failures. A 550 response, for example, typically means the recipient address does not exist. These codes are preserved in email headers, making them invaluable for debugging delivery failures — use our HTTP headers check tool to inspect the raw headers of suspicious messages.

220 mail.destination.com ESMTP Postfix
EHLO mail.sender.com
250-mail.destination.com
250-STARTTLS
250 SIZE 52428800
MAIL FROM:<alice@sender.com>
250 Ok
RCPT TO:<bob@destination.com>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Hello
...
.
250 Ok: queued as 12345
QUIT
221 Bye

SMTP Ports: 25, 465, and 587

SMTP uses three different ports, each with a distinct role:

• Port 25: The original SMTP port for server-to-server mail relay. Most residential ISPs block outbound port 25 to prevent spam from compromised home computers. If your IP address is residential, you cannot send mail directly on port 25.
• Port 587 (Submission): The correct port for mail clients (Thunderbird, mobile apps) submitting mail to their outgoing server. Requires authentication (SASL) and uses STARTTLS to upgrade the connection to TLS encryption. This is the port you should configure in any email client.
• Port 465 (SMTPS): An older "implicit TLS" port that was briefly deprecated but is now formally re-assigned for authenticated SMTP over TLS. Some providers still use it.

The difference between STARTTLS and implicit TLS matters: STARTTLS starts as a plaintext connection and upgrades, while implicit TLS wraps the entire session in TLS from the first byte. Both are secure when properly configured, but STARTTLS is theoretically vulnerable to downgrade attacks if the server is misconfigured.

You can verify whether a mail server has specific ports open using our port checker tool — just enter the mail server hostname and check ports 25, 465, and 587.

SPF, DKIM, and DMARC: Authenticating Email

SMTP itself has no built-in authentication — anyone can claim any "from" address. Three DNS-based authentication mechanisms solve this:

SPF (Sender Policy Framework): A TXT DNS record that lists which IP addresses are authorized to send mail for a domain. When a receiving server gets a message claiming to be from @example.com, it checks the SPF record. If the sending IP is not listed, the message fails SPF and may be rejected or marked as spam.

DKIM (DomainKeys Identified Mail): The sending server signs the message with a private cryptographic key. The receiving server retrieves the public key from DNS and verifies the signature, confirming the message was not tampered with in transit. DKIM survives forwarding better than SPF because it's tied to the message content, not the sending IP.

DMARC (Domain-based Message Authentication): Ties SPF and DKIM together and tells receiving servers what to do when authentication fails: none (monitor), quarantine (send to spam), or reject (block entirely). DMARC reports are emailed back to the domain owner, giving visibility into who is sending mail using your domain.

Together, these three mechanisms form the backbone of modern email authentication. Use our IP lookup tool to research sending servers found in email headers.

Diagnosing Email Delivery Problems

When email delivery fails, the first place to look is the email headers. Every server that handles a message appends a "Received:" header, creating a traceable chain from sender to recipient. Reading these headers from bottom to top shows you exactly which servers processed the message and when.

Common delivery problems and their SMTP diagnostics:

• 550 5.1.1 User Unknown: The recipient address does not exist. Check for typos in the address.
• 550 5.7.1 Blocked: The sending IP is on a blacklist (RBL). Check our IP lookup tool to see blacklist status.
• 421 Try Again Later: Temporary greylisting. The receiving server is asking you to retry in a few minutes — a common spam-reduction technique.
• 535 Authentication Failed: Wrong username or password for the submission port.
• TLS Negotiation Failed: Certificate mismatch or expired TLS certificate on the receiving server.

For deliverability issues, always verify your SPF and DKIM records are correctly published, confirm your sending IP is not blacklisted, and check that your PTR (reverse DNS) record matches your mail server's hostname — receiving servers often reject mail from IPs with missing or mismatched PTR records.

SMTP Security: Risks and Best Practices

SMTP was designed in a more trusting era and has accumulated security concerns over its lifetime. Understanding these risks helps both senders and system administrators protect their infrastructure.

Open Relays: A misconfigured mail server that accepts and forwards mail for any domain — not just its own — is called an open relay. Open relays are rapidly added to blacklists because spammers exploit them to send bulk mail. Always configure your mail server to relay only authenticated users or specific trusted IPs.

SMTP Smuggling: A relatively recent attack class (2023) where subtle differences in how SMTP servers interpret line endings can allow attackers to inject forged emails that pass DMARC checks. Major providers have patched their implementations.

Credential Stuffing on Port 587: Attackers try stolen username/password combinations against submission ports. Rate limiting, fail2ban, and strong passwords are essential defenses.

Best practices for secure SMTP:

• Require TLS for all connections (use STARTTLS or implicit TLS)
• Deploy SPF, DKIM, and DMARC for your domain
• Keep PTR records accurate and matching your EHLO hostname
• Monitor blacklist status of your sending IPs regularly
• Use authenticated submission (port 587) for all client mail

Frequently Asked Questions