IMAP and SMTP

What each protocol does

The Simple Mail Transfer Protocol moves a message from a client to a submission server and then between mail servers until it reaches the recipient's destination. It is a push protocol, defined in RFC 5321, and it terminates once the receiving server accepts responsibility for the message.

IMAP, the Internet Message Access Protocol, gives a client access to messages already stored on a server. It is a retrieval and synchronization protocol, defined in RFC 9051, and it leaves messages on the server rather than transferring ownership of them to the client.

The consequence of leaving messages server-side is synchronization. Folders, flags and read status live on the server under IMAP, so marking a message read on a phone shows it as read on a laptop, which is the behavior that distinguishes IMAP from POP3.

The ports each uses

Submission over SMTP uses port 587, defined as the message submission port in RFC 6409, where the client authenticates and upgrades the connection through STARTTLS. Port 465 carries the same submission traffic over an implicitly encrypted connection.

Relay between mail servers uses port 25. That port is for server-to-server transfer rather than client submission, and it is widely blocked on consumer and hosting networks precisely to stop clients using it directly.

Secure IMAP uses port 993, an implicitly encrypted connection registered with IANA for that purpose. Port 143 is the cleartext IMAP port, which upgrades through STARTTLS where the server supports it.

Why a sending application needs only one of them

An application that sends email needs SMTP and does not need IMAP. Sending is a submission operation, and nothing about it requires reading a mailbox.

IMAP becomes relevant only where an application must read incoming mail, such as processing replies or polling a shared inbox. That is a mailbox-access problem rather than a sending problem, and it is served by a different class of product.

Conflating the two produces a predictable configuration error. Entering IMAP settings where a client expects SMTP settings fails at connection time, because the server on 993 does not speak the submission protocol.

This boundary is a product decision for us, not an oversight. Nitrosend is not a mailbox server, and there is no IMAP surface to configure. Its agent inboxes receive mail on your own domain and hand it to your application over a webhook and REST. My way of putting the underlying point is that we are not inventing a new communication protocol here, it is all email, and the discipline that follows is picking which half of it you are actually in.

Reading a mailbox is a different product with different risks, and treating an inbox as something an application logs into is where a lot of otherwise sound architecture goes wrong. A sending system needs credentials to submit; it does not need standing access to a person's mail. Those are not the same request, and conflating them is how a send integration quietly becomes a mailbox integration.

Authentication differs between them

Both protocols authenticate, and both increasingly reject account passwords. Google blocks account passwords for third-party clients on accounts with two-step verification, and Microsoft has been retiring basic authentication for client access, so an app password or an OAuth token is the working credential on major providers.

The credentials are not necessarily interchangeable. A provider may issue one app password that covers both protocols or scope credentials per protocol, so the provider's own documentation determines whether one value configures both.

Encryption is mandatory in practice on either protocol. Both carry credentials in a form that is encoded rather than encrypted, so a session without TLS exposes the password to anyone on the path.

What neither protocol governs

Neither protocol determines whether a message reaches an inbox. SMTP defines how a message is transferred and accepted, not how a receiving system files it, and the filtering decision happens after acceptance.

Placement is decided by domain authentication and sender reputation. SPF, DKIM and DMARC are DNS-published records evaluated by the receiver, and they sit outside both protocols entirely.

Delivery status is also outside SMTP's scope for the sender. A message accepted at the SMTP conversation can still bounce afterwards or land in a spam folder, so acceptance is not confirmation of delivery.

That blind half is checkable from outside the protocols. We built deliverability checks into Nitrosend that read a domain's SPF, DKIM and DMARC configuration and report bounce rates, the layer neither IMAP nor SMTP will ever show a client.

None of that authentication and bounce-rate checking is something I want a person running by hand between sends, and it is not something an AI agent should have to reason about either. It is why an agent describing an email to Nitrosend gets the SPF, DKIM, DMARC and bounce-rate picture built into the send, not bolted on afterward by a script that only ever spoke the SMTP half of the story.

Go deeper