Agency Email Operations: One Identity Per Client

The situation

Consider a digital marketing agency that runs email programmes for around thirty small and mid-sized clients: retailers, clinics, coaching businesses, a few B2B firms. The agency builds the campaigns, manages the lists and sends the mail. For years it sent everything through a single account, with most clients' mail leaving from the agency's own domain or a generic sending address.

That arrangement was easy and became a liability. When one client, a retailer, imported an old list and sent to it, complaints rose and some of the agency's other clients saw their mail land in spam. Clients began asking whose domain their email actually came from, why their own domain name did not appear, and whether they could see their own delivery reports. Two prospective clients asked about DMARC and the agency could not give a clear answer. The partner who ran operations decided to rebuild the setup around one rule: every client gets their own identity and their own reputation.

Why client isolation matters

Mailbox providers evaluate reputation by sending domain and, for dedicated infrastructure, by IP address. When many clients share one, the weakest client sets the reputation for all of them. Isolation changes the economics: a bad list damages only the client who owns it, and the agency can see which client it is. It also makes the agency's service easier to sell, because a client with its own authenticated domain controls and owns its reputation. We cover how provider rules reinforce this in our bulk-sender analysis.

The design

The client onboarding checklist

The most valuable output of the project was a single page, applied to every new client in the same order. Each step has a gate: the next step does not begin until the previous one is confirmed.

1. Choose the sending subdomain. Pick a subdomain on the client's own domain and keep it separate from the one used for staff mailboxes.
2. Collect DNS access. Either the client adds records or grants the agency delegated access. Records are copied exactly from the sending console.
3. Verify the domain. Confirm that SPF and DKIM pass on a test message, and that the From domain aligns. Our DKIM setup guide covers the steps.
4. Publish DMARC with reporting. Start at p=none with a reporting address the agency can read on the client's behalf.
5. Audit the list. Ask where each segment came from and when it last engaged. Validate addresses before the first send.
6. Warm up gradually. Start with the most engaged contacts and widen in steps, as described in our warm-up guide.
7. Turn on monitoring. Set up delivery events and complaint alerts for the client's stream.
8. Hand over the report. The client receives a monthly view of delivery, complaints and authentication status in plain language.

Migrating the existing clients

Moving thirty clients at once would have been reckless. The agency sorted them into three waves by risk:

• Wave one: the best lists. Clients with recent, permission-based lists and steady volumes moved first. They were the least likely to hit problems and gave the team practice.
• Wave two: the middle. Clients with mixed list quality moved after list audits and sunset rules.
• Wave three: the risky ones. Clients with old or purchased lists were offered a choice: clean the list and move, or stay on a restricted lane with low volume until it was clean. The agency documented this policy in its contracts.

Each client's cut-over followed the same pattern: authenticate the new subdomain, send a small volume alongside the old setup, compare delivery, then switch fully. Our migration guides, such as moving from Mailgun, describe the general approach to moving a sender without losing suppression data.

DMARC across thirty domains

Every client domain now needed a DMARC record and someone to read its reports. Reading thirty sets of XML by hand is not realistic, so the agency designed a routine instead of a tool:

1. All reports for client domains go to one mailbox tagged by client and are processed together.
2. A weekly review lists, for each client, the sources that fail and who owns them.
3. A client moves from p=none to enforcement only when the weekly review shows no legitimate source failing for a defined number of weeks.
4. The monthly client report states the current policy and the next planned step.

This turned DMARC from an unanswered question into a service line. It also gave the agency a concrete answer for the two prospects who had asked. For the background on why this matters, see our DMARC adoption analysis.

Governance: who is allowed to do what

A multi-client operation needs clear boundaries. The agency wrote them down:

• Staff access follows the client assignment. A strategist sees the clients they manage, not the whole book.
• Clients can see their own data and nobody else's.
• Changes to authentication records and policies require a second person's review.
• When a client leaves, their domain records are removed, their data is exported on request and access is revoked the same day.

Handling the objections

Not every client welcomed the change, and the agency prepared short, honest answers in advance:

• "Why do I need to touch my DNS?" Because mail that carries your own domain, signed and aligned, is trusted more than mail sent as a third party, and the records are what prove it. The agency offered to make the changes for them if given access.
• "Will this affect my website or my staff mailboxes?" Not if done on a dedicated subdomain. The checklist includes a step to confirm that existing mail records are untouched.
• "Can't we just send faster?" Sending faster is exactly what damages a new domain's reputation. The warm-up is the quickest safe route, not a delay.
• "Who is responsible if it goes wrong?" The contract and the monthly report make responsibilities clear: the agency owns the setup and monitoring, and the client owns the quality and consent of the list.

How the agency would measure success

We state no numeric outcomes; a real agency should record its own baseline before it starts.

What the agency learned

1. The checklist is the product. Clients value the predictability of a standard process.
2. Isolation is a sales feature. "Your own domain, your own reputation" is easier to explain than shared infrastructure.
3. Risky lists need a policy, not a favour. Writing the rule into contracts removed the awkward conversation.
4. Move in waves. The first wave teaches the team; the last wave is the hardest.

Related reading

• DKIM setup guide
• IP warm-up guide
• DMARC aggregate reports: moving to reject