Own your email list, for realNot CSV export theater: what to export, in what format, and how to prove it works.

Most people treat a CSV download as proof they own their list, then find out during an actual migration that the file is missing the one column that matters: who consented, when, and through what mechanism. That gap does not show up until you try to mail the list somewhere else and realize you cannot lawfully do it, because an address with no consent record is not something you are cleared to email from a new sending identity in most jurisdictions.

This page is the practical side: what to export, in what shape, and how to prove the move actually works before you need it to. The legal side, meaning what Mailchimp, Klaviyo, Kit and beehiiv's current terms actually say about who controls the rows and what happens after you leave, is covered separately in Who owns your email list? That article quotes the clauses; this one is the checklist you run against them.

An export built for real portability carries six things per contact: the address, name and custom fields, list or segment membership, subscription status, the consent source and date, and the unsubscribe or complaint history with timestamps. Drop any one of those and the next platform inherits a gap you will not notice until it costs you a complaint.

CSV is the safer default for a straightforward move between two mainstream platforms. Reach for JSON, or a CSV with one row per event rather than one row per contact, when the list carries a consent or engagement history complicated enough that flattening it into simple columns would lose information.

The consent source and date field records how someone ended up on the list and when: a signup form, a checkout flow, an imported list from a prior tool with its own consent trail. Without it, a new platform has no way to distinguish a subscriber who opted in last month from a row that was scraped or purchased, and in most jurisdictions that distinction is exactly what makes mailing someone lawful or not.

The unsubscribe and complaint history matters just as much, in the other direction. It is what keeps a re-import from accidentally re-adding someone who already told a previous platform to stop. Losing that history and remailing someone who unsubscribed is one of the fastest ways to generate the complaint that gets a brand-new sending identity reviewed before it has even warmed up.

The domain is the one part of this that is already yours regardless of what platform you send from, which is exactly why you never send campaigns from a platform's own shared domain. Everything else on that list has to be deliberately carried across in the export, because none of it follows the addresses automatically.

Your domain moves for free. Its sending reputation does not. A new platform requires its own SPF, DKIM and DMARC records for that domain, generated fresh even though the underlying domain has years of history elsewhere, and mailbox providers treat the new sending identity as unproven until it builds its own track record. Google's own sender guidelines describe authentication and a low complaint rate as ongoing requirements, not a one-time setup step, which is the practical reason a fast list import followed by an immediate full-volume send is the most common way a clean migration goes wrong.

Before trusting the new setup with anything that matters, run a small import first: a subset of the list, not the whole thing, and confirm that addresses marked unsubscribed on the old platform show up suppressed on the new one. That one check, run once before the real migration, catches a missing consent or suppression field while the cost of being wrong is a handful of test sends rather than a complaint spike on your only sending identity.

• Your list is small and your relationship with each recipient is direct enough that a suspension would be an inconvenience, not a crisis, so a monthly backup export covers the realistic risk.
• You are not sending anything time-sensitive enough that a platform outage or review would cost you real revenue, so the overhead of maintaining a second, ready-to-go sending path outweighs the risk it protects against.
• You already keep a disciplined monthly export with consent and suppression fields intact, which is most of this playbook done in advance; a full second platform is the next step only once that habit is solid.

SendBunny is built so the five parts above sit in an account you administer from day one: a complete email platform installed into your own AWS account as a CloudFormation stack, with contacts, consent fields and the account-wide suppression list held in your own DynamoDB. CSV import brings a list in; re-imports enrich existing contacts rather than overwrite them, so a second import does not undo suppression history already on file. It sends through your own Amazon SES, unlimited contacts, $199 once. It is not for you if you will not run an AWS account, or if you need a hosted signup form today, since contacts arrive by CSV import or the API rather than through a hosted form.