Your ESP can see your listWhat that means structurally, and what four providers' terms allow beyond a support ticket.

A rented email platform stores your contacts in its own multi-tenant database, alongside every other customer's, because that is how a hosted product is built to work. Someone on the vendor's side needs to be able to query that database to debug a delivery issue, investigate a support ticket, or run the infrastructure your account depends on. That access is not a leak or an oversight; it is a structural requirement of the hosting model itself, present whether or not you ever notice it.

The relevant question for a sender is not whether that access exists, since on a hosted platform it does. It is who holds it, how broad it is, and what the platform's terms permit beyond troubleshooting your specific ticket.

• Your own team, with whatever role-based access you have set up, which is the access you would expect and generally control.
• The vendor's support and operations staff, whose internal access controls and audit trails are rarely published in detail. Mailchimp's Standard Terms of Use, like most hosted platforms, treat your content as yours while the underlying infrastructure, and the staff who operate it, sit entirely on the vendor's side of the line.
• Subprocessors, meaning the infrastructure, payment, and deliverability vendors your ESP itself relies on, who can have their own access to pieces of your data as part of running the service.
• Product features that use your data as an input, most visibly AI and analytics tooling, where the terms are the only place that spells out exactly what is allowed.

Two different things hide under the phrase "we may use your data," and only one of them should concern you. Kit's Terms of Service, last updated 5 September 2025, permit the platform to "create, use, and disclose Anonymized Data" to develop and improve its services, with no opt-out offered. beehiiv's Terms of Use, last updated 16 July 2026, describe similar aggregated and anonymised usage, and separately note that for its ad network, subscriber profiles get enriched from third-party providers, with a stated promise not to disclose them to any third party in identifiable form.

Klaviyo draws a sharper line on the more consequential version of this question. Its Terms of Service, also last updated 17 December 2025, state that Customer Data will not be used to train third-party foundation models, which is a direct answer to the question that anonymised-analytics language usually leaves open: is your actual data, not a de-identified derivative of it, being fed into someone else's model.

The practical takeaway is that these clauses are not interchangeable, and the only way to know which one governs your account is to read the specific document dated for the specific feature you are about to turn on, rather than assume every platform's data-use language means the same thing.

A vendor cannot make a credible zero-access promise about an account it is hosting, because hosting the account is what creates the access in the first place. The only architecture that removes it is one where the vendor never holds a credential that reaches into your data at all: your contacts live in an account you administer, on infrastructure the vendor's own staff cannot log into, because there is nothing on their side that grants entry.

That is a different claim from a support team promising not to look, or a policy document promising to delete access logs. It is the absence of the access path itself, which is the only version of this promise that survives a change in staff, a change in policy, or a subpoena the vendor is legally required to answer.

• Your list is not sensitive: a public newsletter with no confidential fields, where the downside of vendor visibility is genuinely small.
• You rely on the vendor's support team being able to see your account to actually help you, and you have decided that tradeoff is worth it for the support quality you get in return.
• You operate in a context with no specific regulatory or contractual reason to avoid vendor-side access, and the convenience of a fully managed platform outweighs the structural exposure described above.

Contacts on a SendBunny install sit in your own DynamoDB, in your own AWS account, rather than a shared vendor database anyone's support team can query. We never receive your AWS credentials, so there is no support or operations path into your data on our side to describe in the first place. Status updates during install and updates are one-way; nothing about your account content is sent back to us. License is $199 once, sending through your own Amazon SES. It is not for you if a managed platform's support team having account access is a tradeoff you are comfortable with, or if you will not run an AWS account.