Simple Mail Transfer Protocol (SMTP) is a communication protocol used for send and forward emails from a sending application or server to another email server. SMTP is not the primary protocol for reading inboxes. To retrieve messages already stored in a mailbox, email applications typically use IMAP, POP3, or another access mechanism provided by the service provider.
SMTP works by exchanging commands and responses between devices. This protocol is relevant for office email users, domain administrators, website owners, and application managers who send notifications. Understanding SMTP helps explain why messages from websites fail to deliver, how to recognize the differences between ports 25/587/465, and why receiving a message by one server doesn’t necessarily mean the email has been read by the recipient.
What is SMTP and What is its Function?
SMTP stands for Simple Mail Transfer Protocol, a standard for sending email over a network whose basic specifications are set out in RFC 5321. Its core role is to move a composed message from one sending system to the next until it reaches the environment responsible for the destination domain.
A simple example: when a customer fills out a contact form on a website, the application can submit a notification to an authorized SMTP email delivery service. The service then processes the delivery or forwards the message to the destination server. In the context of a website built using dynamic web applications, SMTP is a component of outgoing communication, not a replacement for a database or application system.
The main function of SMTP
- Message submission: receive messages from clients or applications that have sending permission.
- Message relay: forward email between servers that play a role in the delivery path.
- Transaction status exchange: The server provides a response code to indicate whether a particular step was successful, rejected, or needs to be retried.
- Interoperability: provides standard communication rules so that different email systems can exchange messages according to supported policies and extensions.
SMTP doesn’t guarantee that all emails will reach the inbox, be spam-free, be read promptly, or pass every recipient’s policies. The quality of the sender’s address, the service’s reputation, domain authentication, and the destination server’s rules also affect the final outcome.
Components in an Email Delivery System
Mail User Agent (MUA)
An MUA is an application or interface through which users compose, send, and read messages, such as a desktop email application or webmail application. An MUA can submit messages to a submission service; the delivery implementation behind a modern application may use a different vendor-provided path.
Mail Submission Agent (MSA)
MSA receives messages from authorized users or applications. RFC 6409 separates the functions submission from relay to ensure that security policies and sender validation are properly implemented. Submission services typically connect to port 587 or 465, depending on the provider’s configuration.
Mail Transfer Agent (MTA)
The MTA processes message transfers between servers. In interdomain delivery, servers can use DNS information, including MX records, to find the system responsible for the destination domain. If delivery fails temporarily, the queuing and retry policies are determined by the system handling the message.
Mail Delivery Agent and mailbox
Once the receiving system accepts the message for local delivery, the storage/delivery component places the message in the appropriate mailbox or service. Implementations vary by provider. The user then reads the message through an application and access protocol such as IMAP. Understand that transfer, delivery, And read are different stages.
How Does SMTP Work?
1. User or application creates a message
A message has a sender, recipient, subject, content, and associated headers. The address shown in the header does not exactly match the entire envelope information used during transfer. Email services may implement rules to ensure the sender is authorized to use a specific address.
2. The client contacts the submission server
The client opens a connection to the correct SMTP host, using the port and security method required by the provider. In the typical model, on port 587, the client can negotiate using STARTTLS; on port 465, TLS is active from the start of the connection. Once a secure channel is established, the service may require authentication such as OAuth or another supported mechanism.
3. The client and server exchange SMTP commands
The protocol uses commands such as EHLO to introduce clients and negotiate features, MAIL FROM to determine the envelope sender, RCPT TO for the destination address, and DATA to send the message content. The server responds with a status code. Some commands or extensions are available only if advertised by the server.
Example of protocol flow illustration
EHLO client.example
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: Pengirim <[email protected]>
To: Penerima <[email protected]>
Subject: Pesan contoh
Ini hanyalah isi pesan simulasi.
.
QUITNotes: the above snippet only illustrates the conceptual sequence, No A safe script to paste directly into production configuration. Real sessions require server responses, TLS and policy-compliant authentication, and proper protocol format and terminators. Do not send passwords over insecure connections.
4. The sending server looks for a route to the destination domain.
The transfer system typically checks DNS to determine the destination server, including MX records if available. Hosts and IP addresses are used at the networking stage; for general context, see IP address function. In practice, DNS and email policies are different from DNS settings for websites or CDNs. Article DNS and IP on the website provides context for web infrastructure, not MX or email authentication tutorials.
5. The receiving server sends the status and processes the message.
The response code indicates the outcome of a stage. A 2xx response at the appropriate stage typically means the system accepted the task; a 4xx indicates a temporary problem that may require retry; and a 5xx indicates a permanent rejection at that stage. Messages received by the server does not mean they have appeared in the Inbox or have been read by a human.
6. The recipient opens the mailbox
Users retrieve messages through the provider’s application and access mechanism, rather than reading the mailbox contents via SMTP. If the recipient replies, a new message is sent via the appropriate submission and transfer channels.
Difference between SMTP Ports 25, 587, and 465
| Port | General uses | Security and records |
|---|---|---|
| 25 | SMTP relay between mail servers | Not the best default choice for user applications; outbound access is often restricted by network providers. |
| 587 | Message submission from client/application | Generally uses STARTTLS and authentication according to service policy |
| 465 | Message submission with implicit TLS | TLS starts immediately when the connection is opened; use only if supported by the provider. |
RFC 6409 specifies submission typically over port 587 and distinguishes it from relay over port 25. RFC 8314 describes the use of port 465 for implicit TLS and recommends protecting the connection between the client and the submission server. Real security depends on certificate implementation and validation, not just port numbers.
What is the relationship between SMTP and TLS and SSL?
TLS protects traffic while it passes over a successfully established encrypted connection. The term “SSL” still often appears on legacy interfaces, but modern configurations should follow the TLS supported by the provider. Encryption during transmission No the same as end-to-end encryption: the provider server or recipient system can still process the email content according to its architecture.
SMTP AUTH and OAuth are not the same thing
SMTP AUTH includes an authentication mechanism for submissions over SMTP; OAuth is one of the modern methods of obtaining authorization in implementations that support it. Microsoft explains that Exchange Online can use SMTP AUTH for certain applications and devices, but recommends disabling it if not needed. Don’t rely on legacy username/password instructions without checking your provider’s latest authentication policies.
Differences between SMTP, IMAP, and POP3
SMTP intended for message submission/transfer. IMAP provides a way for applications to access and synchronize email in server-managed mailboxes. POP3 supports email retrieval with a simpler model, depending on client and server settings. The three cannot be considered interchangeable because they have different functions.
If an email is successfully sent but doesn’t appear in the recipient’s application, the problem could be with cross-system delivery, spam filtering, mailbox storage, IMAP/POP3 access, or application settings. Troubleshooting should determine where the failure occurred, rather than simply changing the sending port.
Safe Steps to Configure SMTP for Website or Application
1. Determine the shipping destination
Does your website send contact forms, account verification links, invoices, system notifications, or marketing newsletters? For transactional emails, the reliability and accuracy of the sender’s identity are a priority. For marketing emails, consider recipient consent, frequency, unsubscribe management, and anti-spam policies. Example of an email marketing template can help plan message content, but does not configure SMTP.
2. Use an authorized delivery service
Ask for documentation on the SMTP host, port, TLS type, authentication mechanism, sending limits, and allowed From addresses. Don’t assume a host that works for one provider will work with another domain. If using WordPress, check for trusted and relevant delivery integrations; WordPress plugin explanation helps understand how modules add CMS functionality.
3. Store credentials safely
Don’t post SMTP passwords on public pages, published code samples, open repositories, or logs that are accessible to anyone. Use platform-appropriate secret/configuration management mechanisms, restrict access rights, and rotate credentials when suspected of being compromised.
4. Verify DNS and sender identity
For organizational domains, review MX and authentication mechanisms such as SPF, DKIM, and DMARC according to the provider’s configuration. SPF concerns sending server authorization; DKIM provides domain signatures; and DMARC helps recipients enforce policies based on authentication alignment results. These three do not replace TLS or user sending permissions. Server changes or DNS changes can impact email; see context of hosting migration with the same domain while noting that web hosting and email hosting can be separate.
5. Run end-to-end tests
Using a recipient address you know, send a test message with a unique subject line, then check the application status, available server logs, the recipient’s mailbox, and the spam folder (if applicable). Ensure the authentication headers are configured correctly. Don’t rely solely on the plugin’s “sent” notification if there’s no evidence the message was processed in the delivery path.
6. Monitor and isolate deliverability issues
Record the time, amount, transaction type, error code, and provider response without storing excessive sensitive information. If multiple messages fail, check for changes to the provider’s configuration, reputation, quota, domain, and policies before changing too many things at once.
Common SMTP Errors and How to Read Them
Authentication failed or 535
Incorrect credentials, authentication not allowed, or unsupported login method are some possible causes. Check whether the account is authorized to use SMTP AUTH, whether the token/permission is still active, and whether your organization’s security policy prohibits certain mechanisms. Avoid resending the same password without understanding the source of the problem.
Connection timed out or refused
Hosts, ports, firewalls, network provider restrictions, and inoperative services can all block connections. Check the host and network configurations according to the documentation. On hosting servers, blocking outgoing port 25 may be an anti-abuse policy, not an application error.
TLS handshake or certificate error
Problems can arise from mismatched hostnames, incorrect trust chains, incorrect system time, or incorrect encryption methods. Don’t disable certificate verification just to make the delivery appear successful; correct your TLS configuration and contact your provider.
Relay denied or sender not permitted
The service may reject messages that attempt to use a From or Destination address outside the account’s permissions. Use the correct domain, account, and relay policy. Not all servers accept public relays, and open relays pose a risk of abuse.
Message goes to spam folder or is invisible
A successful SMTP transaction on the previous server does not confirm final inbox placement. Check the recipient’s status, SPF/DKIM/DMARC configuration, message content, reputation, and filter rules. Do not manipulate headers to circumvent anti-spam systems.
The Relationship between SMTP and Websites, Business, and Email Marketing
Website notifications and marketing communications require appropriate delivery channels, but serve different purposes. Order confirmation emails must be understandable and delivered in a timely manner. Newsletters require legitimately acquired contact lists, useful content, and an unsubscribe mechanism.
In strategy digital marketing channels, email is a business-owned communication channel that requires permission management and message quality. Direct advertising discusses the direct promotion approach, whereas marketing personalization helps to craft messages based on relevant needs without collecting excessive personal data.
Marketing teams also need to distinguish the ability to deliver email from the ability to measure the impact of communications. Lead quality, follow-up, and business conversion require separate measurements; learn understanding leads And types of marketing conversions for this context. SMTP itself does not measure business success or prove that the recipient read the message.
FAQ about Simple Mail Transfer Protocol
Is SMTP free?
SMTP is a protocol standard, not a single service package. Email providers can offer submission services in free plans, paid plans, or as part of a hosting service with specific quotas and limitations.
Does port 587 always have to be used?
Not always. Port 587 is commonly used for submission with STARTTLS, while 465 is used for implicit TLS if supported. Choose based on the service documentation and applicable security policies.
Is SMTP the same as an email server?
SMTP is a communications protocol. An email server is software or a service that performs several functions, including submission, relay, mailbox storage, and user access. A single service can use more than one component.
Does successful sending mean the email has been received by the user?
No. The application can report success after a single server receives the message. Continued delivery, spam filtering, mailbox placement, or reading by the recipient are separate events.
Why is it not OK to use regular passwords in public instances?
Genuine credentials can be used by others to send unauthorized emails. Examples should use placeholders, and production systems should use the provider’s required secret storage and authentication.
Conclusion
SMTP is a fundamental part of the email delivery process. To understand it, differentiate between submit, relay, and mailbox access; use ports and TLS appropriate to the service; verify domain permissions and authentication; and then test the complete delivery path. Success at any one stage of the protocol doesn’t guarantee emails will arrive in the inbox, let alone be read. This approach allows website owners and technical teams to more accurately diagnose issues without taking shortcuts that compromise security.
Official References and Sources
- IETF RFC 5321 — Simple Mail Transfer Protocol, SMTP transfer and response standards.
- IETF RFC 6409 — Message Submission for Mail, separation of submission and relay and port 587.
- IETF RFC 8314 — TLS for Email Submission and Access, port 465 and TLS protection.
- Microsoft Learn — Enable or disable SMTP AUTH in Exchange Online, authentication and submission policies; reviewed on October 15, 2026.
