How to Avoid Shared SMTP Credentials Across Clients

Quick answer for smtp credentials per client

Pay for send-as. Create a credential scoped to that zone. Put it in that site’s secret store. Map From. Send one probe. Product path: features, send and reply, migration planner, pricing. AUTH is IETF RFC 5321 — Simple Mail Transfer Protocol. Quote ImprovMX pricing if you compare hops—do not copy their users onto ours.

Free: 1 domain, 3 aliases, send-as/SMTP/API disabled. Solo $40/yr. Starter $8/$80. Business $19/$190. Agency $39/$390. Confirm live cards. No inbox SLA. Not SOC 2.

Helpful credential docs name the zone: people-first content. A gist titled “smtp for all clients” is an incident waiting for a screenshot.

The user problem and the decision criteria

Agencies ship faster when every site inherits SMTP_USER and SMTP_PASS from a shared template. That template becomes the blast radius. One contractor, one leaked repo, one offboarded intern—every client From is now someone else’s submitter.

The useful isolation is boring: one credential per zone, stored where only that deploy can read it. The useless isolation is “we use a strong password” on a shared user. Strength does not shrink the blast radius.

Technical mail flow

The site authenticates to MailerZ and offers a From that must be mapped on that zone. MailerZ 250s or returns 550 5.7.1. The recipient’s MX is their problem. Your VPS or host must not listen on port 25. That path is how open relays start.

IETF RFC 7208 — Sender Policy Framework (SPF), IETF RFC 6376 — DomainKeys Identified Mail (DKIM), and IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) apply once you send for real. Those records belong to the client zone. Pasting Client A’s SPF include onto Client B is leftover identity, same class of mistake as leftover MX.

Gmail send-as can use the client SMTP user. Follow Google’s send-as help only as UX—Google Gmail Help — Send mail from a different address—then use dashboard host and port. Do not paste a shared agency password into ten Gmail accounts.

Step-by-step setup and decision path

1. Map From on that zone

   Aliases exist. Exclusive MX if replies matter. Pay for send-as.

2. Create a credential for that zone only

   Filename the secret with the zone. Do not reuse last month’s user.

3. Store it in that site’s secret store

   Not the monorepo. Not Slack. Not a shared Doppler project named “all-clients.”

4. Send one unique probe

   Third mailbox. History 250. Header From intact. Delete the script.

5. Write the user on the per-zone sheet

   Noun list is inbound. SMTP user is outbound. Both name the zone.

6. Rotate on leak or offboard

   Do not wait for the next quarter. The old password is still a submitter until you rotate.

Failure modes and proof

Proof is a per-zone user, a secret store that cannot see sibling sites, one history 250, and a rotation date on offboard. “We use 2FA on Gmail” does not replace SMTP isolation. Destination 2FA is still required. It is a different control.

MailerZ workflow and product boundary

Authenticated SMTP plus inbound MX. Envelope SRS. Header From never rewritten. Not IMAP. Not an open relay. Unhosted or unauthorized From is 550 5.7.1. We will not help you design a shared relay that impersonates every client.

Free: 1 domain, 3 aliases, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/yr. Starter $8/$80. Business $19/$190. Agency $39/$390. Confirm pricing. Seats are operators of the map. No inbox SLA. No SOC 2.

Hourly send caps exist so a leaked user cannot become a campaign. Agency is 25 per hour and 800 per month. Caps are not an inbox-placement promise. A shared user that hits the cap takes every client site down together. Isolation also isolates outages.

Cost, alternatives, and trade-offs

Time is a line item. Creating eleven users costs less than one leaked fleet password. Leftover MX is a different invoice. Do not mix them on one ticket.

Env isolation

Hosting panels love “copy environment from staging.” Staging that points at production SMTP is a shared credential with extra steps. Staging should send to a sink mailbox with a staging From you mapped on a staging zone—or it should not send.

CI that prints env on failure is a leak. Redact. Support tickets that paste SMTP_PASS recreate the leak in a third system. See how to avoid sending credentials to support—same rule, fleet scale.

WordPress SMTP plugins store passwords in the database. That is still per site if the password is unique. It is a fleet leak if you reused the agency user. Rotate after any DB dump you emailed to a contractor.

Serverless platforms inject secrets per project. One project per client is the control. One project named “agency-smtp” is the anti-pattern.

Rotate on offboard

When a client leaves, rotate or delete their SMTP user before you delete the aliases—or immediately after, in the same window. Leaving the user live after you remap inbound is how a forgotten cron still sends as their domain.

When an operator leaves the agency, rotate every client user they could read. That is painful. It is cheaper than hoping they forgot. Access reviews exist for this. Seats on the map are not mailbox seats, but they still imply who can mint credentials.

Filename rotation evidence with the zone and the date. “Rotated SMTP” in Slack without a zone is not evidence.

What a leak actually is

