What this RFC defines
RFC 6851 defines the MOVE command for IMAP, which atomically moves one or more messages from one folder to another in a single operation. Before MOVE, clients had to perform a COPY followed by a STORE Deleted and EXPUNGE sequence, which was not atomic and could leave messages in an inconsistent state if the connection dropped mid-operation.
Where you see it in practice
When you drag an email from your Inbox to an Archive folder in a modern email client and it completes instantly and reliably even on an unstable connection, the client is using the IMAP MOVE command from RFC 6851. Without it, a folder move requires multiple round-trips and can result in duplicate messages or incomplete moves if the connection is interrupted between the COPY and EXPUNGE steps.
How it connects to other RFCs
RFC 6851 extends RFC 9051 (IMAP). It works alongside RFC 4551 (CONDSTORE) and RFC 2177 (IDLE) as part of the modern IMAP extension set. The MOVE command is advertised in the CAPABILITY response so clients can detect server support before attempting to use it.
Current status
RFC 6851 is a current standard, published January 2013. IMAP MOVE is supported by Dovecot, Cyrus, and Exchange. Most modern email clients use it when available and fall back to COPY+EXPUNGE on servers that do not support it, making it a significant reliability improvement for mobile clients on unstable connections.
The MOVE extension
RFC 6851 added the MOVE command to IMAP in January 2013. Before MOVE, moving a message between folders required a client to issue COPY (to the destination), then STORE with the Deleted flag on the source, then EXPUNGE to remove it. This three-step sequence was error-prone: if the network dropped between COPY and EXPUNGE, the message could end up in both folders or neither. MOVE performs all three steps atomically on the server, guaranteeing that the message ends up in exactly one location.
Why atomicity matters
The pre-MOVE workaround (COPY plus STORE plus EXPUNGE) is why some older mail clients occasionally showed duplicate messages after network hiccups or crashes. If the client crashed after COPY but before EXPUNGE, the original message remained in the source folder while a copy sat in the destination. MOVE eliminates this class of bug by making the operation atomic at the server. It also reduces bandwidth: the message is not re-fetched by the client between the COPY and EXPUNGE steps.
Adoption in modern clients
Every major IMAP client (Apple Mail, Thunderbird, Gmail IMAP, Outlook) supports MOVE and prefers it over the three-step workaround when the server advertises the MOVE capability. Dovecot has supported MOVE since 2013; Cyrus and other major servers followed. If you drag a message between folders in a modern client, MOVE is what actually happens under the covers, assuming both the client and server support it.
RFC 6851 (January 2013) defines the IMAP MOVE extension: an atomic operation that moves messages between mailboxes in a single command. Replaces the classic COPY-STORE-EXPUNGE pattern (copy to target, flag original as deleted, expunge). MOVE is atomic (all or nothing), efficient (one round-trip), and immediately consistent. Advertised as MOVE in CAPABILITY. Widely supported by Gmail, Microsoft 365, Dovecot, Cyrus. Foundation for every “drag a message between folders” operation in modern mail clients.
RFC 6851 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Atomic move of messages between IMAP mailboxes |
| Advertised as | MOVE in IMAP CAPABILITY |
| Command | MOVE seq-set target-mailbox |
| UID variant | UID MOVE uid-set target-mailbox |
| Replaces | COPY + STORE +FLAGS \Deleted + EXPUNGE pattern |
| Published | January 2013 |
MOVE vs classic COPY+STORE+EXPUNGE pattern
| Aspect | Classic pattern | MOVE |
|---|---|---|
| Commands | 3 (COPY, STORE, EXPUNGE) | 1 (MOVE) |
| Round-trips | 3 | 1 |
| Atomicity | Not atomic (partial failure possible) | Atomic (all or nothing) |
| Race window | Message present in both source and target for a moment | None (immediate transition) |
| Failure handling | Complex (need to detect partial state) | Simple (single response) |
| Server load | Higher (three operations) | Lower (single operation with efficient backend) |
MOVE dialogue example
Common MOVE mistakes
MOVE; use it when available. The classic pattern is a fallback for servers lacking MOVE, not the default.Related standards and further reading
- RFC 3501 IMAP Guide: base IMAP protocol
Frequently asked questions
Should I use MOVE or the classic COPY+STORE+EXPUNGE pattern?
MOVE when available. Advantages: atomic (no race window), fewer round-trips (1 vs 3), lower server load (backend can optimize as index update rather than data copy). Check CAPABILITY for MOVE; use classic pattern only as fallback for legacy servers lacking support.
What is COPYUID in MOVE response?
The UID assigned to the message in the target mailbox. Format: [COPYUID UIDVALIDITY source-uids target-uids]. Clients that need to reference the message immediately after MOVE (for follow-up operations, UI updates) should capture COPYUID. Without capturing, the client must re-fetch the target mailbox to find the moved message.
What happens if MOVE fails?
Depends on when in the operation. Target mailbox does not exist: OKfailure response, source unchanged. Target over quota: failure response, source unchanged. Partial failure (some messages moved, some not): rare; RFC 6851 MOVE is designed as atomic all-or-nothing. If the server returns partial success, treat it as failure and re-sync source mailbox state to determine actual outcome.
Do all IMAP servers support MOVE?
Most modern ones. Gmail, Microsoft 365, Yahoo, iCloud, Dovecot, Cyrus, Fastmail all support MOVE. Older on-premises Exchange or minimal custom servers may lack support. Check CAPABILITY for MOVE; if absent, fall back to COPY+STORE+EXPUNGE. Client libraries handle detection and fallback automatically.
Is MOVE part of IMAP4rev2?
Yes. RFC 9051 (IMAP4rev2, 2021) folds MOVE into the base protocol; no separate CAPABILITY advertisement needed for IMAP4rev2 servers. RFC 6851 remains the reference for MOVE semantics on IMAP4rev1 servers, which remain dominant in 2026.
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.
