Email marketing for agencies: separate clients, separate reputations

Running email for several clients is a different job from running it for one account, and the difference is not the login screen. It is the reputation. Gmail, Outlook and Yahoo judge a sending domain and the infrastructure behind it, not a spreadsheet of clients, so if two clients’ mail rides the same reputation, one client’s messy list can drag a clean one into the spam folder alongside it. That is the question to ask before anything else: does a platform keep each client’s own reputation and numbers separate, not just their logins and their contact lists.

EmailFig’s client accounts do. One login can run a client account per customer, kept one level deep, and each one’s deliveries, bounces and complaints belong to it alone.

Key Takeaways

• One login runs a client account per customer, kept one level deep: a client cannot create its own sub-clients.
• Each client account carries its own sending reputation, its own bounce and complaint counts, and its own bill.
• A hard bounce or spam complaint anywhere on EmailFig blocks that address on every account, which protects your other clients from an address one client’s list picked up.
• We do not offer white labelling at any size. BigMailer does, on its Business Pro and Agency Pro plans, if that is what you need.
• Both plan families are free up to 4,000 subscribers per client, so a book of small clients can run largely on the free tier.

If white labelling is what you need, we are not it

EmailFig does not offer white labelling at any size: no version of the product carrying your agency’s logo instead of ours, no rebranded interface, no reselling it end to end as your own tool. If that is the requirement, say so to yourself now rather than discovering it after onboarding a client.

BigMailer does offer white labelling, on its Business Pro and Agency Pro plans. Whether it is the better fit for the rest of what you need is a separate question, since white labelling is not free and is not automatically the right call for a small book of clients, but it is the honest answer to where to look if that one feature is non-negotiable.

What paid plans here do remove is narrower: the “Powered by EmailFig” line on the pages a client’s recipients see, an unsubscribe page or a preference centre, disappears the moment that client’s account is on a paid plan, the same as it would for any account. That is branding a recipient notices, not a product a client logs into. A client account does not get a login of its own in the first place: your own team signs into it, so there is no separately-branded doorway to worry about either way.

Client separation means more than separate folders

The easy version of “separate clients” is tagging contacts by client inside one account. It looks organized and it is not actually separate: every client’s contacts still count toward the same billing tier, a bad import from one client still shows up in the account-level numbers everyone else’s mail is judged against, and anyone with access to the account sees every client’s list, not just the one they were hired to run.

A client account is genuinely separate. Its contacts, campaigns, automations, forms, reports, sending domain and subscription belong to it and nothing else touches them, the same wall that separates any two unrelated EmailFig customers. Move a client to its own account and none of that changes: the same builder, the same automations, the same segments and templates, just scoped to one client instead of blended into a shared pool with everyone else’s tags on top. That is the baseline “separate clients” needs to mean before reputation, pricing or reporting is worth discussing at all.

Why one client’s bad list should not sink another’s

This is the part most agency-facing content skips, because most of it is written by platforms where every client shares one sending reputation by construction.

Each client account keeps its own bounce rate, complaint rate and delivery history. A messy list on one client does not show up in another client’s numbers, and a bad list stays on that one account: if a client’s sending is paused, only that client’s account stops, not your whole roster. See why purchased lists cause trouble.

Be precise about what “separate” covers, because overselling it would be worse than not saying it. On managed sending, the underlying infrastructure is shared across EmailFig’s managed accounts, the same as it is for any single customer, so it is not total isolation down to the wire. What is isolated is what a platform actually controls: each account’s own counts, its own sending-health read, and the one thing that is shared on purpose is protective rather than pooled. An address that hard-bounces anywhere on EmailFig’s managed sending is suppressed for every managed account, which means an address one client’s list picked up cannot be mailed from another client’s account either. Reputation itself belongs to a domain and an IP, not to an account or a login, which is why account-level isolation still works even though the sending infrastructure underneath is shared.

If a client needs sending infrastructure that is entirely their own with nothing shared at all, that is what BYOS is for: connecting a client’s own Amazon SES account puts their reputation on infrastructure only they use. You can make that call per client, not per agency; one client can run on managed sending while another runs on their own AWS account, independently.

