KoltrixEmail Setup for Agencies Managing Many Client Domains
A practical system for agencies that touch email on dozens of client domains: who owns DNS, how to get access, what to record, and how to offboard cleanly.
On this page(8 sections)
- Decide who owns what, in writing
- Getting access without collecting passwords
- The per-client records tracker
- Sending mail on behalf of clients
- Authenticate every sender
- Don't send from your own domain pretending to be theirs
- Keep the replies with the client
- Separating client mail inside the agency
- Monitoring without becoming the help desk
- Offboarding a client cleanly
- Key takeaways
An agency with twenty clients is quietly responsible for twenty sets of DNS records, and usually nobody wrote any of them down. The day a client's contact form stops delivering, someone has to work out from scratch which registrar holds the domain, who added which SPF include, and whether the agency or the client is supposed to fix it.
This guide is a system for avoiding that afternoon. It applies whether you build websites, run marketing, or manage a product for clients, as long as your work causes mail to be sent or received on a domain you don't own.
Decide who owns what, in writing
Most agency email problems are ownership problems first and technical problems second. Before you touch a client's DNS, agree on three things and put them in the statement of work or onboarding doc:
- Who owns the domain registration. It should almost always be the client, in an account the client controls. An agency that registers domains in its own account creates a hostage situation it never intended, and a painful transfer when the relationship ends.
- Who is allowed to change DNS. Name the people on both sides. "The agency may add and modify records needed for the website and forms" is clearer than an unspoken assumption.
- Who is responsible when mail breaks. If your site's contact form sends through a provider you chose, a broken SPF record after the client changes mailbox hosts is still something you'll be asked about. Say in advance how that support is handled and billed.
None of this needs a lawyer. It needs a paragraph that both sides have read.
Getting access without collecting passwords
Agencies end up holding a surprising number of client credentials. Each one is a liability. Prefer, in this order:
- Delegated access. Many registrars and DNS providers let the owner invite another user or grant access to a single domain. Use that wherever it exists.
- A shared vault entry the client controls. If delegation isn't available, ask the client to share the login through a password manager they own, so they can revoke it.
- Screen-share sessions. For a one-off change, have the client log in and make the change while you guide them. Slower, but nothing is left behind.
Avoid credentials sent in plain email. If you inherit them that way, ask the client to rotate the password after the work is done.
The per-client records tracker
The single most useful artifact an agency can keep is a simple record of what it changed on each domain. A spreadsheet works. One row per record, per client:
| Client | Domain | Record type | Host/name | Value (short) | Why it exists | Added by | Date |
|---|---|---|---|---|---|---|---|
| Client A | clienta.example | TXT | @ | SPF incl. form provider | Contact form sends as hello@ |
Agency (Priya) | 2026-03-02 |
| Client A | clienta.example | CNAME | sel1._domainkey | DKIM for form provider | Signs form mail | Agency (Priya) | 2026-03-02 |
| Client B | clientb.example | TXT | _dmarc | p=none, rua to client | Monitoring before enforcement | Client IT | 2026-04-11 |
Two columns earn their place more than the rest. "Why it exists" stops the next person from deleting a record that looks unused. "Added by" tells you whether a change is yours to support.
Before every engagement starts, snapshot the existing records into the same sheet. When something breaks later, you can show exactly what was there before you arrived.
Sending mail on behalf of clients
Agencies commonly cause three kinds of mail to be sent as a client's domain: website form notifications, marketing or newsletter sends, and transactional mail from an app you built. Each needs the same groundwork.
Authenticate every sender
If a service sends as @clienta.example, it needs to be in that domain's SPF record or, better, it needs to sign with DKIM on that domain. The common failure is adding a service's SPF include without checking how many includes are already there. SPF allows only ten DNS lookups during evaluation, and a domain that already uses a mailbox host, a CRM, a helpdesk and a newsletter tool gets there fast. Our plain-English guide to SPF, DKIM and DMARC covers the mechanics.
Don't send from your own domain pretending to be theirs
A form that sends from [email protected] with the client's name in the display name looks like phishing to recipients and filters alike. Send from the client's domain, properly authenticated, or send from yours honestly labeled.
Keep the replies with the client
When a customer replies to a client's form confirmation or order email, that reply belongs in the client's inbox, not the agency's. Check the Reply-To on everything you configure. A reply-to pointing at a developer's address from the build phase is one of the most common things agencies find when they audit old projects.
Separating client mail inside the agency
Your own team also receives a lot of mail about clients: notifications from the client's hosting, form submissions you're copied on during testing, alerts from monitoring. A few habits keep that manageable:
- Use one shared address per client relationship, such as
[email protected], rather than personal addresses. When an account manager leaves, the history stays. - Label or file by client automatically, based on sender domain or the address mail was sent to.
- Turn off agency copies of production form submissions after launch. You don't want a client's customer data sitting in your inbox indefinitely.
If your team works from a shared inbox, per-mailbox permissions let you give a freelancer access to one client's mail without exposing the rest.
Monitoring without becoming the help desk
You can catch most problems before the client does with very little effort:
- Publish DMARC with aggregate reports going to an address the client controls, and get a copy if the client agrees. The reports show every source sending as the domain.
- Run a quick check on each client domain after any DNS change: MX, SPF, DKIM and DMARC. Our DMARC checker and MX lookup are free for exactly this.
- Send a test from every form and app you built after launch and after every change, and look at the authentication results in the headers.
Offboarding a client cleanly
The end of an engagement is when undocumented access does damage. Use a short checklist:
- Remove agency users from the registrar and DNS provider
- Hand over the records tracker for the domain, including what each record does
- List every service that still sends as the domain and who pays for it
- Move any sending accounts in the agency's name to the client, or shut them down with notice
- Update Reply-To and notification addresses that still point at the agency
- Delete stored credentials and confirm the client has rotated them
- Archive the shared client mailbox according to your retention policy
A client who receives this list at the end of a project tends to remember the agency well, even if they leave.
Key takeaways
- Settle ownership of the domain, DNS changes and mail problems in writing before you touch anything.
- Prefer delegated access over shared passwords, and never keep credentials you don't need.
- Keep a per-client records tracker with a "why it exists" column and a before-snapshot.
- Authenticate every service that sends as a client, watch the SPF lookup limit, and keep replies flowing to the client.
- Offboard with a checklist so nothing in the agency's name keeps sending after you've gone.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
