Export All Your Email Before You Cancel a Subscription

How to export your email before cancelling a subscription is the sort of task that looks like two clicks and turns out to be seven — because the mail itself is only one of the things you are about to lose. Contacts, filters, signatures, forwarding rules, aliases and billing history all live inside the same tenant, and most of them do not survive cancellation.

This guide is the universal pre-cancellation checklist: what to export, in what order, and — the step almost everyone skips — how to verify the archive is actually readable before your access ends. It is provider-agnostic. Gmail, Outlook, Fastmail, Proton, Zoho, iCloud, HEY: the file formats and menu paths change, the checklist does not.

Cancellation itself is a two-minute click. The two weeks around it are the actual work.

What actually moves — and what doesn't#

The mistake that destroys years of mail is treating a mailbox like a Netflix subscription — cancel it, and it sits there quietly waiting for you to come back. It does not. When you cancel most email services, the mailbox is scheduled for deletion, and a short admin-restore window (measured in days, not months) is the only thing between you and permanent loss. There is no automatic export, no attachment archive dropped in your other inbox, no long grace period.

The table below is the honest map of what survives cancellation, what needs an active export before you cancel, and what has to be re-created at the new host from scratch. Notice how many rows are "export before you cancel" — that is why the sequence matters more than any single tool.

Pre-cancellation checklist#

Run through this list once before you touch a single export. Everything below is fifteen minutes of preparation that saves the migration from a rushed weekend with a broken archive.

• Pick the destination first. You cannot verify a mail export end-to-end without a second mailbox to import it into. Provision the new host — even a free tier at Fastmail, Zoho or Proton — before you export anything.
• Have two machines ready. Export on the primary machine, verify on a second one. An archive that only opens on the machine it was created on is not a backup; it is a coincidence.
• Install one desktop mail client that can read your archive format. Thunderbird for MBOX, classic Outlook for PST, Apple Mail for EML. This is your verification tool.
• Note your current MX, SPF, DKIM and DMARC records — screenshots or a text file. If anything goes wrong during the domain move, this is your rollback map.
• List every alias, forwarding rule and filter. The provider's own settings page is the only complete list; nobody remembers all of them.
• Download at least the last twelve months of billing invoices. Your accountant will need them and the billing portal disappears with the subscription.
• Warn stakeholders. Cancelling shared mailboxes, calendars or delegated access without telling people first is how a quiet migration becomes a Monday-morning fire.

Steps: export mail, contacts, calendar and settings#

The following sequence works across every major provider. The menu paths differ; the order does not. Do these top to bottom, and only start cancellation after step 7 has passed.

1. 1

   Export the mail as MBOX, PST or EML

   On Gmail-family accounts, use Google Takeout (takeout.google.com) and select Mail — it produces MBOX per label. On Microsoft 365 / Outlook.com, use the classic Outlook desktop client's Import/Export wizard to write a PST, or the Microsoft eDiscovery export for tenants. On IMAP hosts (Fastmail, Zoho, iCloud, Proton Bridge), drag every folder into a local Thunderbird profile so it is stored on disk as MBOX. Include Sent, Drafts, Archive and every custom label — Inbox is the smallest part of your history.

2. 2

   Export contacts as vCard or CSV

   Every provider exports contacts from the same address-book page they display them on. vCard (.vcf) preserves photos and multiple fields per contact and imports cleanly into every other mail host and most CRMs. CSV is the fallback when the destination refuses vCard. Do both if you can — they are small files.

3. 3

   Export every calendar as ICS

   Do this per calendar, not per account — most people have three to five (personal, work, shared team, birthdays synced from Facebook or Contacts). ICS files import into any other calendar. Note which calendars you own versus were invited to: only the ones you own carry the events with them.

4. 4

   Save filters, forwarding rules and vacation responders

   Gmail exports filters as XML from Settings → Filters and blocked addresses → Export. Outlook rules live inside the Outlook profile and travel with a PST. For everything else, screenshot each rule. You will re-create them at the new host by hand, and the screenshots are the specification.

5. 5

   Save signatures and templates as plain text and HTML

   Open each signature in the settings page, copy the HTML source (browser dev tools if the provider does not expose it), and paste into a text file. Do the same for any canned responses or reply templates. These are tiny, easily forgotten, and painful to rebuild from memory.

6. 6

   Record aliases, send-as identities and connected apps

   List every address that can currently send from this account and every third-party service that has an OAuth grant against it. Both lists are on the account's own settings pages. When the account dies, both lists become invalid: aliases return to the provider's pool; OAuth grants are revoked and integrations start failing without a clear error.

