# Email Vendor Lock-In: The Five Things That Actually Trap You

Source: https://wraps.dev/blog/email-vendor-lock-in

Exporting your contacts is the easy part. Here is what makes leaving expensive, and what to ask before you sign.

7 min read•Wraps Team

SendGrid, Postmark, Mailgun, and Resend all let you export your contacts. That is not the part that traps you.

Lock-in on a transactional email provider is not contractual and it is rarely about data portability in the way the marketing pages discuss it. It is about the assets you build up while you are a customer that turn out to belong to the vendor. Five of them matter, in roughly this order.

01

## The sending reputation is on their IPs, not your domain

This is the one that costs real money, and it is the one nobody checks before signing. You spend months building a sending history: low complaint rates, consistent volume, engaged recipients. That history attaches to the IP addresses doing the sending, and on most plans those addresses belong to the provider and are shared with other customers.

When you leave, you do not take it with you. You start again on a new pool at a lower volume, ramping slowly while mailbox providers decide whether to trust you. Every other item on this list is a weekend of engineering. This one is a quarter of degraded deliverability.

The check

Ask whether the sending identity is yours or theirs. If the answer involves their IP pool, your reputation is not portable.

02

## Templates carry their merge syntax, not yours

Every provider has a templating dialect. Handlebars with custom helpers, a proprietary block editor that exports JSON, substitution tags with their own escaping rules. The export button gives you HTML, and that HTML has their syntax baked into it.

The fix is cheap if you do it on day one and expensive if you do it in year three: keep templates in your own repo in a format that renders anywhere. React Email compiles to plain HTML and does not care who sends it. MJML works the same way. If templates only exist inside the vendor's editor, they are the vendor's.

The check

Can you render a production email from source control, without calling the vendor's API?

03

## The suppression list is a liability you cannot re-derive

Every hard bounce and every complaint you have ever received is recorded somewhere. That list is the reason you are not mailing addresses that already burned you. Lose it and you re-mail all of them, at once, from a brand new sending identity that has no reputation to absorb the damage.

That is the worst possible first week on a new provider, and it is entirely self-inflicted. Some providers export it readily. Some give you an API and a rate limit and wish you luck.

The check

Export the suppression list today. If you cannot do it in one call, you do not really have it.

04

## Event history has a retention window and no bulk export

Opens, clicks, bounces, deliveries. Most providers hold these for 30 to 90 days depending on plan and expose them through a paginated API rather than a dump. That is usually fine day to day, and it is a problem the week you need to answer a compliance question about a message you sent eight months ago.

This one matters less than the first three for most teams. It matters a great deal if you are in a regulated industry, and it tends to be discovered at the worst time.

The check

Ask for the retention window in writing, and ask whether there is an export or only an API.

05

## The credentials are wired into more places than you remember

SMTP credentials and API keys spread. They end up in the main application, a cron job, two Lambdas, a Zapier somebody set up, the billing service, and a staging environment nobody has touched in a year. Migration means finding all of them, and the ones you miss fail silently until a customer says they never got a receipt.

This is the most tractable item here. Route every send through one internal module from the beginning and the swap is a single file. Teams that skip that step pay for it once, loudly.

The check

Grep for the provider's SDK import across every repo. The count is your migration size.

## The question that covers all five

Could you move to a different provider in a week and keep your delivery rates? Not your data. Your delivery rates.

Most teams have never asked it, and the answer is usually no because of item one. That is worth knowing before you sign rather than during the migration, because the answer is decided at signup and cannot be changed afterwards without doing the migration you were trying to avoid.

## What bring-your-own-cloud fixes, and what it does not

Wraps deploys sending infrastructure into your own AWS account, so some of this list stops being a vendor question. Some of it does not, and pretending otherwise would make this a worse buying guide.

| Asset | Managed provider | Wraps |
| --- | --- | --- |
| Sending reputation | Their IP pool. Not portable. | Your SES account and your domain. It stays when the platform goes. |
| Suppression list | Theirs, exportable to varying degrees. | SES account-level suppression in your AWS. Already yours. |
| Delivery events | Their store, plan-limited retention. | Your DynamoDB table on the Production and Enterprise presets, your retention policy. We keep a copy too — see below. |
| Templates | Their editor and dialect. | Still the vendor's problem. See below. |
| Contacts and workflows | Theirs. | Still the vendor's problem. See below. |

Solved by the architecture

Your sending identity, reputation, and suppression list sit in your AWS account under your own IAM, and so does the raw event history on the Production and Enterprise presets. Stop paying Wraps and the sending infrastructure keeps running, because it was never ours to switch off.

Not solved

Contacts, templates, and workflow definitions live in the Wraps database, not yours, and so does a per-message record of everything sent through the platform: recipient, subject, sender, merge variables, and the engagement timestamps. Templates are the softer case since they are React Email in your repo if you author them that way, but the platform data is platform data and moving off us means moving it.

That is a real limit, not a rounding error. What changes is which half of the list is at stake: the expensive half, reputation and suppression, stops being a migration problem. The cheap half is still a migration.

## Run the check on what you have now

The migration guide covers moving an existing SES setup, and the BYOC page has the full architecture including what stays behind if you leave.

[Migration guide](https://wraps.dev/docs/guides/migration)[How BYOC works here](https://wraps.dev/byoc)