A protocol for reading email from a mailbox — a fallback way to pull customer mail into tickets when forwarding or webhooks aren’t available.
IMAP polling is the belt-and-suspenders option when you can’t forward or webhook a mailbox.
How it works
IMAP (Internet Message Access Protocol) lets a client read and manage mail that stays on the server, rather than downloading and deleting it. A help desk connects to the mailbox with credentials, periodically checks for new messages, fetches them, and turns each into a ticket. Because it polls on an interval, new mail appears within a minute or two rather than instantly — fine for most support, but not the same as a real-time push.
When to use it
IMAP is the fallback when the cleaner options aren't available. Forwarding a support address to the help desk, or receiving mail via a webhook from your provider, both deliver mail the instant it arrives. Reach for IMAP when you can't change MX or forwarding rules — for example, a shared mailbox on a legacy server you don't fully control, or a team that wants to start pulling history out of an existing inbox before committing to forwarding.
Common pitfalls
- Polling delay: messages arrive on the next cycle, not in real time.
- Authentication: many providers now require app passwords or OAuth instead of the raw account password.
- Read state: if agents also open the mailbox directly, the desk and the human can fight over what's already been seen.
- Loops: forwarding and IMAP on the same mailbox can re-ingest the same mail twice if not deduplicated.
A team migrating off an old shared mailbox often starts with IMAP to pull existing threads into tickets, then switches to forwarding once routing is set up — using IMAP as a bridge, not a permanent channel.
How Cherryrise handles it
Cherryrise prefers forwarding and provider webhooks for live mail, and offers IMAP as a fallback for mailboxes you can't reconfigure. See the integrations options for connecting an existing inbox.