This is worth deciding client by client rather than picking one family for the whole roster. A client with a small, well-behaved list and no appetite for an AWS account is well served by managed sending, where EmailFig’s own import and content checks do the protecting. A client who already runs infrastructure elsewhere, sends in volume, or simply wants their reputation to depend on nobody else’s sending decisions is better served by BYOS, even if it means walking them through connecting an AWS account once. Neither choice locks you out of the other for a different client.

Whose list is it: consent, and what happens when a client leaves

The platform does not settle who owns a client’s list; that is a contract question between you and the client, and worth having in writing before the first import, not after. What the platform gives you is the mechanics for either answer to work.

A client’s contacts export as CSV whenever you want them, the same one-click export any account gets, filtered by list if you only need one. Under 10,000 rows it downloads immediately; above that, EmailFig builds the file in the background and emails a link. The export carries subscribe status, source, tags and lists, and every custom field, which is what a client (or their next tool) actually needs to pick up where you left off. See exporting contacts to CSV.

One thing does not travel cleanly, and it is worth telling a client this before a handoff, not after: suppressions do not export as a re-importable “unsubscribe list” that another tool will honor automatically. Whoever takes a client’s list next has to import their own suppression record separately, or a bounced or complained address can get mailed again somewhere else. Inside EmailFig, that record holds by design: re-importing or re-adding the contact by hand never lifts a hard bounce, a complaint or an unsubscribe. Only the recipient can reverse their own unsubscribe, by signing up again and confirming by email. See suppressions and why an address cannot be re-added.

On consent itself: since you are usually the one signed into the account, you are also the one whose account absorbs the consequences of a list you did not personally collect. Ask a client where a list came from, when, and what people were told, before you import it, the same detail EmailFig’s team would ask for if it looked into the account. A list built by an “email append” service or bought from a broker does not clear that bar regardless of how clean the addresses look; see why purchased lists cause trouble.

Reporting a client will actually read

A client does not want a raw dashboard. They want an answer to “did it work,” and the report page already has one: delivery rate, open rate, click rate and unsubscribe rate across the top, bounce and complaint rates underneath, an engagement chart of opens and clicks over time, and a ranked list of which links actually got clicked. That is what to walk a client through or screenshot into an update, per campaign, on the client’s own account.

Two things are worth explaining to a client the first time you show them a number, so they do not over-read it later. Open rate is inflated by Apple Mail’s privacy protection pre-fetching images, which counts as an open whether or not a person looked; see why open rates read high. And a recipient-level CSV, with delivery status and timestamps for every person on the send, exists for a client who wants the raw data rather than the summary. See reading a campaign report for what every card on the page means, and recipient activity and CSV export for the row-level version.

If a client also runs an automated sequence, a welcome series or a re-engagement drip, that has its own report, separate from a one-off campaign’s, since a running automation never really finishes the way a campaign does. Send a client the campaign report for a launch and the automation report for the ongoing sequence, rather than trying to make one number stand in for both. When the two rates disagree, weight click over open: open is the one already inflated by Apple Mail’s pre-fetching, and click is the number a client can trust at face value.

Pricing your own service so you do not lose money

Each client account is its own subscription, priced on that client’s own contact count, not pooled with your other clients or billed as one line per seat across the roster. That is the number to plan around: your EmailFig cost scales with what each client actually needs, and a client who never grows past a few thousand contacts costs the same whether you have five clients that size or fifty.

Both plan families are free up to 4,000 subscribers, per client account, no card required. A book of small clients can sit almost entirely on the free tier on the EmailFig side; what a client sees on that tier is the “Powered by EmailFig” line on their unsubscribe page, which any paid tier removes. Above the free cap, here is what a few sizes look like on each family, current as of publishing; the full ladder is on the pricing page:

BYOS costs less on the EmailFig side at every size, because on BYOS a client also pays Amazon directly for the sending itself. That AWS bill is worth pricing in before recommending it: see what Amazon SES actually costs for the line items people usually miss. Billing correspondence for every client account, invoices and failed-payment notices included, reaches you rather than a per-client inbox you would otherwise have to chase, so a client falling behind on payment does not depend on them noticing an email you never see.

What you charge on top is yours to work out: some agencies mark up the platform cost, some fold it into a flat retainer, some pass it through at cost and bill separately for the work. Whichever you pick, price it off each client’s own tier rather than off what one big client-management contract would cost on a platform charging per client, since that is not how this one is metered. A flat retainer set once against a small client’s list is the shape most worth rechecking as that client grows, since the tier the retainer was priced against can move well past what it still covers.

