← Back to the catalog

Outlook PST/OST Corruption

Outlook reporting a corrupted data file sounds like one problem, but it's actually two very different ones wearing the same error message — and which one it is changes whether this is urgent at all.

Recovery decision

PST/OST corruption: what should you do next?

Answer one question about the current state. The result suggests the safer next step rather than diagnosing the failure.

Typical source stabilityUsually stable

Default action riskModerate

Default first actionPreserve mail files

Check my situation

This guide classifies the next recovery action from observable information. It does not diagnose hardware condition or estimate a percentage chance of recovery.

What's actually happening

Outlook stores mail locally in one of two container file formats, and they play very different roles. A PST is often the only copy that exists — the default for POP3-configured accounts, and for any manually created archive file, since neither of those has a live mailbox on a server backing them up. An OST, by contrast, is normally a cache of a mailbox that actually lives on an Exchange, Microsoft 365, or IMAP server, so the server is often the primary recovery source. But before discarding the OST, verify that the server actually contains all required mail state: unsynchronized drafts, items cached locally before ever reaching the server, or content no longer resident on the server can make a particular local store recovery-relevant in its own right.

How recoverable this really is

If the server mailbox is intact and complete, rebuilding a damaged OST may be routine: deleting it and letting Outlook reconnect rebuilds the cache automatically, with the main cost being the time the resync takes. The important step is confirming that condition before deleting or recreating the local cache, not after. A corrupted PST is a genuinely different situation whenever it turns out to be the sole copy of its contents — a badly damaged one can lose folders, individual messages, or attachments outright, depending on exactly where within the file's internal structure the corruption falls.

Preserve the original PST/OST and note its size and location. Check the server mailbox and webmail without deleting or recreating the local store first. If the underlying drive shows read errors or instability, deal with acquisition before running mail-repair tools; repair is a write-capable logical operation and should be performed on a copy.

What you can check safely

Check whether the mailbox is still accessible through webmail or another synchronized client, confirm whether the local file is PST or OST, and record the file path and size before changing anything. These checks can establish whether the local store is the only copy without modifying it.

What changes recoverability

File size, truncation, storage-media condition and the type of corruption all matter. Logical damage inside an otherwise complete PST is different from a PST that has been partially overwritten or truncated, and neither should be confused with a failing disk that happens to contain the mail store. With OST files, account availability, mailbox synchronization state and whether unsynchronized local items existed are especially important.

First determine where the authoritative mail still exists

A PST is commonly a local Outlook data store or archive; an OST is normally an offline cache associated with a server-backed mailbox. That distinction changes the recovery strategy, but the file extension alone doesn't settle it: a PST can be a POP account's primary store, a manually created archive, an exported copy, a backup, or a duplicate of mail that also exists elsewhere — the question that actually matters is which copy is authoritative, not which extension the file has. If the complete mailbox still exists on Exchange, Microsoft 365 or another server, rebuilding a local cache may be safer than trying to repair it. If a PST contains mail that exists nowhere else, the file itself is primary evidence and should be copied before repair.

PST is a database with two core B-trees

Underneath the mail-client surface, a PST is a node database indexed by two separate structures — a node B-tree that maps folders and messages to logical records, and a block B-tree that maps those records to the physical bytes that actually store them. A message can involve several of these blocks at once — its properties, body and attachments aren't necessarily one contiguous piece — which is why damage can remove an attachment while leaving its message readable, or remove a message body while its header survives.

ScanPST can rebuild the store without preserving every original item — preserve the original first

Microsoft documents that ScanPST checks and repairs structural problems in the data file, and that some items may not be recovered; repaired or recovered items can also appear in recovered/Lost and Found structures rather than their original location. That is enough reason to preserve the original PST before repair and validate the recovered mail afterward. Always run ScanPST against a copy, and keep the untouched original until the repaired result has actually been checked.

OST is usually reconstructable from the server — but not always

The normal path for a damaged OST really is to delete it and let Outlook rebuild the cache from the server, and that should be the default assumption. But unsynchronized drafts, items cached locally before ever reaching the server, a mailbox since deleted or purged on the server side, or an old workstation holding history no longer available anywhere else can all make a specific OST genuinely unique. Confirm the server mailbox actually still has the missing content before deleting the local file, not after.

The general approach

The first step is establishing which file type is actually involved — Outlook's Account Settings shows this per account, usually next to the account's data file path. For a genuinely irreplaceable PST, Microsoft's own ScanPST.exe repair utility (installed alongside Outlook) is the standard first move, run against a copy of the file rather than the original.

A repaired PST opening in Outlook is not sufficient validation on its own. Check the folder tree against what should be there, expected date ranges, message counts where they're known, and that message bodies and attachments actually open, not just that the file mounts.

The "damaged bookkeeping, not necessarily damaged data" logic here mirrors File System Corruption at the application-file level instead of the drive level. For the full internal structure, see PST and OST Internal Structure Recovery. See the full directory of recovery software by vendor for options if ScanPST.exe alone doesn't resolve a badly damaged PST.