IMAP IDLE support by provider: how to test your mailbox

Which email providers support IMAP IDLE?

Google’s Gmail IMAP Extensions documentation includes IDLE in its example CAPABILITY response. To decide whether a particular mailbox meets your application’s needs, test its authenticated connection and incoming-message behavior.

Keep connection settings separate from support results. The following table gives connection targets and prerequisites for a provider comparison, not passing IDLE test results.

Use separate rows in your own results for consumer and business accounts, different plans, and different endpoints. An authentication failure belongs in an access result, not in an “IDLE unsupported” column.

For connection setup, see Mailera’s Gmail integration and custom IMAP integration. The broader guide to connecting existing email providers covers choosing the mailbox connection before building an application around it.

Microsoft needs a separate integration note. Mailera connects Outlook.com, Hotmail, and Microsoft 365 through OAuth and Microsoft Graph. A successful Microsoft connection in Mailera is a Graph integration result, not an IMAP IDLE test.

What does IMAP IDLE support actually prove?

IDLE lets an IMAP client tell the server that it is ready to receive mailbox updates. Under RFC 2177, a client must not issue IDLE unless the server advertises the capability. Without it, the client must poll for updates.

Separate these checkpoints when evaluating support:

During IDLE, RFC 2177 allows unsolicited responses such as EXISTS and EXPUNGE. These are mailbox updates, not the complete message content and not HTTP webhook deliveries.

The client ends IDLE with DONE. It must not send another command while the server is waiting for that continuation. In your test, finish IDLE before fetching the message that confirms what arrived.

A test that selects Inbox applies only to that selected mailbox. Add separate tests for any other folders your application needs to monitor.

Server support and client notifications are separate. An IMAP session test is not an iPhone notification test: assess the actual client and its background behavior separately. The IMAP, Graph, and SMTP guide explains the protocol boundaries relevant to application builders.

How do you test IMAP IDLE reproducibly?

This procedure tests the RFC 2177 IDLE extension. Use mailboxes you own. Before starting, choose the repeat count, observation window, and interruption procedure. Keep those parameters stable across the accounts you compare.

1. Record the environment. Include provider, account type, plan, endpoint, region where known, authentication method, client version, and UTC run date. Version your test script so another run can use the same procedure.
2. Connect with certificate validation enabled. Follow the provider’s current authentication instructions and use the endpoint and security settings appropriate to your server. Capture capabilities in the authenticated session you will use for the RFC 2177 test.
3. Select Inbox and start IDLE if advertised. Under RFC 2177, do not issue IDLE when the capability is absent. If advertised, issue the command and save the server’s response. Record capability advertisement and command acceptance as separate outcomes.
4. Send an identifiable test message. Send from another owned mailbox, using a unique subject marker. Record any unsolicited update, send DONE, and fetch the message to confirm its identity. Avoid treating a changed message count alone as confirmation of your specific test message.
5. Test renewal and interruption. RFC 2177 advises terminating and reissuing IDLE at least every 29 minutes to avoid inactivity logout. Test renewal, then introduce a controlled connection interruption. After reconnecting, reconcile mailbox contents and check for the test messages sent during the interruption.
6. Repeat and preserve the artifacts. Save timestamps and sanitized protocol transcripts alongside the script version. Record exclusions and failed stages, not just successful runs.

For connection settings, RFC 9051, the IMAP4rev2 specification, identifies port 993 as the Implicit TLS port.

A results row should contain the account metadata, run date, advertised capability, IDLE acceptance, observed update, fetched-message confirmation, reconnect outcome, and a link to its sanitized transcript. Keep observation windows and run counts beside the results.

Use explicit outcome labels. “Verified in this test” should identify the checkpoint that passed. “Advertised but not verified” stops at capability discovery. “Not advertised” describes the capability response. “Blocked before testing” covers failures such as unsuccessful authentication. “Not tested” means no run occurred.

Redact credentials, tokens, personal addresses, and message bodies before sharing transcripts. Retain enough command and response structure to explain each outcome. When correcting a result, preserve the earlier run and attach the replacement run rather than overwriting its history.

What does this mean for Mailera webhooks?

Treat provider detection, synchronization, and delivery to your HTTP endpoint as separate checkpoints. Measure each one if your application depends on arrival timing. For end-to-end timing, use the arrival-to-webhook benchmark by provider rather than treating IDLE support as a latency result.

