Email Backups: What You Need to Plan

Email needs backups not because a server is certain to fail, but because operational correspondence can disappear in many ways: a user deletes a folder, an account is compromised, an application synchronizes a mistaken action, storage fails, or the company discovers a loss too late.

At Mailcore, the backup environment is a production-launch requirement, not a checkbox in a plan. A company domain is not switched until copying is configured and a control restoration proves the result. Preparation therefore begins by defining the protected data, retention period, and recovery scenario that matters to the client.

A backup is not ordinary storage

A message visible in the server mailbox through IMAP is the working copy. It synchronizes to clients, so deletion on one device can propagate to the server and every other device. Synchronization does not protect against a logical error.

A mail application's local cache is not automatically a backup either. It may be incomplete, depend on one user's profile, and mirror server deletions. A laptop file remains vulnerable to hardware failure, theft, and malware.

A true backup environment generally has these properties:

• data is separated from primary storage and its accounts;
• several recovery points exist instead of one continuously overwritten copy;
• retention is defined;
• access is restricted and logged;
• recovery is tested in practice;
• the included and excluded data is understood.

A copy without a restore test is a hypothesis. Successfully writing files or seeing a green job status does not prove that a mailbox, folder, or message can be restored in time.

Scenarios to protect against

User error

An employee may delete a message, clear a folder, or configure a rule incorrectly. Deleted-item retention can help, but it is not an independent copy: its window may expire and bulk deletion may affect the entire mailbox.

Account compromise

An intruder can read or delete correspondence, add forwarding rules, and hide evidence. If the backup uses the same passwords and permissions, it can be damaged at the same time. Access separation is essential.

Technical failure and corruption

Disks, filesystems, databases, and software updates can fail. Replication improves availability but not necessarily recoverability: corruption or deletion can propagate quickly to a replica. Recovery points must allow return to a state before the event.

Migration error

IMAP migration can miss a folder, duplicate, or unusually formed message. Record folder and approximate message counts before migration and keep the source service until reconciliation under the agreed plan. See the email migration checklist.

Define the data and objectives

“We back up email” is too vague. Inventory message content, attachments, folder structure, read flags, contacts, rules, and user settings. Not every method preserves all of them.

An IMAP copy focuses on messages and folders. It can help migration or temporary export but need not preserve server filters, passwords, address books, or administrative configuration. Archive format also affects item-level restoration.

Record two objectives:

• RPO: how much recent change the company can lose; with daily copies, the potential loss window can approach one day;
• RTO: how quickly service or required data must be restored.

These values determine copy frequency, storage, and process complexity. “Backups are available” says little without scope, RPO, and RTO.

A verifiable process

Begin with a written design, not software installation. Assign an owner; list data sources, schedule, retention, and copy locations; define who may restore and who validates the result.

The practical minimum is:

1. Inventory domains, mailboxes, and data volume.
2. Use separate credentials with minimum necessary rights.
3. Encrypt copies in transit and at rest.
4. Keep several historical recovery points.
5. Protect at least some copies from immediate modification or deletion.
6. Alert automatically on failed jobs.
7. Regularly restore a selected mailbox and individual message.
8. Document what returned, how long it took, and which properties were lost.

The “3-2-1” rule is a common guide: three copies, two media types, and one off-site copy. Cloud implementations vary, but failure isolation remains useful. Two copies are not independent if one credential error or delete operation can destroy both.

How Mailcore prepares backups for production

Mailcore uses verifiable acceptance criteria. Before changing the client's MX, the data coverage, copy isolation, encryption, error monitoring, retention, and an actual recovery must be confirmed.

Preparation with the client includes:

• establishing the importance of correspondence and retention period;
• agreeing protected data and expected recovery time;
• separating backup from local IMAP synchronization;
• retaining source data after migration until reconciliation;
• performing a control restore to a safe location;
• recording the result before approving production switchover.

A temporary export or client-side copy can reduce individual risks, but its limits must be explicit. An archive may preserve messages but not rules or address books. Ownership, frequency, and control must be clear.

How to test recovery

Test a concrete scenario rather than merely opening an archive. Choose a mailbox, folder, and messages of different sizes. Restore them to a safe location without overwriting production. Compare sender, recipients, dates, subject, body, attachments, and folder structure.

Measure time and record each step. A process dependent on one engineer's memory is not ready. For encrypted backups, verify key availability and key-recovery procedure separately.

Repeat tests after software, storage design, permissions, or schedule changes. Also model an account compromise: the backup system should continue protecting data even if a user's password is exposed.

What to ask any email provider

Ask which objects are copied, how often, how long recovery points remain, where copies reside, who has access, whether one message can be restored, how the process is tested, and typical request time. Distinguish backup from replication and trash retention.

Confirm that the selected configuration includes the feature and which test proves it. Mailcore's rule is explicit: a production domain connects only after a successful control restoration. See “How Much Does Business Email Cost?” for the pilot's base terms and pricing structure.

Reliability begins with a testable criterion. A backup becomes part of an operational service only when restoration can independently verify it, which is why the test belongs in Mailcore's pre-launch control.

Sources

• NIST SP 800-34 Rev. 1: Contingency Planning Guide
• CISA: #StopRansomware Guide
• NIST Cybersecurity Framework 2.0
• RFC 9051: Internet Message Access Protocol (IMAP4rev2)