How Outlook Stores Mailbox Data in OST Files

Cached Exchange Mode and the role of the OST file

When Cached Exchange Mode is enabled, which has been the default for Exchange and Microsoft 365 accounts since Outlook 2010, Outlook does not query the server for every action a user performs. Instead, it maintains a local copy of the mailbox in the OST file and works against that copy directly. Read operations, searches, folder navigation, and rule evaluation are served from disk rather than from the network, which reduces load on the Exchange server and keeps Outlook responsive even during periods of network latency or brief connectivity loss.

The OST file is tied to the mailbox GUID and the Exchange profile that created it. It cannot be opened independently by another Outlook profile, because the binding to the source mailbox is enforced at the profile level and validated against the server during each connection attempt. A PST file, by contrast, is a portable, standalone container that Outlook can open without any server connection at all, which is one of the key structural differences between the two formats.

Without Cached Exchange Mode, Outlook operates in Online Mode, where every folder view and message open triggers a direct MAPI request to the server. Online Mode does not maintain a full OST replica, though it may still use a smaller OST-based cache for specific features such as offline access to recent items in some hybrid configurations.

Internal structure of an OST file

An OST file is built on the same ESE technology that underlies the Exchange Server database (EDB) format, though the two are not interchangeable and cannot be opened by the same tools. Internally, the file is organized into several logical components:

• Header block: Stores metadata about the file, including the format version, the associated mailbox signature, page size, and CRC checksums used to detect corruption during mount operations.
• Node database: A B-tree structure that indexes every object in the mailbox, folders, messages, attachments, and their parent-child relationships, allowing Outlook to locate an item without scanning the entire file sequentially.
• Property streams: Each mailbox item is stored as a set of MAPI properties (subject, sender, recipients, body, flags, categories, and so on), encoded as named property tags rather than as flat text. This is why raw OST data cannot be read as plain text or opened in a generic text editor, and why any recovery process has to interpret these property structures rather than simply copying bytes.
• Attachment table: Larger attachments are stored separately from the message property stream and referenced by pointer, which keeps the message table itself compact and speeds up header-only operations like list views and search indexing.
• Free page list: Tracks pages freed by deleted items so the ESE engine can reuse space without immediately shrinking the file on disk, which is part of why an OST file's size on disk does not always shrink right after items are deleted.

Outlook 2013 and later use a Unicode-based OST format, identified internally by a different header signature than legacy ANSI-based files, which supports mailbox and item sizes beyond the 2 GB limit imposed on older formats. Current builds of Outlook set a default OST size warning threshold around 50 GB and a hard limit around 100 GB, both of which are configurable through registry policy in managed environments.

Where OST files are stored on disk

By default, Outlook creates the OST file under the user's local profile, typically at a path resembling:

C:\Users\username\AppData\Local\Microsoft\Outlook\

The file name is generated from the mailbox's SMTP address combined with a unique identifier, for example username@domain.com.ost, which prevents collisions when multiple accounts are configured in the same Outlook profile. Administrators can redirect this location through Group Policy using the PST and OST files path policy setting, which is often done in virtual desktop or shared workstation environments to keep cache files off system drives with limited capacity.

Because the file lives in the user's local AppData folder rather than in the mailbox itself, it is not included in standard file-server backups unless explicitly targeted, and it does not need to be backed up for mailbox recovery purposes since it can always be regenerated from the server. This is a point often misunderstood in disaster recovery planning: the authoritative copy of the mailbox is on the Exchange server or in Microsoft 365, and the OST file is disposable from a data-protection standpoint under normal circumstances.

How synchronization keeps the OST file current

Outlook synchronizes the OST file with the Exchange mailbox through MAPI-based incremental change notifications. When an item changes on the server, whether through a new message arriving, a rule moving a message, or a change made from another device or Outlook on the web, Exchange logs that change against the mailbox using an internal change number sequence. Outlook periodically requests the delta since its last synchronization cycle and applies only the changed properties to the local OST file, rather than re-downloading the entire mailbox.

