Mail file import and export

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-29

Restow reads mail files, such as the remains of a mailbox that no longer exists but has to be kept, into a legacy mailbox you can browse and restore, and it writes mail back out as files from backups, imported mailboxes and the archive. It is available in every edition, since 0.1.0, and it states what it cannot do next to what it can. The same page covers the archive that imported mail can optionally go into, the ways mail gets into it from the mailboxes themselves (Business and Service Provider, since 0.4.4), and the layer on top of it that is designed for GoBD-compliant use.

What can be imported

EML: single files, folders or a ZIP.
MSG (Outlook): single files, folders or a ZIP. Only mail messages; calendar items, contacts and tasks saved as MSG are reported as "not mail" and not imported.
MBOX: Thunderbird (including its .sbd folders), Apple Mail, Dovecot and Postfix exports, and Google Takeout.
ZIP: the folder structure inside the archive becomes the folder structure of the mailbox, with EML, MSG and MBOX inside.
MailStore: an export as an EML or MSG folder tree, or a ZIP of it. MailStore's internal archive format cannot be read; in MailStore, export the mail to the file system as EML or MSG.

How files get in

You can upload files in the browser. The upload is chunked and resumable, up to 10 GiB per file by default, and every chunk carries a SHA-256 checksum. Each chunk is sealed with the tenant key as soon as it arrives, from the first byte, and stored on your storage target, so no plaintext copy of the file is written to a disk. The file type is recognised by its content, never by its extension.

The alternative is a server-side import folder, mounted read-only, with one subfolder per tenant. The administrator places files or whole folder trees there, for example a MailStore export, and selects them in the interface. Restow never writes to that folder and never empties it, and it checks that every path stays inside the tenant's own subfolder.

What you get

An import creates an "Imported mail files" source with a legacy mailbox that keeps the folder structure. It appears in the restore explorer like any other mailbox, marked as imported. You can browse it, search it, preview and print messages, download them, and restore them into an existing IMAP account or a Microsoft 365 mailbox (under a new restore folder; existing items are never replaced). There is no "restore to the original", because there is no original. Each import adds a new snapshot that contains everything before plus the new mail, so you can build a legacy mailbox from several files in turn.

EML and MBOX are stored byte for byte. An MSG file contains no ready-made email, so Restow reconstructs an EML from the stored properties (headers if Outlook stored them, text, HTML, attachments, embedded messages). The report counts these messages as reconstructed from MSG.
A message with the same Message-ID and the same SHA-256 in the same folder is a duplicate: it is not stored again, but it is counted and listed. Importing the same file twice produces "nothing new" and no snapshot.
Every unreadable or damaged item is listed with its reason in the import report, and harmless leftovers such as empty files are listed as skipped. Nothing drops out silently.
If the import worker restarts, it continues where it stopped and never reads a message twice.

Optionally you can ingest the imported mail into the archive (the option to archive at the same time, available in every edition): each new message becomes an archive object with its original bytes, hash chain, the archive retention settings and search over subject, addresses and body text (attachment content is not searched). The retention period starts on the import date, not on the date of the message, and the archive is append-only and tamper-evident (hash chain) from ingestion onward. Which layer prevents a change is a question of the repository: see "Immutability and the archive" below.

The archive

The archive is an append-only store for mail with a SHA-256 hash chain, in every edition. Mail gets in through mail import with archiving, as described above, and, in Business and Service Provider, from the mailboxes themselves (see "How mail gets into the archive" below). The archive is switched on per mail job. Search covers subject, addresses and the body text (not attachments), pages through its results and filters by sender, date and mailbox. Every hit names the way that captured the mail, and a mail that several ways captured shows them all.

Chain verification checks every link of the hash chain, the daily anchors (written every night) and, if you want, a sample of message contents.
Archived messages can be read in Restow and downloaded as .eml.
A notice says how the storage protects archived mail.
The archive can be exported like a mailbox, see below. The export of a search leaves out the captures that a stronger way replaced, as the search does.

How mail gets into the archive

Since 0.4.4 the archive has more ways in than journaling. The mail job editor asks "How mail reaches the archive" and offers only the ways that fit each kind of mailbox in the job (Microsoft 365, IMAP, Google Workspace over IMAP; for IMAP accounts on a Microsoft host it suggests connecting a Microsoft 365 source instead). Each way is labelled "At transport" or "Near-time", at least one per kind is required, and ways can be combined. The defaults of a new job are Graph for Microsoft 365 and IMAP sync for IMAP and Google Workspace. All of this is part of Business and Service Provider; the Community build keeps the capture idle.

