Still paying for unsubscribed contactsThe row you cannot email is still the row your plan bills you for.

A contact-tier ESP typically sets your price by counting rows in your account, and an unsubscribed contact is still a row. Engagement reporting will show that person as opted out, which is real and useful information, but the tier your invoice is drawn from is usually based on presence in the database, not on subscription status. The invoice and the engagement dashboard disagree with each other, and the invoice wins.

This is not universal across every plan on the market, and the exact rule is worth checking on your own contract before you assume it applies. What is consistent is the direction of the incentive: platforms that bill by contact count have little reason to exclude unsubscribed rows from that count, because doing so would only lower revenue on accounts that are already sending less.

Purging unsubscribed rows to cut the tier looks like an obvious answer and creates a worse problem. An unsubscribe is a suppression record, not just an absence. It is the proof that this specific address asked to stop receiving mail from you, with a timestamp attached. Lose that record and a future list import, a merged database, or a new tool with no memory of the opt-out can put that address back into rotation. Remailing someone who unsubscribed is one of the fastest ways to generate a spam complaint, and complaint rate is the metric that actually threatens your sending reputation and, on Amazon SES, your account's standing.

So the honest framing is that you are not paying rent on a person you email. You are paying rent on a compliance record you are supposed to keep, on a billing model that charges you to keep it correctly.

The difference is what sets the price. Storing rows, including suppressed ones, is genuinely cheap: it is a database problem, not a sending problem. What is expensive is a pricing model that bundles storage and sending into one number keyed off list size. Separate the two and an idle list, unsubscribed rows and all, costs close to nothing to keep on file, while sending stays metered at roughly $0.10 per 1,000 emails through Amazon SES.

• Your unsubscribed and inactive segment is small relative to your active list, so the mismatch this page describes barely moves your invoice either way.
• You value the ESP's built-in re-engagement or win-back tooling enough that having those cold contacts inside its system, rather than parked separately, is worth the tier you are already paying.
• You are early enough that list size is small in absolute terms, and the administrative cost of separating storage from sending is not worth your time yet.

If you do move platforms, the point of this page is the one step people skip: export the unsubscribe and complaint history alongside the addresses, not just the addresses. A CSV of emails with no status column is a list you cannot safely mail from anywhere, since you no longer know who opted out. Bring the subscription status, the date of the unsubscribe or complaint, and import all of it, including the suppressed rows, into wherever the list lands next. Re-imports should enrich existing records rather than overwrite them, so a second export from the old platform does not accidentally revive suppression history the new platform already has.

SendBunny installs into your own AWS account as a CloudFormation stack, with campaigns, lists, and a transactional API, and there is no contact-tier fee at any list size, subscribed or not. Suppression is enforced account-wide across every send path, so an unsubscribed or complained address stays excluded whether it is mailed through a campaign or the API. The license is $199 once, with optional $99 a year updates, and sending is metered separately at Amazon SES rates. It is not for you if you will not run an AWS account, or if you are relying on an ESP's win-back automation to re-engage cold contacts.