Separating agency reputation from client sending domains
Agencies that send Client Co's outbound from the agency's own authenticated domain are borrowing risk in both directions. Client complaints can stain the agency. Agency volume patterns can stain the client. Mailbox providers do not care that your contract said "white label."
GTM runs email and LinkedIn inside client-isolated workspaces with send windows, domain limits, and a compliance gate that stays on. The reputation story has to match that architecture. Client sending domains, client-scoped monitoring, and client-scoped pauses are how you keep one bad week from becoming a multi-client incident.
"Different From names" is not isolation
Volanea's agency guide on shared email infrastructure is clear. Providers score a mix of IPs, authenticated domains, DKIM d= domains, return-path domains, engagement, complaints, and volume consistency. Changing the visible From line while everyone still shares one return-path, one DKIM signer, one queue, and one reputation dashboard is cosplay isolation.
MailerSend's own docs make the same blunt tradeoff for agencies. Sending through the agency's authenticated domain means the client's activity hits the agency's reputation. Authenticating the client's domain is the stronger path for volume, DMARC alignment, and clean separation.
What you actually need per client workspace:
- Client-owned sending domain or clearly delegated subdomain
- SPF, DKIM, and DMARC aligned for that From domain
- Separate return-path or bounce domain when the stack allows it
- Separate suppression store
- Separate volume caps and send windows
- Separate monitoring (Postmaster, complaint rate, bounce rate)
Shared IP pools can still couple tenants at the provider layer. That is why per-client monitoring and automatic pause on abnormal bounce or complaint spikes matter even when domains look separate.
Why agencies mix reputations in the first place
It feels faster. One warmed agency domain. One DNS project. One Postmaster login. One set of warm-up scripts.
It also fails in predictable ways:
- Client A's scraped list spikes hard bounces and the shared domain cools for everyone
- Client B's aggressive offer language drives complaints that land on the agency root
- A rebrand or offboarding leaves Client C stranded because their "sending history" lived on your domain
- DMARC toward p=reject never happens because alignment was never client-native
AWS's SES tenant guidance exists for the same reason SaaS platforms isolate tenants: one customer's reputation problem should not tax the rest. Agencies are multi-tenant operators whether they admit it or not.
A practical separation standard
- Provision the client's domain first. Do not start meaningful outbound volume on a shared agency root "while DNS is pending."
- Authenticate before scale. Seed-test SPF, DKIM, DMARC alignment from the exact path that will send.
- Warm on that domain. Engaged, in-ICP traffic for that client. Keep inside send windows and domain limits.
- Monitor per domain. Google Postmaster Tools should see the client's sending domain, not only an agency aggregate.
- Pause locally. Policy blocks, complaint spikes, or hard bounce spikes pause that client's sending identities. They do not become a reason to burn Client D's domain to "make the week."
- Offboard cleanly. When a client leaves, their domain reputation and suppression history leave with them. Your agency root should not be the artifact they depended on.
The agency root anti-pattern in one paragraph
An agency warms mail.youragency.com, authenticates it once, and lets every client From display change while DKIM and return-path stay on the agency root. QBRs look fine until one client's complaint rate rises. Suddenly every other client on that root inherits slower placement. The fix people reach for is a new agency subdomain. The fix that works is authenticating and monitoring each client's domain as its own reputation unit inside an isolated workspace.
LinkedIn is part of the same story
Email domain separation without LinkedIn seat isolation is half a plan. A contractor seat used for three clients' connection requests couples risk the same way a shared DKIM signer does. Keep LinkedIn identities inside the client workspace. Never spend one client's acceptance health to rescue another client's volume target.
What to tell buyers in plain language
Buyers should ask:
- Whose domain authenticates the mail?
- Can you show bounce and complaint rates for my domain alone?
- What happens to my sending history if we end the engagement?
- Are suppressions and pause rights scoped to my workspace?
If the answer is "we send as you from our infrastructure and it usually works," you are hearing a convenience story, not a reputation architecture.
GTM's product stance is client-isolated workspaces for email and LinkedIn, with compliance controls that do not turn off when volume gets busy. Separation is not a brand preference. It is how multi-client outbound stays operable.
Sources
- https://www.volanea.com/blog/shared-email-infrastructure-deliverability
- https://www.mailersend.com/help/sender-identities-vs-domains
- https://support.google.com/mail/answer/9981691?hl=en
- https://resources.mailertogo.com/guide/multi-tenant-email-architecture-saas-reputation-isolation
- https://aws.amazon.com/blogs/messaging-and-targeting/improve-email-deliverability-with-tenant-management-in-amazon-ses/
- /workspace/trygtm/knowledge/product.md
Want outbound where each client's sending identity stays isolated? Join the waitlist at https://trygtm.com/waitlist.