Multi-client cold email deliverability requires infrastructure isolation that prevents one client's reputation damage from contaminating another client's inbox placement across shared domains, IPs, or sending infrastructure.
Agencies lose deliverability through 2 failure modes: shared infrastructure contamination and unmonitored per-client reputation decay. Validity's 2025 Email Deliverability Benchmark Report measures global inbox placement at 83.5%, spam placement at 6.7%, and missing mail at 9.8%, confirming that even legitimate email routinely fails to reach the inbox.
This 5-phase, 32-item checklist covers per-client infrastructure setup, inbox provisioning, pre-launch verification, ongoing monitoring, and incident response for agencies managing cold email across 10 or more simultaneous client accounts.
WHAT IS MULTI-CLIENT COLD EMAIL DELIVERABILITY?
Multi-client cold email deliverability is the infrastructure practice of maintaining separate sender reputations for each client to prevent one client's spam complaints, bounce rates, or authentication failures from degrading inbox placement for other clients. Deliverability differs from delivery. Delivery means a receiving server accepted a message. Deliverability means the message reached the inbox rather than the spam folder or the void.
Validity's 2025 Email Deliverability Benchmark Report measured global inbox placement at 83.5%, spam placement at 6.7%, and missing mail at 9.8%. Microsoft Outlook proved the toughest major mailbox provider, with only 75.6% inbox placement. These figures reflect permission-based marketing email, not cold outreach, where placement rates run lower due to absent prior engagement signals.
The isolation principle governs multi-client operations. Each client requires separate domains, separate authentication records, separate IPs, and separate monitoring dashboards. Reputation aggregates at the infrastructure level, not at the individual sender level.
PHASE 1: PER-CLIENT INFRASTRUCTURE SETUP CHECKLIST
Phase 1 requires provisioning a unique secondary domain, configuring SPF, DKIM, and DMARC authentication, establishing a dedicated tracking domain, and verifying forward and reverse DNS alignment before any campaign traffic begins. Every item in this phase executes once per client at onboarding.
1. Register a secondary domain dedicated to outbound email for each client (never send cold email from a client's primary corporate domain)
2. Publish an SPF record as a TXT entry at the domain apex, authorizing all legitimate sending IP addresses
3. Generate a DKIM key of 2048 bits and publish the public key as a DNS TXT record (Google recommends 2048-bit keys for mail sent to personal Gmail)
4. Set a DMARC policy at minimum p=none with alignment checks enabled, then progress to p=quarantine or p=reject as confidence builds
5. Verify that the sending IP's PTR record resolves to a hostname matching the forward DNS entry
6. Configure a custom tracking domain isolated per client to prevent click-attribution contamination across accounts
7. Enable TLS (Transport Layer Security) encryption on all outbound connections
PHASE 2: INBOX PROVISIONING AND WARM-UP CHECKLIST
Phase 2 requires calculating per-inbox daily volume limits, distributing client campaigns across multiple inboxes to stay below provider thresholds, and executing a 2 to 4 week warm-up ramp before reaching target sending velocity. No inbox sends campaign volume on day one.
Calculate each client's required inbox count: client monthly target divided by 22 sending days divided by safe daily limit per inbox. Safe daily limits per inbox range from 50 to 125 emails during warm-up and 200 to 350 at maturity, depending on engagement rates and provider responses. No client inbox shares credentials or sending identity with another client.
Warm-up protocol for new inboxes:
1. Days 1 to 7: Send 50 emails per day to verified, engaged recipients
2. Days 8 to 14: Increase to 100 emails per day; monitor bounce rates daily
3. Days 15 to 21: Increase to 200 emails per day; verify spam complaint rate stays below 0.1%
4. Days 22 to 28: Increase to target volume; confirm inbox placement above 85% through seed testing
HubSpot documents a 40-day warm-up for dedicated IPs and a 30 to 60 day progressive ramp when migrating to a new domain or ESP. Agencies managing 10 or more clients run overlapping warm-up schedules, requiring centralized tracking to prevent ramp collisions.
Google Workspace vs Microsoft 365 Limits for Agencies
Google Workspace limits agencies to 2,000 messages per day per user with 3,000 external recipients daily, while Microsoft 365 allows 10,000 recipients per day per mailbox at 30 messages per minute. Microsoft explicitly states that Exchange Online is not designed for bulk mailing scenarios.
Limit Type | Google Workspace | Microsoft 365 | EmailBison |
Daily Volume per Inbox | 2,000 messages | 10,000 recipients | 500,000 per month (cluster) |
External Recipients per Day | 3,000 | 10,000 (tenant-level, scales with licences) | Unlimited |
Recipients per Message | 500 | 500 | Variable |
Designed for Bulk Sending | No | No | Yes (single-tenant clusters) |
Warm-Up Automation | Manual | Manual | Automated |
Per-Client Isolation | Manual domain configuration | Manual domain configuration | Per-workspace with dedicated IPs |
Microsoft's previously announced per-mailbox External Recipient Rate Limit of 2,000 recipients per day was cancelled in 2026 and never took effect. Many third-party articles still cite this cap incorrectly. The active constraint remains the tenant-level External Recipient Rate Limit, which scales with licence count and defaults to 5,000 external recipients per day for trial tenants.
Google's SMTP relay service permits up to 10,000 messages per 24-hour period per user with a 100-recipient limit per transaction, but this capacity serves application relay, not direct cold email sequencing.
PHASE 3: PRE-LAUNCH VERIFICATION CHECKLIST
Phase 3 requires validating every recipient address to keep hard bounce rates below 3%, confirming DMARC alignment, testing inbox placement across Gmail and Outlook, and verifying sequence copy includes required CAN-SPAM elements before scheduling sends. This phase executes before every new campaign or major sequence change.
1. Run all recipient addresses through a verification service and suppress any address flagging as invalid, disposable, or role-based. Hard bounce rates above 3% trigger reputation penalties at Gmail and Outlook.
2. Test authentication records using diagnostic tools such as MXToolbox or Google Admin Toolbox to confirm SPF, DKIM, and DMARC pass with alignment after any DNS or infrastructure change.
3. Send test messages to seed accounts across Gmail, Outlook, and Yahoo to verify inbox placement before full deployment.
4. Confirm each email includes a valid physical postal address. FTC CAN-SPAM rules require this for all commercial messages, including B2B. Penalties reach up to $53,088 per violation.
5. Verify a clear and functional opt-out mechanism exists in every message. CAN-SPAM requires honouring opt-outs within 10 business days. Gmail requires one-click unsubscribe for bulk marketing messages exceeding 5,000 per day to personal Gmail accounts.
6. Review sequence copy for spam-trigger patterns including excessive capitalisation, misleading subject lines, image-heavy layouts with minimal text, and link-dense formatting.
For UK and EU recipients, the ICO confirms that B2B emails to corporate bodies generally do not require PECR consent, but agencies need a UK GDPR lawful basis, typically legitimate interests. The recipient's right to object to direct marketing under GDPR Article 21 is absolute and requires immediate processing cessation upon objection.
PHASE 4: ONGOING MONITORING CHECKLIST
Phase 4 requires tracking per-client domain reputation in Google Postmaster Tools, monitoring IP reputation through Microsoft Smart Network Data Services (SNDS), running weekly inbox placement tests, and verifying spam complaint rates stay below 0.3% across every active client campaign.
Metric | Tool | Frequency | Action Threshold |
Domain reputation | Google Postmaster Tools | Weekly | Alert if Medium; pause if Low or Bad |
IP reputation | Microsoft SNDS | Weekly | Alert if Yellow; pause if Red |
Spam complaint rate | Google Postmaster Tools | Daily | Alert above 0.1%; pause above 0.3% |
Hard bounce rate | Sending platform dashboard | Daily | Alert above 2%; pause above 3% |
Inbox placement rate | Seed-account testing (EmailGuard, GlockApps) | Weekly | Investigate if below 80% |
Blacklist status | MXToolbox, Spamhaus, Barracuda | Every 72 hours | Initiate delisting immediately |
Volume compliance per inbox | Sending platform dashboard | Daily | Reduce if exceeding safe threshold |
Authentication pass rate | Google Postmaster Tools | Weekly | Fix any SPF, DKIM, or DMARC failures immediately |
Google Postmaster Tools calculates spam rate based on recipient-reported spam on inboxed mail only, not on total sends.
A low reported spam rate coexists with poor actual inbox placement when Gmail routes a large share of traffic to spam automatically before recipients interact with it. Agencies must pair complaint-rate monitoring with external inbox-placement testing to detect silent filtering.
Gmail and Yahoo both enforce a 0.3% maximum spam complaint rate for bulk senders. Rates consistently above 0.3% trigger spam-folder routing, IP reputation penalties, and potential domain-level blocks.
PHASE 5: DELIVERABILITY INCIDENT RESPONSE CHECKLIST
Phase 5 triggers when any client's spam complaint rate exceeds 0.3%, domain reputation drops to Low in Google Postmaster, bounce rates spike above 5%, or a blacklist listing appears, requiring immediate campaign pause, infrastructure isolation, root-cause diagnosis, and graduated reputation recovery.
1. Pause all campaigns for the affected client within 90 minutes of trigger detection.
2. Verify infrastructure isolation. Confirm other clients use separate domains, IPs, and authentication records with no shared tracking domains or overlapping suppression lists.
3. Diagnose root cause by reviewing the past 72 hours of list sources, content changes, volume spikes, authentication failures, and complaint feedback-loop data.
4. Implement the corrective action. Suppress bad list segments, fix authentication records, remove spam-trigger content, or reduce volume to pre-incident levels.
5. Resume sending at 25% of pre-incident volume and increase by 20 to 30% every 3 days over a 14 to 21 day recovery ramp.
6. Document the incident timeline, root cause, and resolution in the client's operational log.
7. Conduct a post-mortem with stakeholders within 5 business days of full recovery.
Isolated infrastructure limits the blast radius. When Client A's purchased list causes an 8% bounce rate, pausing Client A's workspace within 90 minutes contains the damage to that client's domain and IP.
Clients B through N continue sending uninterrupted on their own isolated infrastructure. Minor authentication issues resolve in 7 to 10 days. Major reputation damage from purchased lists or complaint spikes requires 14 to 21 days of re-warming.
THE COMPLETE MULTI-CLIENT DELIVERABILITY CHECKLIST (ALL PHASES)
The complete checklist consolidates all 32 verification items across 5 phases into a single operational table showing each item, its phase, required frequency, and responsible owner.
# | Checklist Item | Phase | Frequency | Owner |
1 | Provision unique secondary domain per client | 1 | Per client onboarding | Infrastructure Lead |
2 | Publish SPF record authorizing sending IPs | 1 | Per domain setup | Technical Admin |
3 | Generate and publish 2048-bit DKIM key | 1 | Per domain setup | Technical Admin |
4 | Set DMARC policy (minimum p=none) | 1 | Per domain setup | Technical Admin |
5 | Verify PTR and forward DNS match | 1 | Per domain setup | Technical Admin |
6 | Configure custom tracking domain per client | 1 | Per client onboarding | Technical Admin |
7 | Enable TLS on all outbound connections | 1 | Per domain setup | Technical Admin |
8 | Provision inboxes at safe volume ratio | 2 | Per client onboarding | Infrastructure Lead |
9 | Begin 2 to 4 week warm-up sequence | 2 | Per new inbox | Deliverability Manager |
10 | Distribute volume across provider mix | 2 | Per campaign | Campaign Manager |
11 | Verify email list hygiene (3% bounce max) | 3 | Per campaign launch | Data Manager |
12 | Re-check SPF, DKIM, DMARC alignment | 3 | Per campaign launch | Technical Admin |
13 | Run inbox placement test across providers | 3 | Per campaign launch | Deliverability Manager |
14 | Confirm valid postal address in footer | 3 | Per campaign launch | Compliance Manager |
15 | Verify functional opt-out mechanism | 3 | Per campaign launch | Compliance Manager |
16 | Review sequence copy for spam triggers | 3 | Per campaign launch | Campaign Manager |
17 | Monitor Google Postmaster domain reputation | 4 | Weekly | Deliverability Manager |
18 | Check Microsoft SNDS IP reputation | 4 | Weekly | Deliverability Manager |
19 | Track spam complaint rate per client (0.3% max) | 4 | Daily | Deliverability Manager |
20 | Track hard bounce rate per client (3% ceiling) | 4 | Daily | Campaign Manager |
21 | Run inbox placement test per client | 4 | Weekly | Deliverability Manager |
22 | Verify volume compliance per inbox | 4 | Daily | Campaign Manager |
23 | Check blacklist status (Spamhaus, SORBS, Barracuda) | 4 | Weekly | Technical Admin |
24 | Audit suppression list accuracy | 4 | Monthly | Compliance Manager |
25 | Pause affected client campaigns | 5 | Incident-triggered | Campaign Manager |
26 | Verify infrastructure isolation from other clients | 5 | Incident-triggered | Infrastructure Lead |
27 | Diagnose root cause (bounces, complaints, content) | 5 | Incident-triggered | Deliverability Manager |
28 | Implement corrective action | 5 | Incident-triggered | Appropriate Owner |
29 | Resume sending at 25% volume over 14 to 21 days | 5 | Post-recovery | Campaign Manager |
30 | Document incident in client operational log | 5 | Post-recovery | Deliverability Manager |
31 | Update suppression list with complaints and bounces | 5 | Incident-triggered | Compliance Manager |
32 | Conduct post-mortem with stakeholders | 5 | Post-recovery | Deliverability Manager… |
HOW OFTEN SHOULD AGENCIES RUN THIS CHECKLIST FOR EACH CLIENT?
Agencies run this checklist at 3 frequencies: setup items execute once per client onboarding, verification items execute per campaign launch, and monitoring items execute daily or weekly depending on campaign activity.
Phase | Frequency | Trigger |
Phase 1 (Infrastructure) | Once per client | New client onboarding or domain migration |
Phase 2 (Provisioning) | Once per inbox batch | New inbox deployment |
Phase 3 (Verification) | Per campaign | Campaign launch or major sequence change |
Phase 4 (Monitoring) | Daily (active), Weekly (dormant) | Campaign runtime |
Phase 5 (Incident Response) | As needed | Spam rate above 0.3%, bounce rate above 5%, or reputation drop |
High-volume clients sending more than 5,000 messages per day require daily Phase 4 monitoring. Technical administrators review Phase 1 DNS records quarterly to verify record integrity and certificate renewals.
Can One Client's Spam Complaints Affect Another Client's Deliverability?
Yes, one client's spam complaints degrade another client's deliverability when both clients share the same sending domain, IP address, or authentication records, because mailbox providers aggregate reputation signals at the infrastructure level.
Gmail aggregates bulk-sender reputation at the primary-domain level, counting all subdomains under one threshold. Gmail also assigns bulk-sender status permanently once a domain sends close to 5,000 messages per day to personal Gmail accounts.
Shared IP addresses combine the reputation of every sender using them, according to Google's sender guidelines. One client's purchased list generating an 8% bounce rate causes IP reputation damage that filters every other client sharing that IP.
Do Agencies Need Separate Domains for Every Client?
Yes, agencies require separate secondary domains for every client because Gmail aggregates bulk-sender reputation at the primary-domain level across all subdomains, making subdomain separation insufficient for reputation isolation.
Spreading traffic across client1.agency.com and client2.agency.com does not create separate Gmail bulk-sender treatment. Both subdomains roll up to the same primary domain. Gmail's bulk-sender classification triggers at close to 5,000 messages per day to personal Gmail accounts, and that classification is permanent once assigned.
HOW DOES EMAILBISON AUTOMATE THIS DELIVERABILITY CHECKLIST ACROSS CLIENTS?
EmailBison automates Phases 2, 4, and 5 of this checklist through single-tenant cluster isolation, integrated warm-up sequencing, and per-workspace deliverability monitoring that eliminates shared-infrastructure contamination across client accounts.
The platform provisions each client in a dedicated workspace with isolated DNS records, dedicated IPs, and separate VPCs. EmailBison's architecture uses single-tenant clusters with static egress and noisy-neighbour isolation, preventing one client's sending behaviour from affecting another client's reputation at the IP or network level.
Multi-client automation coverage:
1. Automated warm-up engine executes the 2 to 4 week progressive ramp schedule per inbox without manual volume adjustments, using a proprietary sending algorithm that adapts to provider response patterns.
2. Per-workspace isolation gives each client separate authentication records, suppression lists, and API scoping. EmailBison's documentation recommends placing each client in its own workspace.
3. EmailGuard integration provides real-time inbox placement monitoring that supplements Google Postmaster Tools and Microsoft SNDS dashboards with cross-provider visibility.
4. Master Inbox aggregates replies across all client workspaces for unified agency response handling with native threading.
5. Webhook and REST API access triggers external alerts when incident thresholds breach and exposes leads, campaigns, replies, and automation endpoints for custom reporting.
6. Unlimited workspaces and teammates included at no additional per-seat cost, supporting agencies managing 10 to 50 simultaneous client campaigns.
EmailBison costs $599 per month for up to 500,000 emails per month across unlimited clients, workspaces, and teammates. The platform is SOC 2 Type II and GDPR compliant, with 25 published policies, 30 documented controls, and an externally audited Trust Centre that supports agency vendor-risk and procurement reviews.
Phases 1 and 3 still require manual DNS configuration and list-verification work. EmailBison automates the operational burden of warm-up, monitoring, volume pacing, and incident isolation, reducing per-client deliverability management from 8 to 12 hours per month to under 2 hours.