This delta-based approach is why a large mailbox does not need to fully re-synchronize after a brief network interruption. Outlook resumes from the last known synchronization state and reconciles only the items that changed while the connection was unavailable. Conflicts, such as an item edited both offline and on the server before the two copies reconcile, are logged in a hidden Conflicts subfolder inside Sync Issues rather than silently overwritten, giving the user a record of both versions.

Send/Receive groups control how frequently this synchronization cycle runs and which folders participate. Shared mailboxes and secondary accounts added to the same profile can be configured to download headers only, full items, or to skip synchronization entirely, which directly affects how much of that mailbox is actually materialized inside the local OST file.

Folder-level storage and item retention

Each folder in the mailbox, Inbox, Sent Items, Calendar, Contacts, and any custom folders, maps to a corresponding folder object inside the OST file's hierarchy. Outlook also maintains hidden system folders, including Sync Issues, Conflicts, and Local Failures, which occupy space within the same file but are not normally visible in the folder pane. Retention and archive policies applied at the mailbox level, such as Online Archive or retention tags, determine which items remain in the primary OST versus being moved to a separate archive OST tied to the same profile.

When Cached Exchange Mode is combined with the "Download shared folders" or slider-based "Mail to keep offline" setting introduced in later Outlook versions, only items within the selected time window are stored locally, while older items remain retrievable from the server on demand. This partial caching behavior means the OST file does not always contain a complete copy of the mailbox, which is a relevant distinction when planning any local recovery scenario.

Why OST files become inaccessible

An OST file can become unreadable for several reasons: the mailbox is deleted or disabled on the server before Outlook reconciles local changes, the Exchange profile is removed or corrupted, the file exceeds its format's size limit, the underlying disk develops bad sectors that corrupt the ESE structure, or an abrupt system shutdown interrupts a write operation mid-transaction. In each case, the data inside the file is not necessarily lost, but Outlook can no longer parse it because the binding to an active mailbox profile is broken, or because the internal page structure fails the CRC validation Outlook performs when mounting the file.

A common scenario involves employee offboarding: a mailbox is disabled or removed from Exchange or Microsoft 365 as part of an account deprovisioning process, but a local OST file from that user's workstation still exists with the last synchronized state of the mailbox. Since the file is bound to a mailbox that no longer exists, Outlook cannot reopen it under a new profile, even though the underlying ESE structure and all the mailbox data it contains remain physically intact on disk.

Recreating an OST file versus recovering its contents

In most day-to-day scenarios where an OST file is flagged as corrupted while the source mailbox is still active, the standard remediation is to delete the local OST file and let Outlook rebuild it from scratch on the next connection. This works because the server remains the authoritative data source, and Outlook simply re-downloads the mailbox content into a fresh file. Microsoft's Inbox Repair Tool (SCANPST.EXE) can also attempt to fix structural inconsistencies in a damaged OST or PST file without discarding it, though its repair capability is limited to certain classes of corruption and does not restore items already flagged as unreadable.

Recreation is not a viable option, however, when the mailbox itself is no longer available on the server, when the goal is to recover the last known state before a mailbox was altered or deleted, or when the local file needs to be preserved as evidence or as an offline archive independent of any live Exchange connection. In these cases, the OST file has to be treated as a standalone data source, and its contents parsed directly, since there is no server-side copy left to re-synchronise from.

Accessing Stored OST Data Outside of Outlook

Everything described above, the header block, node database, property streams, and attachment table, exists because Outlook needs a fast, locally-indexed replica of the mailbox. That same structure is also why an OST file can't simply be opened elsewhere: the data is stored in a format tied to Outlook's own ESE engine and validated against a specific mailbox profile, not a portable container the way a PST file is.

This becomes relevant any time the stored data needs to be accessed independently of that original Outlook/Exchange binding, whether Outlook itself is unavailable, the original profile no longer exists, or the goal is simply to move that locally stored mailbox data into a portable format. Reading the same internal structures described earlier, header, node database, property streams, is exactly what's required to do this correctly, which is why a purpose-built converter, rather than a simple copy or rename, is necessary.

EdbMails OST to PST Converter does this by parsing the OST's internal structure directly and exporting the mailbox data, folders, messages, calendar items, contacts, and attachments, into a standard PST file that Outlook can open independently of the original profile or server connection.

 See the full step-by-step OST to PST conversion guide