- What is SMTP, and what does it do?
- How does an SMTP session work?
- Which ports does SMTP use?
- How can you test an SMTP connection?
- SMTP authentication and TLS
- Are SMTP, IMAP, and POP3 the same thing?
- Where should you start when SMTP sending fails?
- What should you configure on an SMTP server?
- Frequently asked questions
- Sources
What is SMTP, and what does it do?
SMTP, or Simple Mail Transfer Protocol, is the application-layer protocol used to submit email from a client to a mail server and transfer it between mail servers. Your message normally goes to a submission server first. That server finds the recipient domain’s MX record and opens another SMTP session with the destination server.
The message does not usually travel directly from your laptop or web application to the recipient’s computer. Your email client or application connects to an SMTP submission service, which accepts the sender, recipient, and message data. Incoming mail is a separate job, normally handled with IMAP or POP3.
That distinction matters when you run a VPS. Your web application can be perfectly healthy while email sending fails because it is using the wrong port, the wrong TLS mode, or credentials for a server that requires authentication. Entering “the SMTP details” is not proof that the connection is correctly configured.
How does an SMTP session work?
SMTP uses a text-based client-server conversation. The client sends commands and the server answers with three-digit response codes. RFC 5321 describes the basic flow: establish a connection, identify the client, specify the envelope sender and recipient, and transfer the message data.
Finding the destination with DNS
The sending server queries the recipient domain’s MX record. For example, a server delivering mail to example.com asks DNS which mail server handles that domain. If no MX record exists, some servers may fall back to an A or AAAA record, but that is not a substitute for a properly configured mail domain.
I check MX records from the terminal with dig:
dig +short MX example.com
The number in the output is the MX preference. A lower number means higher priority. When several records exist, the sending server normally tries the preferred destination first and may try another if the connection cannot be established.
A DNS mistake rarely affects SMTP alone. Other services can depend on the same delegation and record chain, so I use dig before trusting a hosting panel’s status message. If a browser shows a similar DNS failure, the checks in How to Fix DNS_PROBE_FINISHED_NXDOMAIN Error are a useful companion.
TCP connections and SMTP commands
The client opens a TCP connection to the destination server’s port. If the server accepts it, it usually sends a greeting beginning with the 220 response code.
The essential commands are:
EHLO, or the olderHELO: identifies the client.MAIL FROM: supplies the envelope sender.RCPT TO: supplies the envelope recipient.DATA: transfers the message headers and body.QUIT: closes the session cleanly.
The envelope sender is not the same thing as the visible From: header. The MAIL FROM value is used for delivery and bounces, while From: is what the recipient normally sees in an email client. Missing that distinction makes spoofing investigations and delivery troubleshooting harder.
What does the message exchange look like?
A session can look roughly like this:
S: 220 mail.destination.example ESMTP Postfix
C: EHLO sender.example
S: 250-mail.destination.example
S: 250-PIPELINING
S: 250-STARTTLS
S: 250 AUTH PLAIN LOGIN
C: MAIL FROM:<[email protected]>
S: 250 2.1.0 Ok
C: RCPT TO:<[email protected]>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Test message
C:
C: Hello
C: .
S: 250 2.0.0 Ok: queued
C: QUIT
S: 221 2.0.0 Bye
A line containing only a period marks the end of the DATA section. A 250 queued response means the server accepted the message for processing. It does not prove that the message reached the recipient’s inbox. The destination server may still filter it, delay it, or reject it later.
Which ports does SMTP use?
Port selection is one of the SMTP configuration mistakes I see most often. The IANA service-name registry lists port 25 for SMTP, 587 for message submission, and 465 for message submission over implicit TLS. RFC 6409 separates message submission by users and applications from server-to-server SMTP transfer.
| Port | Common use | TLS mode | Authentication |
|---|---|---|---|
| 25 | Mail transfer between servers | Plain connection initially, with STARTTLS when offered | Depends on server policy; usually not intended for application submission |
| 587 | Message submission by a client or application | Usually STARTTLS | Usually required |
| 465 | SMTP submission over TLS | TLS from the beginning of the connection | Usually required |
When is port 25 appropriate?
Port 25 is the traditional port for mail servers delivering messages to one another. A sending domain’s MX server can connect to the recipient domain’s MX server on port 25. Because this traffic is frequently abused for spam, many VPS providers restrict outbound port 25 on new servers.
A blocked port 25 does not mean your web application cannot send email. Pointing the application at a relay or submission service on port 587 is often the right approach. You can ask the provider to remove the restriction, but first decide whether you are going to operate your own mail server or use an external relay.
What is the difference between ports 587 and 465?
RFC 6409 defines port 587 for message submission. The client normally begins with an ordinary TCP connection, sees STARTTLS in the server’s EHLO response, and upgrades the session to TLS. Authentication usually happens after TLS has been established.
On port 465, TLS starts with the first bytes of the connection. This is called implicit TLS and is sometimes called SMTPS. RFC 8314 discusses direct TLS connections as well as STARTTLS for secure submission. In many application libraries, “SSL” means port 465 and “STARTTLS” means port 587.
Do not mix up the port and encryption mode. Selecting implicit TLS while connecting to 587 makes the client expect TLS before the server has sent its normal SMTP greeting. Sending STARTTLS to a direct-TLS service on 465 is the opposite mismatch. Both fail for the same basic reason: the two sides disagree about the first protocol bytes.
How can you test an SMTP connection?
I test network access first, TLS second, and application settings last. Changing everything at once hides the location of the fault. An open TCP port does not prove that SMTP authentication or final delivery works.
Testing STARTTLS on port 587
openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf -servername smtp.example.com
A successful connection shows the certificate chain and TLS version. You can then type EHLO test.example and inspect the server capabilities. Seeing 250-STARTTLS means the server offers the feature; it does not mean that the current session is already encrypted.
Testing direct TLS on port 465
openssl s_client -connect smtp.example.com:465 -crlf -servername smtp.example.com
I do not add -starttls smtp on port 465 because TLS is negotiated at the beginning. If the certificate name does not match the hostname, the client may report a verification error. Fix the hostname or certificate configuration instead of disabling certificate checks. Silencing a security warning is not troubleshooting.
Is the port reachable?
nc -vz smtp.example.com 587
This only tests whether a TCP connection can be established. A succeeded result says that the port is reachable, not that the SMTP account is valid. A timeout can point to a firewall, provider filter, wrong IP address, or routing problem. When I need to inspect the network path, I use mtr; a port test and route analysis answer different questions.
SMTP authentication and TLS
SMTP AUTH lets a submitting client identify itself with a username and password. Authentication alone does not encrypt the connection. Sending credentials over an unencrypted session creates a risk of interception, so a sound configuration establishes TLS first and then uses one of the AUTH mechanisms offered by the server.
An application normally has these settings separately:
- SMTP hostname: for example,
smtp.example.com. - Port: 587 or 465, according to the provider’s instructions.
- TLS mode: STARTTLS or direct TLS.
- Username: often the complete email address.
- Password: an SMTP password or application-specific password.
- Sender address: an address permitted by the account or server policy.
Do not leave the password in plain text in a web application’s error log. Use environment variables or the application’s secret-configuration mechanism. File permissions should also allow only the web-service account to read the relevant secret. Running every command as root has a way of making a small mistake much more expensive.
Are SMTP, IMAP, and POP3 the same thing?
SMTP sends messages and transfers them between mail servers. IMAP and POP3 are used to access or synchronize messages that have already been delivered. Incoming mail can work while outgoing mail fails because the two directions use different protocols, ports, and authentication settings.
| Protocol | Primary job | Common ports |
|---|---|---|
| SMTP | Sending messages and transferring mail between servers | 25, 465, 587 |
| IMAP | Keeping messages on the server and synchronizing folders | 143, 993 |
| POP3 | Downloading messages to a client | 110, 995 |
I learned to treat mail changes as part of a wider system, not as isolated commands. Early in my hosting job, I restarted MySQL on what I thought was a test machine. It was production: twelve minutes of downtime and one very unhappy customer email. The rule that stayed with me was simple: check the hostname before pressing Enter. I apply the same caution here-take a snapshot before changing service configuration, and keep a tested copy of critical files. A snapshot is not a complete backup, but it can buy valuable time during an incident.
If an application sits behind a proxy or an upstream is unavailable, the troubleshooting approach in How to Fix a 502 Bad Gateway Error can help. The visible error may look similar, but a web server’s upstream connection and an SMTP server’s connection must be checked separately.
Where should you start when SMTP sending fails?
This is the order I use:
- Hostname and DNS: Is the SMTP hostname correct, and does it resolve to the right address? Check with
dig +short A smtp.example.comand, when appropriate,dig +short AAAA smtp.example.com. - Port access: Does the VPS provider restrict outbound port 25? Can the server reach 587 or 465 with
nc? - TLS mode: Is direct TLS selected for 465 and STARTTLS for 587? Does the certificate match the hostname?
- Credentials: Is the username the full address, is the password current, and is SMTP AUTH enabled?
- Sender policy: Are the
MAIL FROMandFrom:addresses allowed by the service and domain policy? - Server logs: Compare the application log with the SMTP server log for the same time window.
- DNS authentication records: SPF, DKIM, and DMARC can cause receiving servers to reject a message or place it in spam.
SPF, DKIM, and DMARC are not SMTP commands. They are additional mechanisms used to evaluate sending authorization and message integrity. If the SMTP session completes successfully but the message never reaches the inbox, the problem may be at this later layer.
If a message is sitting in the queue, do not restart the service immediately. Read the response code first. A 4xx response usually indicates a temporary problem or deferral, while a 5xx response usually indicates a permanent rejection; the explanatory text from the server is needed for a precise interpretation.
I used to restart the mail service whenever I saw a queue growing. That habit did not fix the cause; sometimes it only made the timeline harder to reconstruct. Read the log first, then intervene.
What should you configure on an SMTP server?
If you operate Postfix or another MTA, listening on a port is only the beginning. The server must be authoritative for its own domain, relay permissions must be restricted, the TLS certificate must be configured correctly, and the DNS records must agree with the server’s identity.
- Do not leave port 25 as an open relay. Allowing unauthenticated users to send to arbitrary domains creates a serious abuse risk.
- Run submission on port 587 with a separate policy and require authentication.
- For port 465, test direct TLS. For port 587, test the STARTTLS policy.
- Check that PTR, A or AAAA, MX, and, when needed, SPF records do not contradict one another.
- Monitor the mail queue, failed deliveries, and disk usage. A growing queue is often a symptom rather than the original fault.
- Do not merely create backups; test restoring mailboxes and configuration files.
An SMTP server is an internet-facing service. fail2ban and nftables can be useful for SSH and general filtering, but the mail service needs its own rate limits, relay rules, and authentication policy. Changing the SSH port is not security by itself, and changing the SMTP port will not solve a spam problem.
For certificate setup, How to Install an SSL Certificate on a VPS with Let’s Encrypt is a useful reference. The SMTP certificate may be the same certificate used by a web server, but each service still needs its own file paths and reload behavior checked after renewal.
When I’m configuring both sides of email delivery, I also refer to our guide, “What Is IMAP and How Do You Access It?“, to understand how messages are retrieved and synchronized across devices.
Frequently asked questions
Should an application use port 25 or 587 for SMTP?
An application or email client should normally use port 587 with STARTTLS. Port 25 is primarily used for delivery between mail servers, and VPS providers may restrict outbound connections on it.
What is the main difference between ports 465 and 587?
Port 465 establishes TLS at the beginning of the connection. Port 587 begins as SMTP and upgrades the session with STARTTLS. The application’s security mode must match the port.
Can SMTP be used to read email?
No. SMTP sends messages, while IMAP or POP3 provides access to incoming mail. Working outgoing-mail settings do not prove that incoming-mail settings are correct.
Why does email not arrive when the SMTP connection succeeds?
When an SMTP server accepts a message, delivery is not necessarily finished. SPF, DKIM, DMARC, the recipient server’s spam policy, queue delays, and the sender domain’s reputation can affect the next stage. Inspect the SMTP response and the relevant server logs together.
Sources
- RFC 5321 – Simple Mail Transfer Protocol — rfc-editor.org
- RFC 6409 – Message Submission for Mail — rfc-editor.org
- RFC 8314 – Cleartext Considered Obsolete — rfc-editor.org
- IANA – Service Name and Transport Protocol Port Number Registry — iana.org
Türkçe
English
فارسی
Русский