A client’s price also moves on its own as their list does, which is worth building into whatever you quote them. Grow past a tier and the account either upgrades automatically or asks to, depending on a setting on that account; shrink back down and it moves down before the next billing cycle regardless. That means a client’s bill can change between the invoices you see, so if you are passing EmailFig’s cost straight through, check it before you forward it rather than assuming last month’s number still holds. See auto-upgrade: what happens when a list grows and how EmailFig pricing works.

Onboarding a client’s sending domain

Use the client’s own root domain, the one their business is known by, not a subdomain and not one of yours. It is what their recipients see in the From address, and it is what carries their reputation, not yours. Adding it needs DNS access, not a mailbox on it, so the person who can act on it is often whoever manages the client’s hosting or DNS, not necessarily who you have been talking to about the campaign itself. See adding and verifying a sending domain and the DNS records EmailFig generates for exactly what to hand them.

A domain can only belong to one EmailFig account at a time, across the whole platform, not just your own book of clients. If a client tried EmailFig on their own before you took over, or verified the domain under a different account years ago, adding it to the client account you manage can collide with that old claim. It is not self-serve to untangle, but it is quick: see “that domain is already in use”.

For a client on BYOS, get their AWS connection working before adding their domain; the domain’s identity is created inside their own AWS account, so there has to be a working connection to create it in. Each client’s AWS connection is independent of every other client’s, so a broken one on one account has no effect on another. See connecting your own Amazon SES account.

Set the expectation up front that DNS changes usually verify within minutes but can take up to 48 hours to spread everywhere, so a domain sitting in “Pending” for a couple of hours after the records go in is normal, not evidence that something is wrong. Getting those records published usually means routing them through whoever actually holds the registrar or DNS login, not the marketing contact you have been talking to, and that handoff is the step most likely to stall a launch for a week rather than a couple of hours.

Plan for who actually holds the keys before you promise a client a launch date. A marketing contact who can approve copy is often not the person who can log into a registrar or a DNS host, and the record set is small (a handful of TXT and MX entries) but has to land correctly, since a typo in one leaves the domain stuck in “Pending” with no error message pointing at which record is wrong. Building a day or two of DNS lead time into a client’s onboarding timeline costs you nothing and saves the conversation where a launch slips because nobody could reach whoever manages the domain.

The operational reality of running many accounts

A client account does not get its own login. Your team signs into it with the accounts they already use everywhere else on the platform, and when you create a new client, everyone already on your side gets access to it automatically, with no separate invite to send per client. There is also no going the other direction: a client account is one level deep, so it cannot spin up sub-clients of its own. If a client ever needs an agency-style setup for their own customers, that is a separate account, not something nested under yours.

What does not come with that convenience is a rolled-up view across clients. There is no single dashboard that adds every client’s numbers together; each client’s reports, sending health and billing live on that client’s own account, the same as they would if it were a standalone customer. For a handful of clients that is a page open per client. For fifty, it is worth building your own tracking sheet on top rather than expecting the platform to hand you one, at least today.

Suspension and abuse review are account-scoped the same way sending reputation is: a review or a pause on one client’s account has no bearing on the others. And each client account keeps its own timezone, adjustable independently of yours, so a client’s send schedule and report dates read correctly for the zone that matters to them.

One limitation is worth stating plainly rather than discovering later: access is not assignable per client. Everyone on your agency’s own roster gets full access to every client account you create, kept in sync as your team changes, not a subset of clients each staff member is scoped to. There is no view-only role and no way to hand a junior account manager reports for one client without also handing them billing and sending controls for every other client on the roster. For a two- or three-person team that is rarely a problem. For a larger one, it is a real constraint to weigh against everything else client accounts get right, not a footnote.

None of this replaces a real conversation with a client about consent, ownership and what happens if the relationship ends; that is a contract question, not a settings page. What it does is remove the platform itself as a reason that conversation goes badly: separate reputations, separate bills, separate exports, and a plain answer on white labelling before you have promised a client something the product will not do. Pricing has the current numbers for both families if you are working out what a specific roster would cost.