SMTP Ports, IMAP vs POP3, and Email Verification
SMTP sends email. IMAP and POP3 retrieve it. An email API asks a provider to send over HTTPS. Email verification can mean confirming that someone controls an address or estimating whether an address can receive mail. Each solves a different part of the email flow.
Resources
Port 25 is for relay between mail servers, not routine submission from an application or mail client. Start with port 587 unless your provider tells you to use port 465.
Protocol and port reference
Protocol and port
What it does
SMTP 25
Transfers mail between servers
SMTP 587
Submits mail with STARTTLS
SMTP 465
Submits mail over implicit TLS
IMAP 993
Synchronizes a remote mailbox
POP3 995
Downloads mail over TLS
What SMTP does
SMTP moves an outgoing message between systems. A sending application submits the message to a mail submission agent.
The sending system looks up the recipient domain’s mail exchanger, connects to the receiving server, and hands off the message. The recipient reads it through a mailbox protocol or web client.
SMTP does not decide whether a message reaches the inbox. Authentication, sender reputation, recipient engagement, content, and the receiving provider’s filtering all affect placement after the connection succeeds.
Port 25 is the standard relay channel between mail servers. Many networks restrict outbound port 25 because compromised machines abuse it for spam.
Do not treat it as the default application port. Port 587 is the standard submission port.
The client connects, upgrades the connection with STARTTLS, authenticates, and sends the message. Port 465 is also valid for submission, but TLS begins as soon as the connection opens.
Follow your provider’s documented host, port, and TLS mode instead of combining settings from different examples.
STARTTLS opens a connection and upgrades it to TLS before credentials or message content are sent. Implicit TLS encrypts the connection from the start.
Either mode can secure message submission when the client and server are configured for the same one. A frequent failure is selecting port 465 while the client expects STARTTLS, or port 587 while it expects implicit TLS.
The server and client must agree on the mode. Certificate validation should remain enabled in production.
IMAP keeps the mailbox on the server and synchronizes folders, read state, and message changes across devices. It is the usual choice for a mailbox that people read from a phone, desktop, and web client.
POP3 is built around downloading messages. It can leave a copy on the server, but it does not synchronize mailbox state the way IMAP does.
POP3 still works for simple collection and archival jobs. For a shared or multi-device inbox, use IMAP.
SMTP works with frameworks, devices, and older systems that already know how to submit mail. An email API uses HTTPS and may provide request validation, structured errors, templates, and delivery events through provider-specific endpoints.
For a new SaaS application, an API can make sends easier to observe and retry because the response and event formats are structured. SMTP remains useful for compatibility and for tools that only expose SMTP settings.
Both routes ultimately hand the message to the provider’s delivery infrastructure.
Address ownership verification confirms that a person controls an address, usually through a link or code. It belongs in signup, account change, and security flows.
Deliverability validation estimates whether an address has valid syntax and may accept mail. It can catch obvious mistakes and some invalid domains, but it cannot prove that a person wants the message.
Keep consent and bounce handling separate. Use double opt-in when your signup policy calls for it.
SPF names the servers allowed to send for a domain. DKIM adds a cryptographic signature that receiving servers can verify.
DMARC tells receivers how to handle messages that fail aligned SPF or DKIM checks and provides reporting. These DNS records authenticate the sending identity.
They do not replace TLS, and TLS does not replace them. Use encrypted transport for the connection and domain authentication for the message.
For most SaaS products, use an email provider instead of running a public mail server. Authenticate the sending domain, follow the provider’s API or SMTP instructions, keep credentials on the server, and process bounces and complaints.
Separate transactional and marketing streams when their sending patterns or consent rules differ. Classify messages before sending.
Password resets, receipts, and security alerts are transactional. Promotions and newsletters require marketing consent and unsubscribe handling.
A welcome message may be lifecycle marketing even though signup triggered it.
An immediate timeout often points to a blocked port or incorrect host. An authentication error usually points to credentials, account permissions, or the wrong submission method.
A TLS handshake error can mean that the port and encryption mode do not match. If the provider accepts a message but it later bounces or lands in spam, inspect delivery events and authentication rather than the SMTP connection alone.
Log the provider response and message identifier, but never log credentials or sensitive message data. Use delivery events to follow what happened after acceptance.
Use the protocol and port that match the job:
Authenticated submission: SMTP 587 with STARTTLS unless the provider specifies SMTP 465 with implicit TLS.
Server relay: SMTP 25.
Synchronized mailbox access: IMAP 993.
Simple download or archive: POP3 995.
New server-side SaaS integration: use the provider’s HTTPS API when structured errors and delivery events matter.
Loops supports an HTTPS transactional API and SMTP submission. Use the API for server-side product events when you want request validation and delivery events.
Use SMTP when an existing tool only accepts SMTP credentials. In both cases, configure the sending domain and follow the same deliverability practices.
Read the SMTP docs, transactional API docs, and email deliverability guide for implementation details.
Frequently asked questions
Which SMTP port should I use?
Is port 465 still valid?
Is IMAP better than POP3?
Does SMTP verification prove an address belongs to someone?
Primary references: RFC 5321 for SMTP, RFC 6409 for message submission, RFC 8314 for encrypted submission and access, RFC 9051 for IMAP, and the Loops SMTP and deliverability documentation.