A leak is any copy of the password outside the intended secret store: git, Slack, a ticket, a screenshot, a contractor laptop, a leftover .env on a VPS you decommissioned badly. US Federal Trade Commission — CAN-SPAM compliance guide still applies if the leaked user is used to mail strangers. Isolation does not make abuse legal.

After a leak: rotate, check history for unexpected 250s, confirm From maps, tell the client what was possible. Do not add leftover MX “to be safe.” That splits inbound and solves nothing about AUTH.

Two-factor on destination Gmail. HOLD review. Re-query MX after registrar saves if you also cut inbound. IPv6 on the app host is not a reason to open 25.

Night operators who “just reuse the agency SMTP for the weekend launch” recreate the shared user. Write “per-zone credential” on the ticket. If a second operator needs the order, send this page plus the VPS SMTP test article. One user. One zone. One 250. Rotate on offboard.

The artifacts that close smtp credentials per client are a named user per zone, a secret store that cannot see siblings, and a rotation date. Everything else is a shared password with extra ceremony.

One zone, one SMTP user, one secret store

How to avoid shared SMTP credentials across clients is one MailerZ SMTP user per client zone, stored only in that site’s secret store. Map From to aliases on that zone. Rotate on offboard. Never put one password in a shared .env that ten sites inherit. A leak in client A must not mint From for client B. Exclusive MX is still required for inbound. Free has no send-as. Unauthorized send is 550 / 550 5.7.1. MailerZ is not an open relay.

Copy the dashboard host, port, and TLS pair together. Do not paste a Gmail password into a CMS. Do not mail the secret to support. Send a 550 line, a timestamp, and a Message-ID. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Set From to an identity you created on that zone. Do not paste client A’s SPF include into client B. RFC 7208 is per zone. Two v=spf1 records permerror.

Agency is thirty-nine or three hundred ninety when the fleet needs more domains. Business and Starter have lower domain ceilings. Confirm the live pricing page. Hourly and monthly outgoing caps are per account card, not an inbox SLA. This hop is not a campaign sender. Do not warm up by blasting a list through a shared pair.

Envelope SRS only on inbound. Header From stays. MailerZ is not IMAP. Destinations stay Gmail or Outlook. Seats are dashboard people, not mailboxes. Offboard a contractor by revoking their seat and rotating every SMTP user they could see. Offboard a client by deleting MX you own, revoking that zone’s SMTP, and stopping dest forwards into the agency inbox.

What a leak actually is

A pair in a public repo, a Slack paste, a ticket attachment, or a leftover compose file on a laptop is a leak. Rotate in the same hour. Update the one env. Probe once to a third mailbox. Unique subject. History 250. Header From intact. Delete the test script. Do not leave the old pair in a backup.

Shared credentials across clients turn one leak into a fleet incident. Separate users exist so you can rotate A without breaking B. If you already shared, rotate all, split envs, then probe each zone. Related: features, send and reply, security, docs. Not SOC 2. Not HIPAA.

A shared .env that mailed the wrong From

Ten WordPress sites inherited one pair. A form on site B sent From hello@client-a because the plugin defaulted to the first identity the user could authenticate. Dest filed it as confusing. They split credentials, set From per site, probed each, and rotated the old pair. No leftover MX change was required. The inbound hop was already exclusive.

A second shop mailed the pair to support. Treat it as burned. Rotate. Do not ask support to “test with the password.” Self-send is a bad inbound gate and a bad outbound proof. Use a third mailbox.

Fleet checklist

Per client: own SMTP user, own env, own From identities, exclusive MX, leftover delete, one foreign inbound probe, one foreign send-as probe on paid. Rotate on offboard. Confirm /pricing for domain and send ceilings. Start free only to prove inbound on a breakable domain. Sign in if the zone already lives here. That is how to avoid shared SMTP credentials across clients.

Review after a plugin swap or a staff departure. If a CMS still has the old pair, you did not finish rotate. Print the user list from the dashboard and match it to repos. Missing match is a leak waiting.

Repo and CI are part of the boundary

If CI prints env, treat the pair as leaked. Rotate. Mask logs. Do not store the password in a GitHub variable that every fork inherits. Per-client repos get per-client secrets. A monorepo needs per-app secret names, not SMTP_PASSWORD shared. Confirm /pricing for the fleet card. Agency ceilings are domains and aliases, not permission to share one user.

Rotate on offboard even if “they never used SMTP.” They had a laptop backup. Probe each zone after rotate. Unique subjects. Third mailbox. Header From intact. Delete test scripts. Related: send and reply, security, features. RFC 5321. 550 5.7.1 is the boundary working.

Inbound still exclusive

Splitting SMTP does not fix leftover MX. Print MX per client after credential work. Two views. Foreign inbound probe. Then send-as probe. Start free only for inbound practice. Sign in if the zone already lives here. That is how to avoid shared SMTP credentials across clients.