Microsoft Graph (Microsoft 365, near-time). Restow subscribes to Graph change notifications for each archived mailbox and fetches every new mail within minutes of delivery. It needs no new Microsoft permission, no port 25 and no journal rule. Graph tells Restow about new mail only when the installation's public URL is https on port 443 and reachable from Microsoft; otherwise Restow polls every mailbox, by default every 15 minutes, and the archive page says why.
Exchange journaling (Microsoft 365, at transport). Exchange Online sends a journal report of every mail while it is in transport, so the copy exists before any user can touch the mail, BCC recipients and mail that is deleted at once included. It stays the strongest proof. It needs the journal receiver with a TLS certificate of your own and port 25. The archive page now produces the Exchange Online PowerShell commands (connector, mailbox for undeliverable journal reports, journal rule) to copy, and waits for the first report.
IMAP sync with IDLE (IMAP and Google Workspace, near-time). Restow keeps the account in sync and archives every new mail as soon as it is in the mailbox: with IMAP IDLE where the server offers it (one open connection per account), otherwise by checking at intervals, which a source can also be set to for providers with a tight connection limit. All folders but Drafts are read; on Gmail and Google Workspace only All Mail, Spam and Trash, which hold every mail once. Since 0.4.7, a message that the server refuses or does not deliver no longer holds back its folder or the whole pass (the capture gives up on it after three passes and names it in the worker log only), folders that a pass did not reach keep their state, and a watch that the server refuses with a NO on EXAMINE or IDLE is retried after minutes instead of being taken for a server without IDLE for a day.
Forwarded copies (IMAP and Google Workspace, at transport). The mail provider sends a copy of every incoming and outgoing mail to Restow while the mail is in its transport: a BCC map in Postfix or mailcow, a Sieve rule, or the routing rule "Add more recipients" in Google Workspace. Each IMAP account can have an archive address of its own, so the copy is assigned to exactly that account; a copy to the tenant's journal address is assigned by its headers. The archive page shows how to set the rule up and whether copies arrive. Such a copy has no journal envelope: BCC recipients show only if the provider writes them into a header, and a Sieve copy covers incoming mail only.
Mail import with archiving (every edition, afterwards). As described above; the retention period starts on the import date.

Graph, IMAP sync and forwarded copies each take over the mail that is already in the mailbox once, in resumable steps, and mark it "captured afterwards". Mail that reaches the archive by more than one way is recognised by its Message-ID and content and kept once: a capture that is not stronger than what the archive holds becomes a capture entry on that item, and a stronger one (a forwarded copy after an IMAP sync, say) becomes the item and names the earlier capture it replaces, which stays unchanged in the chain. Journal reports and imported messages stay items of their own. If the same Message-ID comes with another body, both are kept and flagged.

The archive page shows the capture status (streams, how mail is noticed, counts of 24 hours and 7 days, the takeover of existing mail), the capture per mailbox with a catch-up on request, the forwarding addresses and the Exchange journaling commands, and alerts say when a capture stops: a mailbox in error for more than an hour, forwarded copies that stopped for 24 hours, or a journal address without reports for 24 hours.

Since 0.4.7 the recommended job includes the archive. While the installation offers capture from the mailbox (Business and Service Provider) and the tenant has mailboxes or accounts an archive can capture, "Create recommended job" and "Protect everything without a job" make the new mail job over all objects back up and archive. A mail job over all objects that exists and does not archive yet is switched to archiving instead ("Switch archiving on in ..."): its schedules stay, the change is audited like an edit in the job editor, and it happens only when an administrator applies the recommendation. The click uses the default capture ways that need nothing set up in the tenant, Microsoft Graph for Microsoft 365 mailboxes and IMAP sync for the other accounts; journaling and forwarding stay a choice in the editor. A mail job over selected objects is never changed, and a job over all objects with capture ways chosen by hand is left as it is. The list of mail jobs shows "Switch archiving on" where the recommendation would switch it on. Without the capture, the recommended job is made as before.

What near-time capture does not promise

Graph and IMAP sync take a mail from the mailbox shortly after delivery, not in transport. A mail that is moved or deleted in that gap can be missed. In Microsoft 365, a retention policy or a litigation hold that keeps deleted mail closes the gap for deleted mail. Restow cannot see such holds (Graph offers no way to read them), so an administrator confirms the hold per source, and the archive page shows the read-only Exchange Online PowerShell commands that check it. IMAP has nothing comparable.
Of the Recoverable Items only the deletions folder is read, so mail purged before Restow fetched it can be missing. Graph cannot export mail over about 150 MB; such mail is logged, not archived. Restow sees BCC recipients only at the sender, and mail that an application sends without a copy in Sent Items is missed.
Journaling and forwarded copies show a mail as it went through the server; near-time capture shows it as it lay in the mailbox shortly after. Restow labels every capture and does not claim completeness for the near-time ways.
Tested against a simulated Microsoft Graph API, a simulated IMAP server, the Dovecot of the release smoke run and the receiver itself, never against a real Microsoft 365 or Google Workspace tenant, Postfix, mailcow or hoster. The receiver does not check the sender (SPF). IMAP sources with OAuth2 cannot be created yet, so a Google Workspace account is recognised by its host or folder list.
Mail jobs that archived before 0.4.4 keep exactly what they did: journaling only for Microsoft 365 and no way yet for IMAP and Google Workspace accounts, so nothing new starts by itself. An administrator switches Graph or IMAP archiving on in the job.

Immutability and the archive

