IMAP vs SMTP: which one sends, which one reads, and what an agent needs

Core differences

SMTP pushes a message from a client to a server, and between servers, until it reaches the recipient's mail system. IMAP pulls messages from a mailbox to a client and keeps the two in step.

SMTP is the outbox path and ends the moment a receiving server accepts the message. IMAP is the inbox path and begins after delivery has already happened.

SMTP is stateless with respect to the message once transmitted, so it has no concept of read, unread, filed or deleted. IMAP maintains exactly that state on the server, which is why the same mailbox looks identical on a phone and a laptop.

Ports differ accordingly. SMTP submission uses 587 with STARTTLS or 465 with implicit TLS. IMAP uses 993 with implicit TLS, or 143 with STARTTLS. The SMTP ports guide explains why 587 and 465 are the submission ports.

A mail client needs both configured. One set of settings sends, the other receives, and a client with only outgoing settings will send successfully while showing an empty inbox.

What changes when an AI agent needs to send and read email

An agent asked to send order notices and answer the replies tends to copy the setup a mail client uses. It opens an SMTP connection for the outbound half, an IMAP connection for the inbound half, and signs both in with one mailbox password. That works for a person at a desk. It works badly for a process that runs unattended.

• Polling. The agent checks the inbox over IMAP every minute, because it has no other way to learn that a reply arrived. Most checks find nothing, and a dropped connection looks exactly like a quiet inbox.
• A full mailbox password in agent memory. The same password reads every message in the mailbox and sends as the account owner, which is far more access than sending a shipping notice needs.
• Bounces parsed out of a mailbox. The agent learns that a message failed by finding a bounce notice among the replies and reading its text, instead of receiving a delivery event it can act on.

The alternative splits the two directions by job rather than by protocol. Sending goes through the email API or the Nitrosend MCP server, signed in with an API key instead of a mailbox password. Replies land on the agent inbox on your own domain and reach the application as an email.received event through email webhooks, so nothing has to poll.

When an agent operates an email account, the choice turns on where approval is enforced and how much the agent can do without it, and the lowest permission that does the job wins. A mailbox password is close to the highest permission an email account has.

George Hartley, Co-founder of Nitrosend, has said an agent triages his inboxes while he still reviews and sends his one-to-one emails himself, a middle ground he does not expect to last long.

POP3 as the alternative to IMAP

POP3 is the older retrieval protocol, in RFC 1939, and it downloads messages rather than synchronizing them.

The distinction matters when more than one device is involved. POP3 traditionally removes messages from the server after download, so a message read on a laptop may never appear on a phone. IMAP leaves the authoritative copy on the server and mirrors it everywhere.

POP3 uses port 995 with implicit TLS, or 110 with STARTTLS. It remains reasonable for a single-device setup that wants local copies, and it is the wrong choice for anything else.

Server settings in a mail client

Configuration is two blocks. The outgoing block takes the SMTP host, port and security mode, and its incoming counterpart takes the IMAP or POP3 equivalents.

Provider hostnames follow a convention rather than a rule: smtp.provider.com for sending, imap.provider.com for retrieval. The values come from the provider's own documentation, since they vary and a guessed hostname fails at connection.

Authentication is required on both, and providers such as Gmail issue application-specific passwords rather than accepting an account password from a third-party client.

The actual host and port pairs for common providers are in the IMAP and SMTP settings guide.

Why this distinction matters for sending applications

An application that sends email needs SMTP or an HTTP API, and needs IMAP for nothing at all. Confusion between the two produces integrations that request mailbox access for a system that only ever transmits.

The exception is a system that must read replies, such as a support tool threading conversations or a sequence tool detecting responses. Reading an existing mailbox, such as a person's Gmail or Outlook inbox, is an IMAP or provider-API job, through Gmail's API, Microsoft Graph, or IMAP directly. Receiving replies on your own domain is a different case.

Nitrosend is not a mailbox server and has no IMAP surface. Every account has an agent inbox that receives mail on your own domain and posts it to your application through the email.received webhook, with threads readable over REST and through nitro_inbox.

For the sending half of that split, an application or agent does not need to pick a protocol by hand at all. Nitrosend handles sending through its transactional email API, its MCP server and its CLI. An agent in Claude, ChatGPT, Cursor, Codex or Gemini CLI describes what to send, and it never has to hold a mailbox password to do it.

Worked example: an agent handles replies to a shipping notice

The prompt, in a store owner's words: Email each customer when their order ships, and draft answers when they reply asking where the parcel is.

Before, unguided, the agent saves the shop's mailbox password, sends each notice over SMTP on port 587, and runs an IMAP loop on port 993 that reads the whole inbox every minute, looking for customer replies and bounce notices in the same folder.

After, with the two directions split and a person approving what goes out:

1. nitro_get_status confirms the account is ready and shows which sender identity the shipping notices will carry.
2. nitro_manage_template creates the shipping notice as a reusable template that every order will use.
3. nitro_review_delivery looks over the shipping notice template before the first parcel ships. It flags validation problems and spam signals, runs preflight and renders previews, and it sends nothing.
4. nitro_send_test_message delivers one copy of the notice to the shop's own test address, the one held in nitro_configure_account, so a person can open it and click the tracking link.
5. A person reads that test and signs off on the template. Only then does the app wire up live sends.
6. nitro_send_message sends each customer's notice when the order ships, with the order ID as the idempotency_key, so a retried event from the store cannot produce a second notice for the same parcel.
7. A customer replies. The reply lands on the agent inbox on the shop's domain and reaches the app as an email.received event. The agent matches the order number in the thread and drafts an answer with the current tracking status.
8. A person approves the drafted answer, and the app sends it with nitro_send_message.
9. nitro_get_insights shows how the shipping notices perform over time, with trends and recommendations.

The change in one line: before, one mailbox password did everything and a loop watched the inbox. After, notices go out through an API key, replies arrive as events, and a person sees the template and every answer before a customer does.

Where it goes wrong when an agent mixes IMAP and SMTP

• IMAP credentials reused for SMTP submission. The agent copies the username, password and host from the incoming block into the outgoing one, the submission server refuses the login during the AUTH command, and the send fails with 535. Retrying the same pair in a loop only adds failed logins. The fix is covered in SMTP authentication.
• An IDLE connection that drops silently. IMAP IDLE holds a connection open so the server can push new mail, but a network change or a server timeout can close it without an error the agent notices. The inbox looks quiet while customer replies go unread.
• Bounces detected by scraping the inbox. A bounce notice is an ordinary email in provider-specific wording. An agent that searches the inbox for words like "undeliverable" misses some failures, mistakes some real replies for bounces, and keeps sending to addresses that no longer exist.
• One agent inbox expected to route many addresses. An agent told to answer mail for support, orders and returns may assume a single agent inbox catches every address by pattern. It receives on one address at a time and has no pattern routing, so mail sent to the other addresses never reaches it.
• A mailbox password left in code or logs. The password an IMAP loop needs ends up in a config file, a prompt or a log line, where it grants full read and send access to anyone who finds it.

FAQ

Go deeper