7. 7

   Verify the archives on a second machine

   This is the step almost every guide skips and every failed migration wishes it had run. Copy each MBOX, PST, ICS and vCard to a second computer. Open the mail files in Thunderbird (MBOX), classic Outlook (PST) or Apple Mail (EML). Import the ICS into a fresh calendar. Import the vCard into a new contacts app. If any file will not open or produces an error, re-run that export while the account is still live. Do not proceed until every archive is confirmed readable in a tool other than the one that produced it.

What breaks anyway — and when to notice#

Even a clean export cannot preserve everything, because some of what you had was a live connection to the provider rather than data you owned. Knowing what will not survive is what keeps the first week at the new host calm rather than surprising.

Rollback plan if the export goes wrong#

Rollback exists to be cheap. It stays cheap as long as the old subscription is still live and paid — the moment you have clicked cancel, rollback becomes a race against a countdown you cannot pause. The whole point of the sequence above is that every step is reversible until the very last one.

1. 1

   If a mail export file will not open on a second machine

   Do not cancel. Re-run the export, in a smaller batch if the tool is timing out. For very large mailboxes on Gmail, run Takeout per-label instead of the whole mailbox in one archive. For Outlook PST, split by year.

2. 2

   If contacts or calendar import into the new host with garbled fields

   Re-export as the alternative format — vCard if you tried CSV, ICS from a fresh source if the first ICS was corrupt. Some providers write non-standard ICS extensions; the destination may reject them. A clean re-export from a different device often fixes it.

3. 3

   If the MX cutover misroutes mail

   Revert the MX record to the original values. Because you dropped the TTL to 300 seconds before the change, propagation is minutes. Keep the old host paid for at least a week after the flip so any misrouted mail is captured, not bounced.

4. 4

   If you already cancelled and are inside the restore window

   Reactivate the subscription immediately from the provider's admin console. Verify each mailbox opens before you do anything else. Once the restore window expires, only a pre-cancellation export can recover the data.

Doing it without downtime#

Zero downtime on a mail cutover is achievable, and it comes from three habits rather than any single tool. The first is timing — schedule the MX change for the lowest-traffic hour of your week (Friday evening or Saturday morning in your business's main timezone), so any short propagation gap lands where a delayed message is not a missed deal.

The second is dual delivery during the observation period. Some hosts natively support routing mail to two destinations at once. Where that is unavailable, a temporary rule on the old host that forwards a copy of every incoming message to the corresponding new-host address gives you the same effect: every message lands at both places, and you pick the better copy.

The third is not technical — it is telling external contacts nothing. A quiet, well-executed cutover reads to the outside world as no change at all. It is only the customer-visible outages and "please email our new address" messages that turn a migration into a communications event, and none of those are necessary when the domain does not move.

How to verify the backup actually worked#

Verification is the difference between a backup and a hope. The pass criteria are boring on purpose — if any of them fails, the archive is not ready and cancellation waits.

• Every MBOX, PST or EML file opens in a mail client on a second machine, not the one that created it.
• The message count in the archive matches the message count shown by the provider's own account settings within a small tolerance.
• At least one message with an attachment opens end-to-end — the attachment downloads and previews.
• The ICS calendar file imports into a fresh calendar and the event dates, times and timezones match.
• The vCard or CSV imports into a fresh address book and phone numbers, emails and photos survive.
• Filters and rules are captured either as XML/JSON or as legible screenshots — enough to re-create them at the new host without guessing.
• Every past invoice you might need is saved as PDF outside the billing portal you are about to lose.

Where AI Emaily fits after the move#

Once every archive is verified and the domain has moved to its new host, the mailbox has to be worked. That is where AI Emaily fits. We are an AI-native email client that connects over Gmail, Microsoft Graph and any IMAP account, so whatever host you land on — Microsoft 365, Fastmail, Zoho, Proton, iCloud or an IMAP box you already had — the archive you just rescued becomes a normal live mailbox: searchable, triaged, and worked by an assistant that files, drafts in your voice, and closes loops with approve-before-send review. We build AI Emaily. Full disclosure written into the argument rather than bolted on.

The honest limit, because it is worth naming plainly: AI Emaily does not create the archive itself. For the job of "produce a browsable local copy of a mailbox I can search five years from now," a dedicated backup tool such as MailStore Home or Aid4Mail does that better than any mail client, ours included. Use those to build the export; use us for the part that starts once the mail is at the new host.

Putting it together#

The whole difference between a successful cancellation and a painful one is order. Provision the new host first, export everything while the old subscription is fully paid, verify each archive opens on a second machine, move the MX record once the new host is proven, keep both hosts live for a week, then cancel. Every step until the last is reversible.

Larger tenants add licensing, SSO and eDiscovery holds. Regulated tenants add legal-hold sign-off and a Vault export. Consumer accounts skip the domain steps entirely. But the mail side of the story is always the same: export before you cancel, verify before you rely, and never let the provider's grace period be your migration plan.