The hash chain makes a change visible; it does not prevent one. What prevents it is the storage, and that is a setting of the repository. The archive's item records keep their own retention, as before. The message content is stored in the same chunk store as backups, so since 0.4.0 the immutability setting of a repository on S3 with Object Lock (compliance or governance mode, 1 to 3650 days) also locks the packs that hold it. A local or NFS repository gets only a deletion delay that Restow enforces itself: someone with access to the server or the share can still delete the files, and the interface labels it "Deletion delay (not immutable)". The installation's default repository cannot be made immutable; give the tenant a repository of its own. Details, what is not locked and what it does not protect against are on the storage page. It was tested against a simulated S3, not yet against a real S3 service with Object Lock.

The GoBD layer, from Business

Business and Service Provider add a layer designed for GoBD-compliant use on top of the archive:

Capture from the mailboxes by Graph and IMAP sync, and capture at transport by journal receipt from Exchange Online over SMTP and by copies a mail provider forwards (the receiver needs a TLS certificate of your own). Each journal report is assigned to the mailboxes it names.
Retention policies with an enforced deletion run.
Legal hold per tenant or per mailbox. A hold is released with a required reason, and the release is audited.

The same limits apply as above: what prevents a change is the repository, not the layer. For the background, see GoBD and e-mail archiving.

Export

You can export mailboxes or folders from backups (Microsoft 365 mailboxes and IMAP accounts), imported mailboxes and the archive, as one of two formats:

EML in a ZIP file: one .eml per message with the folder structure, plus MANIFEST.csv and SHA256SUMS (checkable with sha256sum -c). The bytes are the stored originals.
MBOX: a single folder becomes one .mbox file, several folders become a ZIP with one .mbox per folder, plus manifest and checksums.

The export file is written encrypted to your storage target, and while it is written the SHA-256 of every message is checked against the manifest, so a damaged chunk stops the export instead of producing a silently faulty file. The download link is valid for 24 hours. The request and every download are written to the audit log, and exports of other people's data carry a stated reason. Only mail is exported: calendar items and contacts are counted in the report, not exported.

Stated limits, not hidden ones

PST and OST files are recognised and refused with an explanation. PST import, PST export and MSG export are planned, see the roadmap. EML in a ZIP contains the same messages in their original form.
Calendar items and contacts in MSG files are not imported, and MailStore's internal archive format cannot be read.
From MSG, a body that exists only as RTF is not decoded (Restow uses the text body), and attachments that only point to a file are dropped. Other archive types (gz, 7z, rar, tar) and Apple .emlx files are recognised and reported as not supported, and password-protected or nested ZIPs are reported and not opened.
Mail files are read in separate helper processes with memory and time limits, never inside the server process itself. A message they cannot read within those limits is reported as unreadable (or imported byte for byte without subject, sender and text), and the import goes on. By default, uploads waiting for their import may take up to 100 GiB per tenant, and unexpired export files up to 50 GiB per tenant; both limits can be changed.
An imported mailbox cannot be deleted yet, and neither can the import source while it holds snapshots, archive objects or legal holds.
The archive retention period for ingested mail starts on the import date.

Documentation

The administrator guide describes the steps in mail import and export. Mail restored from an imported mailbox follows the rules on the restore page.

Frequently asked

Can I import an Outlook PST file?

Not today. PST and OST files are recognised by their content and refused with a clear message; they are never parsed. PST import and PST export are planned. Until then, export the messages from Outlook as MSG or EML files (drag them into a folder), or convert the PST to MBOX with a converter, and import that.

Can Restow read a MailStore archive?

Not MailStore's internal archive format. In MailStore, export the mail to the file system as EML or MSG; Restow reads that folder tree, or a ZIP of it, and keeps the folder structure.

What happens with a very large file or a dropped connection?

Uploads in the browser are chunked and resumable: if the network drops or the tab is closed, only the chunks in flight are lost, and choosing the same file again sends only the missing chunks. The default limit is 10 GiB per file. For very large collections, the server-side import folder avoids the browser altogether. If the import worker restarts, it continues where it stopped and never reads a message twice.

How does Restow show that the archive was not changed?

Every archived message is an object in a SHA-256 hash chain. The chain check verifies every link, the daily anchors (written every night) and, if you want, a sample of message contents. It makes a change visible; it does not prevent one. Prevention needs storage that refuses the change: since 0.4.0 a repository on S3 with Object Lock can be made immutable, which also locks the packs that hold archived message content, while on local and NFS repositories only the application, with a deletion delay, stands in the way.

Does Restow archive my Microsoft 365 or IMAP mail by itself?

Only for the mailboxes of a mail job that archives, and only in Business and Service Provider. Since 0.4.4 a job can capture Microsoft 365 mailboxes by Graph change notifications (shortly after delivery) or Exchange journaling (in transport), and IMAP and Google Workspace accounts by IMAP sync (shortly after delivery) or copies the mail provider forwards (in transport). A new job that archives starts with Graph and IMAP sync; jobs that archived before keep journaling only until an administrator switches another way on. Capture shortly after delivery is not complete, and the ways are tested against simulated services only.

Does imported mail end up in the archive automatically?

No. It becomes a legacy mailbox you can browse, restore and download. Adding it to the archive is an option you choose at import time, and the archive retention period then starts on the import date, not on the date of the message.

See how restore works →