Email Deliverability for Agencies: Protect Every Client

Do not index

A client's launch campaign lands in spam, then another account starts showing delivery delays. Both clients use the agency's sending account, and nobody can tell whether the problem started with a list upload, a platform change, or the shared IP.

Email deliverability for agencies starts with controlling how far one client's problem can travel. Separate client identities, accountable access, and monitoring by sending stream help agencies isolate incidents without interrupting healthy campaigns or essential transactional mail.

Table of Contents

What We Check First in an Agency Setup Map the sending identity before reading the metrics Follow the evidence in order Separate Domains, Accounts and IPs for Every Client How far one client's problem spreads by sending setup Dedicated infrastructure has a cost Client Onboarding Checklist Before the First Send Establish the sender and audience Approve operational controls Who Owns DNS, Provider Access and Shared Tools Keep ownership with the client Review shared tools as production infrastructure Weekly Checks Across Every Client Account Weekly checks and the action each one triggers Read the event, not just the percentage Combine daily alerts with a weekly decision meeting What to Do When One Client's List Is Bad Isolate the cause before restarting Don't mistake authorization for demand Common Mistakes When Explaining Deliverability to Clients Explain the incident without hiding uncertainty Avoid promises that create the next dispute Frequently Asked Questions About Agency Deliverability What does SMTP error 550 5.7.515 mean for an agency?Why did placement fall when authentication passes and nothing changed?Should a client's DMARC policy go straight to reject?Confirm Your Client Structure Before the Next Send Complete the operational handoff When to bring in an expert

What We Check First in an Agency Setup

The first diagnostic question isn't whether the subject line looks suspicious. It's whether unrelated clients send through the same identity or infrastructure.

Map the sending identity before reading the metrics

Use a received message and provider event logs to build an inventory for each client:

Visible sender: Record the domain in the From header.

Authentication identity: Read the signing domain in DKIM-Signature and the results in Authentication-Results.

Envelope sender: Record the Return-Path, which can differ from the visible sender.

Sending infrastructure: Identify the account, subaccount, sending IP, and assigned pool.

Shared identifiers create potential reputation connections. They don't prove that every client receives identical filtering, but they identify where an investigation should start.

Follow the evidence in order

Confirm that authentication passes for the actual sending platform and that DMARC alignment works. A signature using the agency's domain isn't automatically a failure, but it doesn't establish the client's identity unless the message has an appropriate aligned authentication path.

Next, identify who controls DNS and provider administration. Then compare complaint, bounce, and deferral trends by client and stream, looking for the earliest change. Only after that should the team examine cadence, content, and list acquisition.

Resources such as HeyNews's guide to AI newsletter writing for agencies address production workflows. Those workflows should remain separate from infrastructure diagnosis, or the team risks rewriting content while the shared sending problem continues.

Keep dated findings tied to configuration changes and campaign launches.

Separate Domains, Accounts and IPs for Every Client

A shared account and sending domain make client separation an accounting label, not a technical control. Separate campaign names won't isolate sender reputation, suppression mistakes, or account-level restrictions.

Choose the sending structure before choosing the reporting dashboard. The structure determines which clients remain exposed when an agency pauses a sender or a provider restricts an account.

How far one client's problem spreads by sending setup

Sending setup	What clients share	How one client's problem spreads	Acceptable when
Shared account and sending domain	Account, domain, IP, and reputation signals	A client's complaints or purchased list can lower placement across client campaigns	Not acceptable for unrelated client work
Separate domains on a shared IP pool	IP reputation and provider history	Risky traffic can affect the pool used by other clients	Low-volume sending with daily complaint monitoring per client
Separate domains and accounts on a shared IP	IP reputation, with account-level controls separated	Shared IP history can still connect otherwise separate clients	Small, low-risk clients with strict stream separation
Dedicated domain, account, and IP per client	No client-level sending identifiers, although upstream infrastructure may remain shared	Direct reputation exposure is substantially contained within the client's streams	High-volume or higher-risk clients with sufficient operational support

Mailbox providers can evaluate the visible From domain, DKIM signing domain, return path, and IP. Changing only the account name leaves the other connections intact.

Subdomains help organize streams, but they aren't a promise of complete independence. Agencies should also assess aggregate primary-domain volume rather than assuming each subdomain operates as an unrelated sender.

Dedicated infrastructure has a cost

A dedicated IP gives a client control over its own IP history. It also adds provisioning, monitoring, and operational work. Small or irregular senders may be better served by a well-managed shared pool than an underused dedicated IP.

