Should each agency client have their own sending domain?

Yes. Each client should send from their own domain (or subdomain). This isolates reputation—if one client damages their domain reputation, others are unaffected. It also builds brand recognition and allows clients to take their domain if they leave.

Should agencies use shared or dedicated IPs per client?

Most agencies use tiered IP pools: premium clients with good practices get dedicated IPs or high-reputation shared pools. Standard clients share pools grouped by volume and reputation tier. New/risky clients get isolated pools. This balances cost with reputation protection.

How do agencies handle client email authentication?

Each client domain needs its own SPF, DKIM, and DMARC records. SPF includes your sending infrastructure. DKIM uses a selector unique to your system. DMARC starts at p=none and advances based on client maturity. You manage the records but they live on client domains.

What happens to email reputation when a client leaves?

If clients use their own domains, they take their reputation with them (good or bad). If you used agency-owned domains, you keep the reputation but lose the client's brand association. Always use client-owned domains for long-term flexibility.

How many clients can share one IP pool?

Depends on combined volume and reputation similarity. A pool of 4 IPs can handle 20-50 small clients sending 10K-50K emails/month each, or 5-10 medium clients at 100K+/month. Monitor pool reputation—if it dips, identify the problem client and isolate them.

Multi-Sending Domain Strategy for Agencies

The Agency Challenge

Agencies face a unique email infrastructure problem: you manage multiple clients, each with different volumes, list quality, and risk profiles. One client's spam complaint spike can tank deliverability for everyone.

The solution is structured isolation: separate what needs to be separate, share what can be shared, and monitor everything.

Domain Architecture

Use Client-Owned Domains

Every client should send from their own domain:

Good: marketing.clientA.com → Client A's campaigns
Good: news.clientB.com → Client B's newsletters
Bad:  client-a.youragency.com → Mixes your reputation with theirs

Why client domains:

Reputation stays with the client (protects your IP reputation)
Brand recognition in the inbox
Clients can leave without losing their email history
Clean separation for compliance

Subdomain Strategy

Create sending subdomains for each client:

