IMAP and SMTP: How Email Reaches All Your Devices

When a user adds a work mailbox to a phone or desktop application, the app usually asks for two sets of settings: one for incoming mail and one for outgoing mail. Different protocols sit behind these fields. IMAP synchronizes mailbox content, while SMTP submits messages for sending.

Confusing them creates a familiar problem: messages are visible but cannot be sent, or sending works while new mail never appears. Diagnosis becomes easier when you look at the message route and the role of each connection instead of the application interface.

What IMAP does

IMAP provides access to messages stored on a server. A client retrieves folders, headers, and message content and sends state changes back: whether a message has been read, moved to another folder, or flagged.

Its defining feature is synchronization. Mark a message as read on a laptop and that state normally appears on the phone and in webmail. Move a message, and the client reports the change to the server. Applications and special folders may behave slightly differently, but the server mailbox remains the source of current state.

This differs from the older POP3 model, in which a client often downloaded messages locally and could delete them from the server. IMAP is generally better suited to modern multi-device work because correspondence is not tied to a single computer.

IMAP does not deliver a message from the sender to your domain. Another server first finds the mail host through the MX record and transfers the message by SMTP. Only after it is stored in the mailbox does the user see it through IMAP or webmail.

What SMTP is responsible for

SMTP is the protocol for transferring email. In a user's client it is used when they select Send: the application opens an encrypted connection to the outgoing server, authenticates, and submits the message.

The server then determines the next delivery step. It may transfer the message to the recipient domain's server or process it through a configured route. SMTP is used again between mail systems on the next segment. This is separate from reading the message over IMAP.

Business environments must distinguish two scenarios:

• authenticated sending by a user from an email client;
• sending by an automated system such as a website, CRM, accounting package, or notification service.

Do not put one user's mailbox credentials into every application without review. Automated systems can have different requirements for volume, frequency, return addresses, and domain authentication. Inventory and approve every sending source before switching the domain.

Why the server name, port, and encryption matter

A username and password are not enough. The client also needs a server name, port, and encryption mode. Exact values depend on the provider's configuration, so use the issued instructions instead of guessing from internet examples.

Encrypted IMAP commonly uses port 993. User submission commonly uses port 465 with TLS from the start or 587 with an upgrade to a protected connection. These are common industry patterns, not universal settings for every server.

The principle matters more than the number:

1. The server name must match the TLS certificate.
2. The connection must be encrypted.
3. Authentication must be enabled wherever the service requires it.
4. The full mailbox address is usually the username, but the instructions must confirm this.
5. Never bypass a certificate warning with “Connect anyway” before investigating the cause.

Mailcore provides webmail, IMAP, and SMTP for configured mailboxes. Clients receive instructions with the exact server names, ports, and safe encryption modes. Those settings should not be posted together with passwords in a shared team chat.

IMAP, SMTP, or webmail: what should you use?

Webmail is a useful control point. It runs in a browser and shows whether a message is present in the server mailbox. If a message appears in webmail but not in an application, the likely cause is synchronization, folder selection, or client configuration.

IMAP suits people who prefer Outlook, Thunderbird, Apple Mail, or a mobile app and want the same folders on every device. Those applications also need SMTP to send. The options are complementary: one person can use the browser and several IMAP clients at the same time.

Consider device security as well. A saved password gives an application access to the mailbox. A lost phone needs a screen lock, and access must be closed under a defined procedure when an employee leaves. A shared mailbox with one password for the entire team weakens accountability because it is difficult to establish who used the credentials.

How to diagnose a problem without making random changes

First determine which direction is failing. Do not change the password, port, DNS, and encryption settings simultaneously; afterward, you will not know what fixed—or broke—the connection.

Messages do not appear in the client

Open webmail first. If the message is there, check the internet connection, IMAP server name, port, encryption, and full username. Confirm that the correct folder is open and that no local filter is hiding it. Check the mailbox quota, because full storage can disrupt normal operation.

If the message is absent from webmail too, IMAP is probably not the cause. Check whether the mail server received it, whether the domain's MX is correct, and whether incoming filtering rejected it.

A message cannot be sent

Check SMTP independently of IMAP. An authentication error usually points to the username, password, or permitted sign-in method. A TLS error calls for checking the server name, the device's system time, and certificate trust. A rejection after submission may relate to recipient policy, reputation, or domain authentication.

If the problem occurs with only one recipient, save the complete server response. “It won't send” hides valuable details: a 4xx code generally indicates a temporary condition, while 5xx indicates a permanent rejection for that attempt. The codes do not prove a single cause, but they make diagnosis much faster.

It works on one device but not another

Compare settings character by character. The older device may have retained a previous password or server name. Check the application version and support for modern TLS. Remove and re-add the account only after confirming that messages are stored on the server and understanding what will happen to local folders.

How the protocols relate to email migration

Historical correspondence is often copied between mailboxes over IMAP when changing providers. This is a separate stage: changing MX routes new incoming messages but does not move existing folders. Copying speed and completeness depend on volume, source-server availability, and folder behavior. Mailcore creates an individual migration plan and quote after reviewing the source data. The sequence is covered in our business email migration plan.

After the switch, monitor both environments for an agreed period: where new messages arrive, whether copying has finished, and whether folders map correctly. A successful IMAP login does not prove that DNS is correct or that outgoing messages are deliverable.

Quick reference

IMAP provides access and synchronization, SMTP submits messages for sending, and webmail is an interface to the same server mailbox. A secure connection requires the exact server name, correct port, TLS, and individual credentials. When something fails, identify the direction and preserve the error text before changing one setting at a time.

If your company is still choosing a service, first review what makes up business email and list every application that will need to send. Client setup will then not turn into a search for forgotten systems after the domain switch.

Sources

• RFC 9051: Internet Message Access Protocol (IMAP4rev2)
• RFC 5321: Simple Mail Transfer Protocol
• RFC 8314: Cleartext Considered Obsolete for Email Submission and Access
• Mozilla Support: Manual account configuration