What Are IMAP Message Flags? Seen, Answered, Flagged

IMAP message flags are per-message state bits stored on the mail server. They record what has happened to each message — whether it has been read, replied to, starred, or queued for deletion — and that state syncs across every client connected to the same account. Six flags are defined by the IMAP standard itself; they are the reason reading a message on your phone marks it read in your desktop client too.

Flags run silently beneath everything your inbox does. They also explain several behaviors that confuse people: why deleted messages still appear in a folder, why starring a message in one app shows as a flag icon in another, and why certain per-app markers never follow you across clients. The answers are all in the flag model.

The six IMAP system flags and what each one does#

Every IMAP message carries a list of flags in its server-side metadata. When a client reads, stars, or deletes a message, it sends a flag-setting command to the server, and every other client that opens the mailbox gets the updated state. No client stores the authoritative copy — the server does.

The six system flags are defined in RFC 3501 (IMAP4rev1) and carried forward in RFC 9051 (IMAP4rev2). They are identified by a leading backslash to distinguish them from user-defined keywords. All six are settable by any client except \Recent, which the server alone controls.

Why deletion in IMAP is a two-step process#

The most confusing thing about IMAP deletion is that marking a message \Deleted does not remove it. The flag tells the server the message is a candidate for removal, but it stays in the folder — visible to all clients, sometimes shown struck through, sometimes hidden by a client-side filter — until an EXPUNGE command is issued. EXPUNGE is the second step that permanently removes every \Deleted message from the selected folder.

This design is intentional. IMAP was built for a world where multiple clients connect to the same mailbox simultaneously. Immediate deletion would create race conditions: one client could remove a message while another was still reading or referencing it. The flag-then-expunge model lets all connected clients negotiate deletion cleanly before the server discards anything.

Different clients handle the timing of EXPUNGE differently. Some issue it immediately after flagging. Others wait until you close a folder, empty trash, or explicitly confirm. Gmail's web interface takes a different approach entirely: it moves messages to a Trash folder rather than setting \Deleted at all, managing deletion through folder moves rather than flags. That is one reason deletion behavior can feel inconsistent when you switch between a native IMAP client and a webmail interface.

System flags versus user-defined keywords#

Beyond the six system flags, IMAP supports user-defined keywords — arbitrary strings a client or server can attach to a message alongside the standard flags. Keywords use the same per-message flag list, but they have no leading backslash and no meaning defined by the IMAP standard. A keyword is just a string: $Forwarded, $Junk, Junk, Promotions, or whatever a client chooses to write.

This is where cross-client compatibility breaks down. System flags are guaranteed to mean the same thing on every IMAP implementation — every server and client reads \Seen the same way. Keywords carry no such guarantee. A keyword one client writes may be ignored, displayed as raw text, or interpreted as a folder label by another. Gmail's category tabs (Promotions, Updates, Forums) and its Importance marker are all keywords. They only render meaningfully inside Gmail; a plain IMAP client sees them as opaque strings.

Common misconceptions about IMAP flags#

Stars and flags do sync across apps — if both apps write the same flag. The \Flagged system flag is what most mainstream clients call a star or flag: Gmail's star, Outlook's flag, and Apple Mail's flag all write \Flagged to the server. Where clients differ is how they display it — one renders a yellow star, another a red flag, another a pin icon. They are reading the same bit on the server; they draw it differently. If a message appears starred in one client and unflagged in another, check whether both apps are actually writing \Flagged or one is writing a proprietary keyword instead.

Importance and category markers usually do not sync. Gmail's Importance marker and its category tabs are Gmail-proprietary keywords. Outlook's Focused Inbox classification is client-side logic that never writes to the server at all. Neither travels to a non-Gmail or non-Outlook client. These are features built on top of the IMAP protocol, not part of it.

The \Recent flag is unique and easy to misread. Unlike the other five system flags, \Recent cannot be set or cleared by any client — only the server sets it, exactly once, when a message first arrives in a mailbox. The first session to open the mailbox after a message arrives sees it as \Recent; every subsequent session does not. Its practical usefulness is limited in modern usage, and RFC 9051 removes it as a meaningful concept — but it still exists in IMAP4rev1 deployments, so you may encounter it in server responses.

How AI Emaily works with IMAP message flags#

AI Emaily reads and writes IMAP message flags as part of its triage layer. When the AI agent marks a thread read, prioritizes a message, or moves it out of the inbox, it sets the corresponding server-side flags — \Seen, \Flagged, \Deleted — so the state appears consistently across any other client you have connected to the same account. The AI's triage decisions are reflected in standard protocol state, not a proprietary layer visible only inside AI Emaily. We build AI Emaily; you can connect your existing IMAP mailbox directly at aiemaily.com and see how the AI handles flag-based state in practice.