An agency doesn't have a sender reputation. A domain and an IP do.

An agency does not have a sender reputation. A domain does, and so does an IP address, and mailbox providers judge exactly those two things when they decide whether a message reaches an inbox. That single fact settles whether one client’s bad list can hurt every other client you run: it depends entirely on what domain and what IP that client’s mail actually rides on, not on which login screen or dashboard sent it.

Get the architecture wrong and one client importing a scraped list drags down deliverability for everyone sharing that domain and IP the same week. Get it right and the same mistake is contained to the one account that made it.

That is one half of what separate client accounts are for. See email marketing for agencies for the other half, keeping each client’s contacts, consent and lists apart in the first place.

Key Takeaways

• Mailbox providers score a domain and an IP address, not a company or a piece of software. “Isolated client reputation” only means something once you say which of the two you mean.
• Domain reputation separates cleanly whenever each client authenticates its own domain or subdomain; Google’s own Postmaster Tools guidance tracks a subdomain as a distinct entity from its parent.
• IP reputation does not separate on a shared pool. Google says outright that every sender on a shared IP carries the others’ reputation with it.
• Three real architectures exist: one shared domain for every client, a subdomain per client, and the client’s own domain. Each trades isolation for convenience differently.
• Who owns the domain when a client leaves is the tradeoff that rarely makes it into the pitch.

What a mailbox provider is actually scoring

Gmail, Yahoo and Microsoft don’t know your agency exists. What reaches their filters is a message carrying a From: address, an IP address it arrived from, and, if it’s set up, SPF, DKIM and DMARC records tying it back to a domain. That’s the whole input. Your brand, your login screen, your client’s trust in you: none of it is visible to a spam filter.

Two things get scored, on different terms. Yahoo’s own sender guidance puts it plainly: “Each IP and DKIM domain has a reputation, which can impact the delivery of your email.” Domain reputation attaches to whichever domain actually signs or authenticates the mail: the DKIM signing domain, or the domain aligned through SPF. Google’s own Postmaster Tools guidance treats a subdomain as its own entity: “To see dashboards for subdomains independently from the primary domain, add the subdomains to Postmaster Tools in the same way you add a primary domain.” A subdomain builds, or burns, a reputation history independent of its parent and of any sibling subdomain next to it.

IP reputation works differently, and it caps what any platform, ours included, can honestly promise: on a shared pool of sending IPs, IP reputation does not separate at all. Google’s guidelines are direct about it: “The activity of any senders using a shared IP address affects the reputation of all senders for that shared IP address.” Microsoft’s filters weigh similar ground, factoring in “the sending IP, domain, authentication, list accuracy, complaint rates, content and more”; a degraded IP drags on everyone using it, regardless of who caused the drag. The only way to actually separate IP reputation is to stop sharing the IP: dedicated IPs, or a wholly separate sending account.

That distinction is also why Gmail’s and Yahoo’s bulk sender rules, the authentication and complaint-rate bar that applies once a sender crosses their volume threshold, are enforced per domain rather than per company. A domain that crosses the line carries its own compliance status; a sibling domain sitting one level over in the same organization doesn’t inherit it automatically. Which domain a client’s mail authenticates as decides whose compliance status it lives or dies under. See Gmail, Yahoo and Microsoft’s bulk sender rules for 2026 for exactly what each provider requires and where they don’t agree.

Three architectures, and what one bad client does to each

One domain for every client

The simplest setup sends every client’s campaigns From: name@youragency.com, signed by the agency’s own DKIM key, over the agency’s own sending path. Onboarding a new client takes minutes.

It also means every client shares one domain reputation and, on a shared IP pool, one IP reputation too. A client who imports a bought list, or whose audience simply doesn’t want the mail as much as your best client’s does, drags down the one domain every other client’s mail rides on. Gmail and Yahoo can’t tell your clients apart here. To them it’s a single sender crossing a single threshold.

A subdomain per client

Give each client its own subdomain of the agency’s domain, clienta.mail.youragency.com, clientb.mail.youragency.com, each with its own DKIM key and its own SPF and DMARC setup. Domain reputation now separates the way Google’s guidance describes above: added to Postmaster Tools as a distinct entity, carrying its own history.