clientA.com (main domain - don't use for marketing)
├── marketing.clientA.com (marketing campaigns)
├── transactional.clientA.com (receipts, confirmations)
└── news.clientA.com (newsletters, optional)

This protects the main domain reputation while allowing you to use different authentication and IP pools per subdomain.

Practitioner note: Some agencies use a single subdomain per client (mail.client.com) for everything. That works for small senders, but if the client grows or has mixed mail types, you'll wish you'd separated earlier. I always set up at least transactional vs marketing separation from day one.

Authentication Setup

Per-Client SPF

Each client's sending subdomain needs SPF:

marketing.clientA.com TXT "v=spf1 include:_spf.youragency.com ~all"
marketing.clientB.com TXT "v=spf1 include:_spf.youragency.com ~all"

Create a dedicated SPF record for your infrastructure:

_spf.youragency.com TXT "v=spf1 ip4:192.168.1.0/24 include:sendgrid.net ~all"

This way, when you add or remove IPs, you update one record and all clients inherit the change.

Per-Client DKIM

Use unique DKIM selectors per client or per agency:

Option A: Agency selector (simpler)

agency._domainkey.marketing.clientA.com CNAME agency._domainkey.youragency.com
agency._domainkey.marketing.clientB.com CNAME agency._domainkey.youragency.com

You manage one key, clients CNAME to it.

Option B: Per-client selectors (more isolation)

clienta._domainkey.marketing.clientA.com TXT "v=DKIM1; k=rsa; p=..."
clientb._domainkey.marketing.clientB.com TXT "v=DKIM1; k=rsa; p=..."

More work but allows per-client key rotation.

Per-Client DMARC

Start every client at p=none and advance based on their sending maturity:

; New client - monitoring only
_dmarc.marketing.clientA.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

; Established client - enforcing
_dmarc.marketing.clientB.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Aggregate all DMARC reports to your monitoring system.

IP Pool Strategy

Tiered Pool Architecture

Pool	Clients	IPs	Use Case
Premium	3-5 high-value	4 dedicated	Best practices, high volume
Standard	10-20 moderate	8 shared	Good hygiene, medium volume
Starter	20-30 small	4 shared	New clients, low volume
Isolation	Problem clients	2	Reputation remediation

Pool Assignment Criteria

Premium Pool (dedicated or near-dedicated):

Clean list (verified, opt-in)
Complaint rate <0.05%
Volume >100K/month
Premium tier pricing

Standard Pool:

Reasonable list hygiene
Complaint rate <0.1%
Volume 10K-100K/month
Regular monitoring

Starter Pool:

New clients (unknown quality)
Volume <10K/month
Under observation for 30-60 days

Isolation Pool:

Known reputation issues
Undergoing remediation
High-risk campaigns

Practitioner note: The isolation pool saves your other clients. When a client's campaigns trigger complaints, move them to isolation immediately. Don't let one bad campaign poison the whole pool. Some agencies resist this because clients complain about "being demoted"—but the alternative is damaging everyone's deliverability.

Infrastructure Options

Option 1: Single ESP, Multiple Subaccounts

Use one ESP with subaccounts per client:

SendGrid Account
├── Subaccount: ClientA (own API key, dedicated IP)
├── Subaccount: ClientB (own API key, shared IP pool)
└── Subaccount: ClientC (own API key, shared IP pool)

Pros: Centralized management, easier billing Cons: All clients on same platform, no ESP redundancy

Option 2: Multiple ESPs

Spread clients across ESPs by need:

Postmark: Transactional for all clients
SendGrid: Marketing for enterprise clients
Mailgun: Marketing for SMB clients

Pros: ESP redundancy, best tool for each job Cons: More complex management, multiple relationships

Option 3: Self-Hosted Core + ESP Overflow

Run your own infrastructure for core clients, use ESPs for overflow:

Mailcow/Postal: Premium clients, full control
SendGrid: Standard clients, managed service

Pros: Cost control at scale, full data ownership Cons: Requires infrastructure expertise

Monitoring Architecture

Per-Client Dashboards

Track independently for each client:

Delivery rate
Bounce rate (hard/soft)
Complaint rate
Open/click rates
Domain reputation (Google Postmaster)

Pool-Level Monitoring

Track for each IP pool:

Aggregate delivery rates
Blacklist status
Gmail/Microsoft reputation
Volume distribution

Alert Thresholds

Metric	Warning	Critical	Action
Bounce rate	>2%	>5%	Investigate list source
Complaint rate	>0.1%	>0.2%	Pause client, review
Delivery rate	<95%	<90%	Check blacklists, reputation
Gmail reputation	Medium	Low	Reduce volume, isolate

Client Onboarding Process

Day 1: Domain Setup

Client provides domain access (or adds DNS records)
Create sending subdomain
Add SPF, DKIM, DMARC records
Verify authentication with test sends

Day 2-7: Warmup

Assign to Starter pool
Begin warmup schedule
Monitor closely for bounces/complaints

Day 8-30: Observation

Track all metrics daily
Address any issues immediately
Build sending history

Day 31+: Pool Assignment

Review 30-day performance
Assign to appropriate pool tier
Set up ongoing monitoring

Client Offboarding

When a client leaves:

Stop sending immediately
Export data (campaigns, metrics, lists) for handoff
Document authentication records client needs to change
Remove from pools - don't leave orphan allocations
Archive configurations for potential return

The client updates their DNS to point to their new provider. Their domain reputation goes with them.

If you're building a multi-client email infrastructure and need help designing the architecture or troubleshooting reputation issues across clients, schedule a consultation.

Sources

M3AAWG: Best Practices for Messaging Service Providers
SendGrid: Subuser Management
Mailgun: Multi-Domain Sending
Google: Sender Guidelines for Bulk Mail

v1.0 · March 2026