Regulated clients may need separate accounts and access controls for governance reasons even when a dedicated IP offers little delivery benefit. Lead-generation clients warrant particularly careful separation because acquisition practices can introduce risk to unrelated promotional and transactional programs.

No infrastructure choice makes a poor list acceptable. Separation limits exposure; it doesn't remove the need to stop harmful sending.

Client Onboarding Checklist Before the First Send

Onboarding should produce evidence that the client is ready to send, not a collection of completed settings screens. The account lead needs an approved sender identity, a defensible audience source, and a clear stop condition.

Establish the sender and audience

Confirm client ownership. Use a domain the client controls rather than an agency domain reused across unrelated businesses. Otherwise, offboarding becomes a reputation and access problem.

Verify authentication. Check SPF, DKIM, and DMARC against the platform sending the messages, including alignment and report delivery. A saved configuration isn't evidence that a received message passes.

Document acquisition. Record how contacts joined, what they expected, consent evidence where applicable, and whether addresses were purchased or rented. Missing provenance prevents a useful investigation when complaints begin.

For personal Gmail accounts, Google's sender requirements classify senders sending about 5,000 or more messages within a 24-hour period as bulk senders, aggregating messages from the same primary domain. Its requirements include SPF and DKIM, DMARC, alignment, valid forward and reverse DNS, TLS, and compliant message formatting.

Approve operational controls

Assign DMARC review. Begin a new deployment with monitoring where appropriate and name the person responsible for investigating reports. Publishing a record without reviewing failures leaves legitimate senders undiscovered.

Separate message purposes. Distinguish promotional, lifecycle, and transactional streams in routing and suppression rules. A marketing opt-out shouldn't accidentally disable a password reset.

Test unsubscribe processing. Confirm the marketing message's one-click mechanism, visible unsubscribe option, and downstream suppression behavior. A working link that doesn't update the sending system still creates complaints.

The written launch approval should identify the approved audience, sending platform, stream, and monitoring owner. Any unresolved authentication failure or unexplained list source should block approval rather than become a task deferred until after launch.

Who Owns DNS, Provider Access and Shared Tools

A new subaccount appears mid-campaign. The visible sender hasn't changed, so the account team assumes the existing configuration still applies. The new subaccount signs differently, its event webhook isn't connected, and nobody notices until reporting becomes incomplete.

That's a change-control failure, not merely a DNS problem.

Keep ownership with the client

The client should retain ownership of its registrar and DNS administration. The agency should receive delegated access with appropriate permissions, rather than becoming the only holder of credentials.

Maintain an access register covering:

Sending systems: Accounts, subaccounts, authorized senders, and permission owners.

Domain identities: From domains, return paths, DKIM selectors, and tracking domains.

Integrations: API keys, webhooks, suppression exports, and connected applications.

Recovery access: Backup administrators and the process for revoking agency access.

Each entry needs a named owner. Without one, a departure or expired credential can delay remediation while campaigns continue failing.

Microsoft's high-volume sender requirements require senders delivering more than 5,000 messages per day to Outlook.com, Hotmail.com, and Live.com addresses to pass SPF, DKIM, and DMARC. Authentication drift therefore creates direct filtering or rejection risk, not just an untidy configuration.

Review shared tools as production infrastructure

Shared template libraries can distribute the wrong tracking domain. Shared suppression imports can remove another client's audience. An incorrectly scoped webhook can attach events to the wrong account, leaving the team investigating misleading complaint data.

Review these connections whenever an ESP migration, vendor addition, new subaccount, or tracking-domain change occurs. Record the approver, expected behavior, test result, and rollback method.

A received-message check should verify the actual authentication outcome, not just the provider's domain-status badge. MailAdept's overview of email authentication provides context for distinguishing authorization from alignment without turning an incident review into a DNS syntax exercise.

A passing test doesn't establish inbox placement. The owner must also watch delivery events and recipient feedback after deployment, when real traffic exposes routing and configuration differences.

Weekly Checks Across Every Client Account

A weekly review answers one question: how far has a new problem traveled? Per-client and per-stream checks exist to catch a fault before it reaches the accounts, IPs, or domains that clients share.

Weekly checks and the action each one triggers

Check	Warning level	Action the same week
Complaint rate per client and stream	Above the agency's internal complaint control limit	Pause the risky stream and trace the campaign or list source
Gmail spam rate in Postmaster Tools	Provider enforcement threshold reached	Stop the affected stream and document the mitigation recovery window
Hard bounce rate per client	Material increase from the stream's baseline	Suppress invalid addresses and investigate acquisition
New blocklist listing for a domain or IP	Any new listing	Identify its relevance, fix the cause, and follow the list's removal process
Deferrals grouped by provider	Sustained rise at a particular provider	Read the error text and adjust sending to that provider
Authentication after a DNS change	Any failure	Correct or roll back the change the same day