Not SOC 2. Not HIPAA. Store windows are recovery. Do not mail the new pair to a ticket to “confirm rotate.”

One client, one secret, one blast radius

Shared SMTP credentials across clients fail as a security design the day one contractor is offboarded. The remaining clients keep working, so nobody rotates. The departed laptop still submits as every brand. MailerZ paid send-as is authenticated SMTP per identity you enable, not a communal password you paste into five WordPress sites. Free cannot send. Do not invent a shared Free credential. It does not exist.

Agency shape is domains and aliases, not one login stuffed into every wp-config. Seats are people who operate the hop. SMTP secrets are per sending identity or per zone, stored in that client’s environment, not in a spreadsheet titled passwords-final-FINAL. A spreadsheet is a shared credential with extra steps.

Staging must not use production SMTP. A staging plugin that can send as the client From to real customers is an incident waiting for a test form. Separate credential, sink destination, or disabled send on staging. If the host only allows one SMTP user, you do not get a pass. You get a second identity or you do not send from staging.

Rotate on offboard the same day. Disable the identity, issue a new secret, update the one client that used it, probe a stranger mailbox. If you cannot name which client used the secret, you already shared it. That rotation becomes a fleet event. Fleet events are how agencies discover they had one password.

Leftover MX is a different ticket. Shared SMTP does not cause random inbound. Do not republish aspmx because a client 550’d. Read the 550. Plan and identity are hop answers. Wrong From is identity. Port 25 from a VPS is nostalgia. Paid submission is the path.

Header From must be a mapped alias you are allowed to send. Visitor-supplied From on a contact form is spoofing. Shared credentials make that spoof look like five brands at once. Per-client secrets plus a fixed From per site keep the blast inside one zone.

Proof is a stranger mailbox per client after rotate. Self-send lies. A successful send to the operator’s Gmail that already trusts the domain is not proof the next client is isolated. Isolation proof is: client A’s revoked secret cannot send as client B.

Where agencies actually leak the same password

Hosting panels that “copy site.” The SMTP user copies with it. Two clients, one secret. Delete from the copy before DNS goes live. WordPress migration plugins that export wp-config. Chat logs. Password managers with one vault for all clients and a contractor on the vault. Those are shared credentials even if you never named them that.

Registrar mail wizards that offer one mailbox for every domain you add. That is not MailerZ. That is a leftover product. Exclusive MX plus per-zone send-as is the hop model. A registrar mailbox password reused on SMTP is a second product class mashed into the first.

Billing pressure says “one SMTP user is simpler.” Simpler for onboarding. Worse for offboarding. Charge the hour to split secrets now. The incident hour is more expensive. /pricing for seats and domains. Agency caps do not mean one password. They mean many zones you must isolate.

Facts: not an open relay, unauthorized recipients 550, envelope SRS on inbound, Header From intact, no SOC 2 claimed. Start free for inbound practice on one domain. Paid send-as when you enable it, per identity, not per agency folklore. Sign in when the zone already exists.

A rotation drill you can run without a breach

Pick one quiet client. Issue a new SMTP secret. Update only that environment. Confirm the old secret fails. Confirm the new secret sends to a stranger mailbox. Write the minutes. That drill is the training for offboard day. If the drill requires touching four other clients, you are already shared. Split first, then drill.

Put “no shared SMTP” in the client intake. If a prospect wants one credential for ten brands, decline or price the incident. The hop will not save a design you refused to isolate.

Intake questions that force isolation before the first site copy

Ask who will hold the SMTP secret, which environment file it lives in, and what happens on contractor last day. If the answer is “the agency vault,” you still need a per-client item in that vault, not one record named smtp-all. Write the client slug on the secret name. A name that cannot name a client is already shared.

Ask whether staging can send. If yes, it needs a different secret or a sink. If no, disable the plugin on staging in the intake, not after the first leaked test order. Put that line in the statement of work. Clients who refuse isolation are clients you price as a fleet rotation later.

After go-live, send one stranger probe, then revoke a throwaway test secret if you created one. The muscle memory is revoke-and-replace, not hope. Hope is how five brands share one password until a laptop walks out.

FAQ

Key takeaways

• SMTP credentials per client: one user per zone.
• Never share env across sites or a monorepo template.
• Mapped From. Free has no send-as.
• Rotate on leak and on offboard.
• One unique probe. No loops.
• 550 is auth. Leftover MX is inbound.
• Agency when the fleet needs capacity. Confirm /pricing.
• Not IMAP. Not SOC 2. Not an inbox SLA.

Conclusion and next action

If you send as client domains, isolate SMTP the same way you isolate destinations. MailerZ can 250 a From it knows. It will not shrink a blast radius you designed. Start free for inbound, paid when each client must send with its own user.

Review when a client or operator offboards, and after any secret leak. Author: MailerZ editorial, Secuno LLC.