Running multiple client domains on one email API account

Agencies and freelancers managing transactional email for several clients hit a specific problem most single-tenant pricing pages don't address: one account, many domains, and a real need to know which client's sending is actually driving the bill.

What matters more than the tier price

Envello's Scale tier supports up to 100 verified domains on one account, with usage-by-domain reporting that breaks down sending volume per domain rather than showing one undifferentiated account total. For an agency, that reporting is arguably more valuable than the raw per-email rate, since it's what lets you actually bill clients accurately or spot which client's integration is misbehaving without guessing.

Setting up a new client domain

Each client's sending domain gets verified independently under the same account: add the domain, publish the SPF, DKIM, and DMARC records it gives you to that client's DNS, and wait for verification (usually minutes once records propagate). Sending reputation is tracked per domain, not shared across the account, so one client's high bounce rate from a messy imported list doesn't drag down deliverability for your other clients on the same account.

Scoping access with team roles

If more than one person at the agency touches the account, or if a client's own developer needs limited access to their domain's logs without seeing every other client's data, team roles (covered in a separate post) let you scope API keys and dashboard access rather than sharing one all-access login across everyone who might need to check on a send.

Suppression lists are per-domain, not account-wide

A hard bounce or spam complaint on one client's domain suppresses that address for that domain specifically, it doesn't blacklist the recipient across every other client you manage. This matters in practice: the same person might be a legitimate contact for one client and a bounced address for another, and account-wide suppression would incorrectly block sends that should go through.

Migrating an existing multi-client setup

If you're currently running separate accounts per client on another provider (common when a provider's pricing doesn't naturally support multi-domain billing), consolidating onto one Scale account with usage-by-domain reporting is usually a net simplification: one invoice, one dashboard, one integration to maintain across your codebase, instead of juggling separate API keys and separate billing relationships per client. The DNS changeover for each domain follows the same dual-sending pattern covered in the provider-migration posts, done one client at a time rather than all at once.

The honest limit

This is one account with domain-level visibility, not a multi-tenant platform with separate billing per client baked in. If you need to hand a client their own fully separate account and billing relationship, that's a different setup (a separate signup per client) rather than something usage-by-domain reporting solves on its own.