The complaint thresholds need explicit ownership. Google's Postmaster guidance recommends keeping its user-reported spam rate below 0.1%; 0.3% or higher has a stronger negative delivery effect, and affected bulk senders lose mitigation eligibility until the rate remains below that threshold for seven consecutive days.

An agency can use the lower level as its internal action trigger. Denominators, available feedback, and reporting coverage differ across mailbox providers, so a complaint metric that looks safe at Gmail may be calculated from a different base elsewhere. Apply each provider's threshold to its own data rather than treating every complaint rate as equivalent.

Read the event, not just the percentage

Postmaster Tools reports on Gmail traffic only. Reconcile its DKIM-authenticated data with the platform's campaign and delivery events before attributing a change to a particular client.

For bounces and deferrals, retain the full SMTP response, recipient provider, campaign identifier, timestamp, and sending identity. A temporary 4xx response needs different handling from a permanent 5xx rejection; repeatedly retrying a permanent failure only adds unnecessary traffic.

Use the free blacklist checker from sister tool mailX to investigate new domain or IP listings. A listing is evidence to assess rather than automatic proof of the incident's cause, and some lists will not explain the affected provider's behavior.

Combine daily alerts with a weekly decision meeting

Set daily complaint and deferral alerts during active sending. A spike that starts on one client's campaign can move along shared IPs or accounts before a weekly dashboard ever shows it.

At the weekly review, assign every finding a date, an owner, an action, and a next check. A finding without an owner stays open while the underlying traffic keeps sending.

The goal of the review is to make sure somebody changes sending behavior when a warning appears.

What to Do When One Client's List Is Bad

Pausing every client is an expensive substitute for diagnosis. It interrupts healthy campaigns and can disrupt essential messages without identifying which sender caused the incident.

Contain the affected stream first. Broaden the pause only when evidence shows a shared account restriction, infrastructure fault, or other exposure that makes continued sending unsafe.

Isolate the cause before restarting

Pause the risky stream. Stop the affected client's promotional or outbound traffic while preserving legitimate transactional routes where they remain healthy. This contains risk without needlessly creating support tickets.

Preserve the evidence. Export complaint, bounce, and deferral events by campaign. Match them to acquisition source, import date, and the last meaningful recipient action so the team can distinguish a bad cohort from a platform-wide incident.

Suppress the problematic audience. Remove complainants from the relevant marketing audience and stop mailing contacts without a defensible reason to receive the campaign. Don't use a fresh account to bypass those suppressions.

Verify remaining addresses. Remove invalid addresses before another send, but don't confuse verification with permission or interest. For lead-generation workflows, Pipecorn's overview of B2B prospect list tools can inform acquisition review, but a sourcing tool doesn't establish that recipients want the messages.

Inspect neighboring clients. Compare delivery trends across shared IPs, signing identities, and accounts. Move or isolate the risky stream when necessary, without treating new infrastructure as permission to resume the same list.

Restart cautiously. Use a clearly defined engaged audience, such as recipients with recent attributable clicks, replies, or relevant customer activity. Increase sending only when complaint and delivery evidence supports it.

Don't mistake authorization for demand

Contactlab's explanation of Microsoft's sender rules illustrates why authentication is a baseline, not evidence that recipients want a campaign. An inactive cohort, abrupt cadence change, or poor acquisition source can undermine results without an obvious DNS failure.

MailAdept's guidance on email list building addresses the acquisition decisions that cleanup alone can't repair. Falling opens also need caution because privacy features can distort that signal; complaints, bounces, deferrals, and attributable actions provide stronger diagnostic context.

Separating the risky sender and correcting its audience can stop continued cross-client exposure. Healthy clients may recover over the following weeks, but the team shouldn't promise a recovery date.

The account lead should explain the affected audience, containment action, evidence required for restart, and next review time. That gives the client an operational decision rather than a vague assurance.

Common Mistakes When Explaining Deliverability to Clients

Agencies control sending identities, audience practices, configuration, and responses to feedback. Mailbox providers decide what reaches the inbox.

Set that distinction before an incident. When clients share infrastructure, a promise made carelessly to one account can erode trust across the whole portfolio.

Explain the incident without hiding uncertainty

