What this RFC defines
RFC 4551 defines CONDSTORE (Conditional STORE), an IMAP extension for performing atomic conditional flag updates. It introduces the MODSEQ value (modification sequence number) that increments with every mailbox change, allowing clients to detect concurrent modifications and perform flag updates only if the mailbox state has not changed since they last synced.
Where you see it in practice
When two email clients (desktop and mobile) are connected to the same IMAP mailbox simultaneously and both try to mark the same message as read at the same time, CONDSTORE prevents race conditions by ensuring the flag update is only applied if the expected MODSEQ matches the server’s current value. Without it, concurrent clients can overwrite each other’s changes. This is particularly important for high-volume enterprise mailboxes with multiple active sessions.
How it connects to other RFCs
RFC 4551 is an extension to RFC 9051 (IMAP). It works alongside RFC 2177 (IDLE) for real-time synchronisation. RFC 7162 extends CONDSTORE with Quick Resynchronisation (QRESYNC) for efficient reconnect after a disconnection. Together these extensions make IMAP suitable for multi-device, high-frequency mailbox access.
Current status
RFC 4551 is a current standard, published June 2006. CONDSTORE is widely supported by major IMAP servers including Dovecot and Cyrus and is particularly important for mobile and multi-device email clients that need reliable concurrent access to shared mailboxes.
The CONDSTORE extension
RFC 4551 defined the CONDSTORE (Conditional STORE) extension for IMAP, allowing clients to detect and prevent conflicting simultaneous updates to messages. Every message and mailbox gets a modification sequence number (MODSEQ) that increments on each change. A client can fetch messages “since MODSEQ X” to get only what has changed since it last synchronized, and can issue STORE commands conditional on the current MODSEQ matching what it expects. If two clients try to update the same message, one will see a MODSEQ mismatch and can refresh instead of overwriting.
Where CONDSTORE matters
CONDSTORE matters most for multi-device usage: your phone marks a message as read, your desktop is running IMAP IDLE, and both need to converge on the correct state. Without CONDSTORE, syncing across devices requires expensive full-folder refreshes. With CONDSTORE, each device tracks the last MODSEQ it saw and only fetches deltas. Modern email clients like Apple Mail, Thunderbird, and mobile clients rely heavily on CONDSTORE for efficient synchronization.
Related extensions
CONDSTORE laid the groundwork for QRESYNC (RFC 7162), which extends the concept to include vanished (deleted) messages and further optimizes reconnect scenarios. Any modern IMAP server (Dovecot, Cyrus, Google IMAP, Microsoft IMAP) supports CONDSTORE. If your IMAP client seems slow or shows outdated state after switching devices, either the client or the server may not be using CONDSTORE effectively, and enabling it in the client settings often improves performance dramatically.
RFC 4551 (June 2006) defines IMAP CONDSTORE (Conditional Store): an extension that lets clients efficiently sync only changes since a specific point in time. Introduces the MODSEQ (modification sequence) number per message, monotonically increasing on any change (new flag, edit, etc.). Clients query “give me all changes since MODSEQ N” instead of enumerating the mailbox. Critical for large mailboxes on multi-device deployments. Widely supported by Gmail, Microsoft 365, Dovecot, Cyrus. Superseded by RFC 7162 which combines CONDSTORE with QRESYNC.
RFC 4551 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Efficient sync of mailbox changes without full enumeration |
| Advertised as | CONDSTORE in IMAP CAPABILITY |
| Key concept | MODSEQ: monotonic modification sequence per message |
| Client action | Track HIGHESTMODSEQ; fetch changes since it |
| Update | RFC 7162 combines CONDSTORE with QRESYNC (quick resync) |
| Published | June 2006 |
The MODSEQ concept
CONDSTORE dialogue example
Common CONDSTORE mistakes
CONDSTORE before issuing MODSEQ-based commands. If not supported, fall back to full enumeration on sync.Related standards and further reading
- RFC 3501 IMAP Guide: base IMAP protocol
- Email Protocols and Ports Guide: IMAP configuration
Frequently asked questions
What is MODSEQ and why does it matter?
MODSEQ (modification sequence) is a monotonically increasing number attached to each message and to the mailbox as a whole (HIGHESTMODSEQ). Any state change (flag set, edit, expunge) increments HIGHESTMODSEQ. Clients that store their last-observed HIGHESTMODSEQ can query the server for “everything changed since MODSEQ N” instead of enumerating the full mailbox. For large mailboxes (100K+ messages), this is the difference between usable and unusable sync performance.
Should I implement CONDSTORE or QRESYNC?
QRESYNC per RFC 7162. It extends CONDSTORE with efficient expunge handling during offline periods. RFC 7162 combined and updated the two extensions in 2014, effectively superseding RFC 4551. Client libraries handle either; check server CAPABILITY for QRESYNC first, fall back to CONDSTORE if only that is available, fall back to full enumeration if neither.
Why does my IMAP client show slow sync on large mailboxes?
Likely not using CONDSTORE effectively. Without CONDSTORE, the client must re-enumerate every message on every sync (FETCH FLAGS for all N messages). With CONDSTORE, it fetches only changes since last sync. Check: (1) does the server advertise CONDSTORE? (Gmail, Microsoft 365, Dovecot yes), (2) does the client use CHANGEDSINCE? (modern IMAP libraries yes), (3) does the client persist HIGHESTMODSEQ across sessions? If any step is missing, sync degrades to full enumeration.
What happens if UIDVALIDITY changes?
All UID and MODSEQ tracking are invalidated. UIDVALIDITY changes when the mailbox is recreated or migrated (server maintenance, provider switch). The client must discard local UID/MODSEQ state for that mailbox and re-enumerate from scratch. Check UIDVALIDITY on every SELECT; if it differs from the previously observed value, do a full sync before resuming incremental.
Do all IMAP servers support CONDSTORE?
Most modern ones. Gmail’s IMAP, Microsoft 365, Yahoo, iCloud, Dovecot, Cyrus all support it. Older on-premises Exchange (2013 and earlier) and some custom or minimal servers may lack support. Check CAPABILITY for CONDSTORE and QRESYNC; presence indicates support. Client libraries typically detect and adapt automatically.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