What doesn’t separate is the IP, if every subdomain still sends from the same shared pool underneath. A client with a genuinely bad list can still push that pool’s standing down, and every other client sending through the same IPs feels it, even while their own domain reputation reads perfectly clean. Isolating the domain buys a lot. It doesn’t buy everything.

The client’s own domain

The client authenticates their own domain, mail.theirbrand.com or their root domain, into your platform directly: their own DKIM key, their own SPF and DMARC. To a mailbox provider, that domain’s history belongs to the client alone, no matter what anyone else on the platform does. If that client’s list goes bad, their own domain absorbs the damage and no sibling client’s domain does. It’s the cleanest separation on the domain axis, and the only one of the three where the client keeps a self-standing sending identity if they ever leave.

It still rides on whatever infrastructure actually sends the mail. If that’s a shared IP pool, the same limit from the section above still applies underneath it.

Who owns the domain when the relationship ends

That last column is the tradeoff that rarely makes it into a sales conversation. A shared domain, or an agency-owned subdomain, is convenient exactly because the agency controls it, which is also why a client who leaves walks away with nothing on the domain axis: no domain, no accumulated sending history, no DMARC record proving years of legitimate mail.

A client’s own domain flips that. The agency loses nothing operationally, its strategy and content and relationship are still its own work, but the client keeps the one asset that actually compounds: a domain mailbox providers already trust. For a client who might switch agencies, or bring email in-house later, that’s the architecture that protects them. For an agency optimizing for stickiness, it’s the opposite choice, and worth naming as exactly that.

How this plays out on EmailFig

None of this is theoretical for us. Multi-account is live: one login runs a client account per customer, one level deep, and every one of those accounts, the agency’s own included, is fully separate: its own bounce and complaint counts, its own suppression scope, and a required, independently verified sending domain, all belonging to that one account alone. A client connecting their own Amazon SES account sidesteps our infrastructure entirely and keeps their own from the ground up.

That last part rules out the first architecture structurally, not just by policy. A sending domain has to be globally unique across the whole platform: once one account has claimed and verified a domain, no other account, including a sibling client account under the same agency, can claim it for real sending. There’s no route to putting two clients on the literal same domain even if an agency wanted to. What’s left is a choice between the second and third architectures above: hand each client a subdomain of the agency’s own domain, or let the client bring their own domain and authenticate it directly. Both go through the same setup any account uses to add a sending domain, generate DKIM, and publish SPF and DMARC, though a client who doesn’t hold their own DNS access adds a coordination step: getting those records into the hands of whoever actually controls the registrar.

Each client account also picks its own way of sending, independent of its siblings and of the agency’s own account: platform infrastructure, or its own connected Amazon SES account (see platform sending or your own Amazon SES). On platform infrastructure, sending rides the shared IP pool every platform account uses, agency clients and everyone else alike, so the IP-reputation limit above applies exactly as it does anywhere else on the product: domains separate, IPs don’t. A client on their own connected AWS account is off our infrastructure entirely, no longer pooled with our other customers, but whether their own SES sending IPs are shared or dedicated is then their call to make in their own AWS account, at the price dedicated IPs actually cost; our own breakdown of what that AWS bill looks like covers that line item. Anyone weighing the field of tools for this can start from our platform comparisons.

The rule that actually holds

None of this argues against running client accounts from one login. It argues for being exact about what “isolated” means before it gets said to a client. If a platform, ours included, claims a client’s domain reputation is separate from every sibling account, that’s a checkable claim: ask whether every account is required to bring its own verified domain. If it claims a client’s IP reputation is separate, ask whether that’s shared-pool sending or a genuinely dedicated resource, because on a shared pool, by Google’s own account of how it works, that claim isn’t true.

The rule that actually protects a client is unglamorous: give them a domain, their own, or a subdomain nobody else authenticates against, that they don’t share with anyone whose list hygiene is out of your hands, and know honestly whether the IP underneath it is shared too. Everything past that is a login screen, a dashboard and a bill, none of which a mailbox provider has ever once looked at.