A useful client update identifies what happened, which stream is contained, when the next check runs, and what evidence will support another decision. It separates confirmed findings from working hypotheses.

Recovery should be framed as a trend to demonstrate, not a date to guarantee. Poor acquisition also limits what technical remediation can accomplish, so list source belongs in the conversation even when the client prefers to discuss platform settings.

Monthly reporting should include:

Stream-level feedback: Complaint and bounce trends without hiding risky traffic inside an account average.

Provider behavior: Deferrals, rejections, and whether the issue affects a particular destination.

Changes completed: Routing, audience, configuration, and cadence adjustments.

Next action: A named owner and the evidence needed to close the issue.

Avoid promises that create the next dispute

Promising inbox placement turns an uncertain provider decision into an agency commitment. The fix is to state the controls being applied and the outcomes being monitored.

Selling an audit as lasting protection leaves the client assuming a past review covers later changes. A one-time audit identifies issues at a particular moment in time. Monitoring and remediation responsibilities should appear explicitly in the scope of work as continuing items, each with a named owner.

Blaming the platform for an audience problem encourages the client to keep using the same acquisition practices. Include source-level evidence in the report so the decision concerns a specific cohort, not competing opinions.

Treating wording as the primary repair sends the creative team into unnecessary revisions. A spam words checker can support a content review, but it can't establish sender health or compensate for unwanted mail.

Put stream-level complaint and bounce trends at the top of the next monthly report. That figure is the one a client can verify independently, and it anchors every recommendation that follows.

Frequently Asked Questions About Agency Deliverability

What does SMTP error 550 5.7.515 mean for an agency?

Microsoft returns this rejection code for authentication-related noncompliance under its high-volume sender requirements. In an agency context, the first question is which client it affects. Read the full rejection for the sending domain, check the SPF, DKIM, and DMARC results on that domain's traffic, and compare rejected streams client by client. Raising or lowering volume does nothing for a missing or misaligned record, and resolving one client's authentication removes a flag that sits on the shared provider relationship.

Why did placement fall when authentication passes and nothing changed?

Authentication proves authorization and alignment. It says nothing about whether recipients wanted the mail. Check recent audience imports, sending frequency, complaint events, provider deferrals, and engagement on the affected stream. "Nothing changed" usually means nothing changed in the DNS panel. An automation reaching an older cohort or a new acquisition source entering the audience shifts recipient response even when the technical setup is identical. If one client's list quality is the cause, contain it to that account before the pattern reaches shared infrastructure.

Should a client's DMARC policy go straight to reject?

Enforcement follows evidence rather than a blanket rule. Review DMARC reports until every legitimate sender on that domain is authorized and aligned, then move through quarantine before reject. A staged rollout limits the damage if an overlooked system is still signing mail on that domain. A client that arrives with an established, validated enforcement policy keeps it during the handover, since relaxing it reopens spoofing exposure. The decision point is the same either way: reports confirm all legitimate sources are authorized, and enforcement no longer risks blocking wanted mail.

Confirm Your Client Structure Before the Next Send

The immediate decision is which streams pause if one client's reputation drops, and which keep sending. Promotional campaigns can usually wait a week while a complaint spike gets investigated; transactional receipts often cannot. Build the evidence around the actual sending identities. A send calendar organized by client name hides the exposure when three clients share the same domain, IP, or ESP account.

Complete the operational handoff

Consolidate the inventory. Record every client's domain, account, IP allocation, and DNS owner so incident responders don't have to reconstruct access under pressure.

Flag shared exposure. For each connection a client shares with others, decide whether it's acceptable or requires separation before launch.

Close onboarding gaps. Resolve undocumented audience sources and sender configuration failures.

Assign monitoring. Establish daily alerts and a weekly review with accountable owners.

The email deliverability audit checklist supports a self-check across authentication, reputation, and list quality.

When to bring in an expert

Outside help becomes useful when incidents repeat, a migration is approaching, a provider block remains unexplained, or nobody owns DNS and provider access. Those signals point to a diagnostic or operational gap, and another dashboard won't close it.

Run one final test before scheduling: for each client, list every other client who shares their domain, IP, or provider account. Each shared identifier is a route a complaint spike or blacklist event can travel, so mark which streams would pause together. If the pause list surprises anyone on the team, the structure still needs work.

MailAdept provides deliverability consulting for agencies: a dedicated expert audits the setup, fixes what hurts inbox placement, and monitors each sending domain with 12+ daily checks and a weekly expert review. Agencies can visit MailAdept to start with a free deliverability audit and identify shared-infrastructure risks before the next send.