What Is IMAP IDLE? How Push Email Works Over IMAP

If you have ever watched a new email appear on your phone the instant it was sent, you have probably seen IMAP IDLE at work. IMAP on its own is a request-and-response protocol: the client asks the server what has changed, and it only learns about new mail when it asks. IMAP IDLE is the extension that flips that around — it lets the client hold a connection open and wait for the server to speak first.

This guide explains what IMAP IDLE is, exactly how the command works, why it is per-folder and connection-hungry, and why it still is not the same thing as true mobile push. The mechanics are precise and worth getting right, because almost every complaint about slow email over IMAP traces back to one of them.

What is IMAP IDLE?#

IMAP IDLE is an optional IMAP extension, defined in RFC 2177 (published June 1997), that lets an email client tell the server it is ready to receive real-time updates about the mailbox it currently has open. Without it, the client has to poll — reconnect or send a check command on a timer — to find out that mail has arrived, been deleted, or had its flags changed. With IDLE, the client issues one command and then waits, and the server sends an unsolicited message the moment something changes.

The word "idle" is slightly misleading. The client is not doing nothing; it is holding a live connection open and listening. That listening state is what makes near-instant delivery possible, and it is also the source of every trade-off in the rest of this guide — a held-open connection costs a socket, watches only one folder, and can be dropped without warning.

How does IMAP IDLE work?#

The mechanics are simple by design. First, the server has to advertise that it supports the extension: it lists IDLE in its CAPABILITY response. If that keyword is missing, the client cannot use IDLE and falls back to polling. When IDLE is available, the client selects a mailbox — almost always the inbox — and then issues the IDLE command.

From there the exchange follows a fixed pattern. The server replies with a continuation response, "+ idling", which means the connection is now in the idle state. While the client waits, the server pushes untagged responses whenever the mailbox changes: "* 4 EXISTS" announces that the mailbox now holds four messages, an EXPUNGE response reports a deletion, and so on. When the client wants to act — to fetch the new message, or run any other command — it sends the single word DONE, and the server closes the command with a tagged OK.

RFC 2177 defines the whole command in one line of formal syntax: the client sends IDLE, and ends it with DONE. There is no tag on DONE, and the client must send it before issuing any other command. The connection stays open throughout, so once the client has handled an update it can immediately issue IDLE again. The example below traces one full round.

Why IMAP IDLE matters, and what breaks without it#

The problem IDLE solves is latency. Without it, a client can only discover new mail as often as it polls. Set the interval short — every minute — and you generate a lot of pointless network traffic and battery drain, because most checks find nothing. Set it long — every fifteen minutes — and mail can sit unseen for a quarter of an hour. Polling forces a choice between freshness and efficiency, and neither answer is good.

IDLE removes that trade-off for the folder it watches. The server stays quiet until something actually happens, then speaks immediately, so the client learns about new mail in seconds without hammering the server on a timer. That is why IDLE is the default for desktop mail clients and for the server-side sync engines behind many mobile apps: it is both faster and lighter than polling — as long as the connection holds. That last clause is the whole catch, and the next section makes the cost concrete.

IMAP IDLE vs polling#

Here is the contrast between the two ways a client can learn that mail has arrived. Polling asks on a schedule; IDLE waits to be told.

Why the difference costs battery and connections#

Two things about IDLE do not scale for free. The first is that IDLE watches exactly one mailbox — the one the connection has selected — because IMAP allows only one selected mailbox per connection. To get real-time updates on a second folder, the client needs a second connection, selecting and idling on that folder. Watch ten folders in real time and you are holding ten connections open, and most mail servers cap how many simultaneous connections one account may open, so this runs into a wall quickly.

The second is battery. A phone holding an IMAP IDLE socket open has to keep the connection warm and wake at least every 29 minutes to re-issue the command, plus whenever a push arrives — and it pays that cost for every account and folder it watches. That is why mobile operating systems steer apps away from holding their own sockets and toward a single, OS-managed push channel, where one system connection serves every app. IMAP IDLE gives you near-real-time mail, but it is not that OS-level push, which is the distinction people most often get wrong.

Common misconceptions about IMAP IDLE#

IDLE is widely used and widely misunderstood. A few points clear up most of the confusion.

• IDLE is not a push-notification service. It is a held-open connection that the app itself must keep alive; if the app is closed or the socket drops, nothing is pushed.
• IDLE does not watch your whole mailbox. It watches only the folder the connection has selected — usually the inbox — so mail filed straight into another folder will not trigger an update on the inbox connection.
• IDLE is not guaranteed. It is an extension, so a server has to advertise the IDLE capability; against a server that does not, the client has no choice but to poll.
• IDLE does not mean instant delivery on a phone. Sleep, NAT timeouts, and dropped connections all interrupt it, which is why battery-conscious mobile apps lean on OS push or a server-side connection rather than idling directly from the device.

How this shows up in AI Emaily#

AI Emaily uses IMAP IDLE in its sync engine, but with the connection where it belongs: on our servers, not on your device. For an IMAP mailbox, our sync workers hold the IDLE connection open and select the folder, so new mail reaches us within seconds of landing — and your phone gets one ordinary push instead of paying the battery cost of holding an IMAP socket open per folder. For providers with their own change notifications, such as Gmail and Outlook, we use those provider APIs rather than IMAP IDLE.

Either way, the moment a message arrives, AI Emaily's AI email assistant can triage it and draft a reply for you to approve. It is a client-side layer that rides on top of your provider's delivery, not a replacement for it, and we are upfront about that limit. We build AI Emaily; you can see the whole product on one page and check the plans, including a 7-day free trial with no charge if you cancel before day seven, on our pricing page.