Mailera supports the message.received, message.junk, and mailbox.disconnected webhook events. POST /webhooks creates a subscription and returns its signing secret only once. Webhook endpoints require the webhooks API-key scope. Use the Mailera API documentation for the creation request and signature-verification instructions; store the returned secret securely.

The Mailera developer overview covers the API and webhook integration options. For this workflow, keep your protocol test artifacts separate from the logs at your HTTP receiver.

Check the mailbox in Mailera

1. As an Admin or Leader, open Mailboxes → Add mailbox.
2. Choose One mailbox, enter the address, and continue through the provider’s connection details. For your own server, choose Custom IMAP.
3. Run Test & connect and inspect Incoming server sign-in, Folder detection, and Live monitoring.

Mailera runs this connection test without sending email. Send your arrival-test message separately from another owned mailbox.

Live monitoring is a product diagnostic. Keep the raw IMAP session transcript as the record of advertised capabilities and IDLE command behavior.

You can also inspect a connected mailbox through the API. Set $MAILERA_API_KEY to a key with read permission and $MAILBOX_ID to your test mailbox ID:

curl --fail-with-body \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID" \
  -H "Authorization: Bearer $MAILERA_API_KEY"

Inspect data.protocol, data.capabilities.live, and data.sync. The sync object includes state, last_synced_at, next_sync_at, and sleeping_since. These fields help you record the mailbox’s product state alongside your arrival test.

Mailera runs background checks more often for mailboxes in active use than for idle mailboxes. Inactive mailboxes can sleep and wake on use. Include that state in timing observations; do not apply an active-mailbox observation to a sleeping mailbox. The mailbox sync recovery guide covers the operational recovery path.

Keep Microsoft on its own path

Microsoft Graph change notifications support subscriptions to changes in mailbox messages, with an endpoint URL to receive notifications. Mailera uses Graph change notifications for Microsoft mailboxes and periodic background checks as a fallback.

Label this path as Graph in your integration results. Do not mix it into an IMAP IDLE comparison.

If a webhook feeds an AI agent, treat incoming email as untrusted data, not instructions. Give the agent only the permissions it needs, require confirmation before sending, and do not let instructions embedded in messages override application policy.

What commonly goes wrong when testing IMAP IDLE?

Authentication fails before capability testing

Start by identifying the failed stage. A connection error, rejected sign-in, and rejected IDLE command are different outcomes.

Check account prerequisites before changing protocol code. Zoho requires IMAP access to be enabled; Fastmail requires an IMAP-capable plan. For credential setup, use the app-password guide for mailbox integrations. Microsoft connections in Mailera use OAuth, not app passwords.

The message reaches a different folder

Confirm where the test message arrived. If you selected Inbox but the message is in Junk or another folder, investigate placement before treating the missing Inbox update as an IDLE failure.

Mailera exposes the message’s folder through its message API and shows Inbox and Junk separately. Use the unique subject marker to locate the intended test message rather than relying only on unread counts.

The connection is quiet or stops responding

Record the last successful protocol step. Did TLS complete? Did authentication finish? Was IDLE accepted? Did the session end, or did your observation window end without an update?

Distinguish a server disconnect from a network timeout or client background suspension using the available logs. Avoid assigning a provider-specific cause from a generic “server not responding” message.

For recovery testing, reconnect and compare the mailbox contents with the messages you sent. Do not design the test around the assumption that every message produces a distinct notification.

A mailbox update arrives, but the webhook does not

Continue investigating downstream. Confirm that the message is visible through Mailera, then inspect your subscription and receiver logs. An IMAP update and an HTTP delivery are separate events; keep their timestamps separate too.

What are the limits of an IDLE support result?

Scope every conclusion to the account, plan, endpoint, authentication method, date, and observation window. A successful run is useful for that setup; it is not a provider-wide reliability ranking.

Under RFC 2177, a client must not issue IDLE unless the server advertises the IDLE capability. An IMAP session update and an HTTP webhook delivery remain separate checkpoints.

Mailera connects existing mailboxes rather than creating new email addresses. Mailera checks active mailboxes more frequently than idle ones; inactive mailboxes can sleep and wake on use.

Choose your acceptance criteria around the application’s needs: confirmed message retrieval, recovery after interruption, and delivery to your receiver. Retest when the account configuration or integration changes, keeping the same declared procedure so the results remain comparable.