Multi-Accounting for Email Agencies: ESP Logins Without Chaos
How email marketing agencies manage dozens of client ESP accounts (Klaviyo, Mailchimp, SendGrid) with isolated browser profiles, without triggering security alerts.
How an ESP login differs from a regular account
An email marketing agency rarely owns its own sending infrastructure. It works inside client accounts: Klaviyo, Mailchimp, SendGrid (Twilio), ActiveCampaign, HubSpot, Brevo, Omnisend. The client creates the account under their own company, invites an agency manager as a user with a role — and from that point on, everything happening in that account is tied to the client's domain reputation, their subscriber list, and their balance with the ESP.
This isn't the same situation as a Facebook ad account or a marketplace seller account. The difference comes down to one thing: ESP platforms are extremely sensitive to new logins, because millions of emails flow through their infrastructure, and mailbox providers (Gmail, Outlook) watch for anomalies just as closely as the ESPs themselves. That's why Klaviyo, Mailchimp, and SendGrid all have built-in security layers: "new login" emails, confirmation codes sent to the account owner's inbox, temporary holds pending verification. This isn't anti-fraud protection against multi-accounting in the usual sense — it's protection of the client's account against hijacking.
The agency's job isn't to bypass this protection, but to avoid triggering it unnecessarily. The same person should be logging into the same client account from a predictable environment: the same browser, the same time zone, the same IP range. Then the system sees "a normal login" instead of "suspicious activity," and doesn't force the client to confirm a code they weren't expecting every single time.
What happens without profile isolation
A typical picture at an agency with 12–15 clients and 3–4 account managers: 30–50 active ESP accounts, with each manager keeping their own list of logins in notes or a shared file. Everyone logs into client accounts from the same work laptop, through the same Chrome, sometimes even from the same incognito window.
The outcome is predictable:
- Constant login confirmation requests. The ESP sees a change in IP, device, or location between clients and asks for a code sent to the owner's email — and the owner doesn't always respond quickly, so the manager loses time or loses access for the day.
- Session mix-ups. Two client Mailchimp accounts open in adjacent tabs of the same browser is a recipe for errors: an email goes to the wrong list, a segment gets created in the wrong account.
- Context leaking between clients. Cookies, autofill, and search history blend together; the address bar suggests a competitor's domain while working on a different client.
- Dependence on a single employee. Passwords and 2FA are tied to a manager's personal phone. They quit, and the agency can't immediately get into a client account that needs urgent attention.
- No activity history. If a client asks who changed an email template and when, there's nothing to point to — the agency has no log on its own side.
A dedicated profile for each client ESP account solves all five problems at once, not just the first one.
How isolation works in practice
The logic is simple: one browser profile = one client ESP account, with its own set of cookies, a stable fingerprint, and, where justified, its own proxy.
A fingerprint matched to the client. If a client has expectations about their "normal" login geography (the agency works from a specific country, or the client is in a different time zone and asked not to be tied to their location), the profile is configured once — OS, browser version, screen, time zone — and then left alone. Why an inconsistent fingerprint attracts more attention from security systems than the account switch itself is covered in detail in the piece on fingerprint consistency.
Proxies when needed, not by default. For most ESP accounts a proxy isn't mandatory — this isn't a marketplace that bans for self-referrals. A proxy is needed when: the client requires logins strictly from a specific country (an IP allowlist in the account's security settings), the agency runs a manager remotely and wants the login to look local to the client, or several client accounts handled from the same office network need to be separated so they don't create suspicious coincidences. Choosing between datacenter, residential, and mobile IPs for different tasks is covered in the article on proxy types for multi-accounting.
2FA in a vault, not on a manager's phone. Most ESPs offer 2FA via an authenticator app. If the key is tied to an employee's personal phone, the agency is physically dependent on that person. A 2FA key stored inside the profile itself removes that dependency: the code is generated right where the account is open, and is available to whoever the profile is handed to.
Where the line is
It's important to separate two different things that easily get lumped together under "multi-accounting."
Legitimate: an agency manages many real client accounts, each one it was invited into by the actual account owner. Profile isolation here is access hygiene and predictability for the ESP's security systems, not an attempt to impersonate anyone.
Prohibited almost everywhere: opening several ESP accounts for one client to get around free-tier limits, sending from a "clean" new account after the previous one was suspended for spam, or simulating multiple independent senders when it's actually the same list and the same content. ESP rules (Mailchimp, Klaviyo, SendGrid — all of them have a clause on this in their Acceptable Use Policy) explicitly forbid creating duplicate accounts to dodge sanctions for spam complaints. An antidetect browser is neither a tool nor an excuse here: if an account gets suspended for genuine spam complaints, the problem is in the sending practices, not in the platform recognizing a device.
It's also worth clarifying expectations around deliverability. An antidetect browser has no effect on whether an email lands in the inbox or the spam folder. Deliverability is determined by the sending domain's reputation, SPF/DKIM/DMARC configuration, subscriber list quality, and the ESP's own infrastructure — this happens server-side, not in the browser a manager uses to log into the dashboard. Profile isolation helps with a different thing: stable, secure, manageable access to the campaign dashboard itself. If the goal is actually testing deliverability through a network of seed accounts, that's a separate topic with its own methodology.
Team roles and client handoff
An agency rarely has one manager carrying a client from start to finish with no changes. People go on vacation, move to other clients, leave the company. ESP accounts shouldn't be "stuck" with a person when that happens.
A practical role model:
| Role | Access to ESP accounts | Typical actions |
|---|---|---|
| Owner / agency admin | All profiles, all clients | Assigning clients, audits, billing |
| Senior account lead | Profiles for their client group | Reassigning profiles between managers, quality control |
| Account manager | Only assigned clients | Campaign, segment, and automation setup |
| Finance | No access to campaigns, access to ESP billing if needed | Paying the ESP subscription, if the agency handles it |
- lev opened Airdrop zkSync 07
- artem closed FB · US · BM-14
- maya is watching artem
- lev transferred TikTok Shop 03
Per-role profile limits prevent a situation where a junior employee accidentally gets access to 40 clients instead of 5. More on setting up roles, limits, and the handoff mechanism itself — moving a profile between employees without re-sharing passwords — is in the article on team roles, limits, and profile handoff. It also covers the handoff mechanics: a profile with its session, cookies, and 2FA key transfers to the new owner without anyone forwarding a password over chat.
When an employee leaves or moves to a different project, access needs to be closed quickly across all accounts at once, not reconstructed from memory afterward. There's a checklist for exactly this in the piece on closing access when an employee leaves without losing accounts.
Live view for oversight and training
A separate practical benefit of team-based profile work is being able to see what's happening in a client's account without asking a colleague to share their screen on Zoom, and without logging into the same account in parallel — which is exactly what triggers the security alerts the agency is trying to avoid.
Live view and remote control of a colleague's profile are useful in three scenarios: a team lead checks a complex automation setup before it goes live on an actual subscriber list; a new hire learns to work in a specific account under supervision without risking breaking anything; an escalation where a client calls asking "what's happening with the campaign right now" and the responsible manager is unavailable — a senior team member can step into the same profile without creating a second parallel session.
Activity logs as an answer to the client
Email agency clients periodically ask: "who changed the email template on the 14th" or "why did the campaign go to the whole list instead of a segment." A profile activity log isn't a replacement for version history inside the ESP itself (that exists separately) — it's internal agency oversight: who logged into the account, when, from which device. It keeps the team disciplined and gives a quick answer without waiting for the client to dig through Klaviyo's interface themselves.
Encryption and handing an account off to another agency
Email agencies sometimes face the reverse of hiring: a client moves to a different vendor, and access needs to be transferred in an organized way, not by blasting passwords over email. If a profile with its login, cookies, and 2FA key is encrypted on the device with the account password — meaning the server physically can't read the profile's contents — the handover happens in a controlled way: either through time-limited access for the new agency, or by fully transferring the profile and then revoking the old team's rights. How profile encryption and access recovery work when something goes wrong is covered in the article on profile security: encryption, 2FA vault, and access recovery.
Common mistakes
One browser for every client "to save time." Saving five seconds switching profiles costs an hour of email verification when the ESP flags the login as suspicious.
A client password sitting in a shared Google Sheet, unencrypted. Convenient until the wrong person sees the sheet, or it's compromised by a phishing link sent to an employee.
2FA on a manager's personal phone with no backup access. The phone is lost or the employee is on vacation and unreachable — the client's account is unavailable at a critical moment (say, an erroneous campaign needs to be stopped immediately).
One proxy shared across a dozen different client brands at once. If several accounts with different content and different domains regularly log in from the same IP within a short window, it's not a rule violation by itself, but it raises the number of random security alerts on the ESP side — the system has no way of knowing this is a legitimate agency.
No handoff procedure when a client moves between managers. The new manager gets the login and password in a direct message, and the old session stays logged in on another device.
Agency economics
This doesn't require a separate plan just for five client accounts — the free plan already includes 3 profiles, enough to try the approach with a couple of clients. For an agency running 20–40 active ESP accounts, a plan with a matching number of profiles and team roles fits better — and it's noticeably cheaper than an hour of downtime from a locked-out client account, or the dent in trust from a client receiving a "suspicious login detected" email. How to budget for profiles relative to team size is a separate topic, covered in the piece on multi-accounting economics and team profile budgets.
Roles and limits for the team can be set up on the team access page, and encryption and profile protection details are on the security page. Current plans are on the pricing page.
FAQ
Do we need an antidetect browser if the client just shared one login and password with the agency? Yes, if multiple employees use that login at different times. Profile isolation and storing the 2FA key remove the dependency on a specific device and phone, and reduce the number of unnecessary login confirmation requests.
What if the 2FA code goes to the client's phone, not the agency's? That's normal practice for especially security-conscious clients — it means every new device or environment change will require calling the client for a code. Profile isolation reduces how often that happens: a stable environment triggers re-verification less often.
Can one proxy be used across several clients' accounts? Technically yes, if clients have no requirement around login geolocation. But if the accounts are clearly different in content and regularly log in from the same IP almost simultaneously, the risk of random security alerts is higher — it's better to separate at least the most sensitive accounts.
Does an antidetect browser affect email deliverability? No. Deliverability depends on the sending domain, SPF/DKIM/DMARC, the ESP's IP reputation, and list quality — all of that is server-side. The browser and profile only concern access to the dashboard, not the actual sending of emails.
What happens to a client's accounts when the manager who ran them leaves? Hand the profiles — sessions and 2FA keys included — to the new owner through the handoff mechanism, and revoke the departing employee's access the same day. The sequence is laid out in the offboarding checklist.