SMTP credentials env security means the host, port, username, and secret live in environment variables, not in git. Copy MailerZ values from the dashboard. Never invent 587 or 465 as product facts. Never commit .env. Never paste the secret into a ticket. Free has no send-as. Paid caps still apply. A leaked SMTP secret is an outbound incident, not a reason to rewrite Header From.
Quick answer for smtp credentials env security
Env files are for machines. Repositories are for code. SMTP secrets are not code.
RFC 5321 AUTH is a password-equivalent. Treat it that way.
Copy dashboard values. Do not copy a blog’s port number as MailerZ fact.
Free cannot send-as. A .env will not unlock it.
Rotate on leak. Remap is not rotation.
Start free only to learn inbound. Buy a paid plan before you put SMTP in production env.
Authoritative mail transport is defined in IETF RFC 5321 — Simple Mail Transfer Protocol. Product path: send and reply, docs, and troubleshooting.
User problem and decision criteria
Decision criteria: who can read env in prod, how you inject vars, whether the secret ever hit git, plan caps.
Criteria that do not belong: hardcoding to “move faster,” sharing .env in Slack, inboxing promises.
CI logs that print env are leaks.
Preview deploys with production SMTP are how staging spam happens.
Agencies should use a password manager and platform env, not a zip of .env.
Open relay fantasies are 550.
Do not store the secret in the Next.js client bundle.
Do not invent SOC 2 as a substitute for gitignore.
Technical mail flow
App reads env → SMTP client → MailerZ AUTH → send as alias → destination.
Inbound aliases are a different path.
Caps: Solo five send-as per hour, one hundred outgoing a month. Burst looks like a bot.
AUTH fail: check plan, username, secret, host, TLS mode from dashboard.
History shows the outbound hop when it exists.
Step-by-step setup / decision path
- Confirm paid send-as is in plan.
- Copy dashboard host, port, TLS or STARTTLS, user, secret.
- Put them in env. Gitignore .env. Provide .env.example without secrets.
- Inject the same names in production.
- Send a probe to a third mailbox.
- If leaked, rotate in the dashboard and update env.
- Keep lists off this SMTP.
- Do not log the secret.
Classify the next failure before a second DNS edit.
HOLD unknown unless you wrote a FORWARD reason.
Quote live pricing before promising alias counts.
Failure modes and proof
Committed .env: rotate now.
Gmail password as MailerZ AUTH: fail.
Free plan SMTP: refuse.
Invented port: fail.
Secret in Slack: rotate.
Client-side Next.js public env: leak.
List blast: cap and filters.
Self-send: lie.
Open relay: 550.
Leftover MX blamed for AUTH: wrong ticket.
Inboxing promise.
Unrotated leak after a contractor leaves.
MailerZ workflow and product boundary
MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. Not Workspace, not IMAP, not an open relay, not a campaign ESP.
Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. Exclusive MX. Hold unknown on Free. Copy SMTP host, port, and TLS or STARTTLS from the dashboard when you send.
Free: one domain, three aliases, one seat, fourteen-day store, fifty outgoing a month, no send-as. Solo forty dollars a year, fifteen aliases, ninety-day store, one hundred outgoing, five send-as per hour. Starter eight or eighty. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote pricing. No SOC 2, ISO, HIPAA, SLA, or inboxing percentage.
Cost, alternatives, and trade-offs
A leaked SMTP secret costs reputation and rotate time.
Hardcoding costs a public repo incident.
Paid plan is required for send-as. Budget it.
Caps exceeded look like outages. Upgrade or slow down. Quote pricing.
Agencies: env review is a security line item.
ESP is cheaper than burning reply SMTP on lists.
Ignore inboxing as a security metric.
Password managers beat shared .env zips.
Operational depth
Name vars clearly: SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS, SMTP_SECURE or STARTTLS as your client expects. Match the dashboard, not a tutorial.
Platform env (Vercel, Render, Docker) should be the production source. Local .env is for laptops.
.env.example lists keys with fake values so onboarding does not copy a real secret.
Rotate when people leave. Offboarding includes SMTP.
Staging should use a sink or a dedicated test alias, not customers.
Rate-limit your app so a loop cannot hit the hourly cap and look abusive.
Do not put MailerZ SMTP in a marketing site form without abuse controls. That is how you get used as spam.
AUTH errors belong in the SMTP checklist article’s spirit: read the client error.
Exclusive MX does not fix AUTH.
No HIPAA claim because you used env files.
Probe after every rotate.
Keep the dashboard as the source of truth when tutorials disagree.
Worked scenarios for SMTP secrets in env
A Next.js app reads SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS from the platform env. Values came from the MailerZ dashboard this morning. .env is gitignored. A unique receipt went to a third mailbox. Header From is the hosted alias. That is a finished setup. Nobody invented 587. Free was not used for AUTH.
A contractor committed .env.example that was actually .env. The secret is in git history. Rotate in the dashboard now. Purge the file from history if the repo is public. Then send one probe. Do not 'change the password later this week.' Later is the incident.
Slack has a screenshot of the dashboard including the password. Treat it as leaked. Rotate. Delete the screenshot. Teach paste-prevention. A leaked SMTP secret is outbound mail as your domain, not a reason to rewrite Header From or flap MX.
Staging and production shared one secret. Staging leaked. Production could send. Split identities or accept that staging is production. Agencies that reuse one secret across clients multiply the blast radius.
A GitHub Action prints env on failure. The log has the password. Rotate. Stop printing env. CI is a publisher.
Someone used their Gmail app password as MAIL_PASSWORD because the plugin label said 'email password.' AUTH failed or, worse, they sent through Gmail and the From bounced around. MailerZ AUTH is MailerZ's secret. Copy the dashboard. Do not recycle mailbox passwords.
Practice and anti-patterns for env SMTP
Practice: dashboard copy into env. Anti-pattern: folklore host and port in the README.
Practice: gitignore .env and scan PRs for SMTP_PASS. Anti-pattern: 'it's a private repo' as a control.
Practice: rotate on any paste. Anti-pattern: rotating only if you see spam.
Practice: one secret per environment and per client. Anti-pattern: a shared agency relay.
Practice: third-mailbox probe after rotate. Anti-pattern: assuming the old secret still works and shipping.
Practice: Free users do not put SMTP in env. Anti-pattern: a template .env that implies send-as on Free.
Practice: leftover MX still deleted for replies. Anti-pattern: perfect secrets and split inbound.
Operator closeout after putting SMTP in env
Closeout lists var names, platform (Vercel, Render, box), who can see the values, last rotate date, and a probe ID. Values themselves stay out of the ticket.
gitignore is proven: a fresh clone has no secret. If the secret is in history, the packet says rotated and history cleaned or repo made private with a dated risk acceptance.
Plan name from /pricing. Caps known. No loop of CI test mails.
Who rotates when a contractor leaves. Env without an offboard step is how leavers keep a sending key.
Agencies name the client workspace. A secret in the agency password manager only is a hostage situation.
Link /send-reply and /docs so the next framework change does not invent a port.
Edge cases in credential handling
Serverless bundlers inline env at build time. The secret lands in a public JS chunk. That is not an env file problem; it is a bundler problem. Keep SMTP on the server. Rotate if it shipped to browsers.
Kubernetes secrets mounted as files are still secrets. Do not cat them into Slack to debug. Read whether AUTH failed (pair) or the host timed out (network). Different tickets.
A password manager shared a MailerZ login and someone created a second SMTP user. Inventory users. Offboard extras. Seats are a trust class.
Unicode or trailing spaces in the env value fail AUTH in ways that look like 'the dashboard is wrong.' Re-copy. Do not flap MX.
Two apps, one identity, one secret. A rotate takes both down if you do not order the deploy. Write the order: new secret in both, then revoke old, or accept a brief 550 window.
Someone wants the secret in the repo 'encrypted' with a key that is also in the repo. That is theater. Use the platform store.
Field notes from leaked .env tickets
The expensive tickets are public git history. The cheap tickets are a rotate and a gitignore fix the same hour.
Developers debug AUTH by pasting the whole .env. Teach them to paste host and port only. The secret never needs to be in chat.
WordPress plugins store SMTP in the database. That is not .env, but the same rule: who can export the site owns the secret. Limit admins. Rotate on admin offboard.
RFC 5321 AUTH failing is a pair problem. Leftover MX will not fix 535. Do not add Google MX because a password was wrong.
Use /troubleshooting for codes. 550 unauthorized is expected on Free and on a wrong secret. 421 is not a password.
No SOC 2 story as a substitute for gitignore. /security is the control page. gitignore is still required.
Handoff memo for the next deployer
Var names, platform, rotate owner, dashboard as source, Free has no send-as, leftover MX is inbound and unrelated to AUTH.
The memo forbids README ports. It forbids Gmail passwords as MailerZ AUTH.
CI must not print env. The memo says so because CI will, eventually, unless forbidden.
Contractor offboard includes rotate. Laptop return is not enough.
Probe: one unique message, third mailbox, Header From check. Caps respected.
Acceptance criteria for env SMTP
A fresh clone has no secret. Platform env has dashboard values. One third-mailbox probe succeeded.
gitignore and a secret scan exist. History is clean or a dated risk note exists after rotate.
Paid plan if you send. Free not configured for AUTH. Caps not looped.
No secret in Slack, tickets, or screenshots. Rotate if any appeared.
No folklore port. No php mail fallback that bypasses the secret.
No leftover MX if replies matter. No invented inboxing in the deploy notes.
Operations review of sending secrets
Inventory every store that has the password: platform env, WordPress DB, a laptop .env, a password manager. The longest list wins the next leak.
Review who left. Rotate if they could see the secret. Same week.
Review CI logs for printed env. Fix the workflow.
Review volume versus /pricing. A leaked loop hits caps and heats filters. Caps are a feature.
Review whether staging still shares production. Split or accept the risk in writing.
Rehearse a rotate on a lab identity. The first production rotate should not be during a leak.
Quarterly review of SMTP env hygiene
Did anyone commit .env? Rotate and teach. Did a screenshot land in Slack? Rotate and delete.
Did dashboard host or port guidance change? Re-copy. Memory is a defect.
Did we document 587 as a MailerZ fact? Delete it. Dashboard only.
Did a contractor keep a seat? Offboard. Rotate.
Did we hit a cap with test mail? Slow the CI. Confirm the plan.
Author: MailerZ editorial, Secuno LLC. Review when platforms, pricing, or scope change.
Closing notes on secrets that send as you
SMTP credentials env security means dashboard values live in environment variables, not in git, chat, or a README port table. Copy host, port, TLS mode, user, and secret from MailerZ. Never invent 587 or 465 as product facts. Never use a Gmail password as AUTH.
Rotate on paste. Split environments. Free has no send-as. A leaked secret is outbound as your domain. Fix the secret. Do not flap MX.
Product path: /send-reply, /docs, /security, /pricing. Start free for inbound. Pay before the first AUTH.
People who may see a sending secret
List every human who can read the platform env, the WordPress admin that exports SMTP, the CI maintainer, and the password-manager vault. That list is the blast radius. Offboard is rotate, not only a goodbye lunch.
Developers debug by pasting. Teach a paste rule: host and port yes, password never. If they already pasted, rotate before the lecture. The lecture does not unsend.
Agencies isolate client secrets. A bench engineer with a folder of .env files is a multi-tenant incident. Vault per client. Seat per need.
Founders who screenshot the dashboard into WhatsApp have published the secret to a backup they do not control. Rotate. Delete. Use a password manager share with an expiry if you must share.
Nobody 'owns gitignore' until a commit lands. Assign a CODEOWNERS check or a secret scan. People plus automation. Either alone fails.
Proof packet for a safe env setup
Var names, platform, gitignore evidence from a fresh clone, last rotate date, who can view, paid plan name, one third-mailbox probe ID, Header From screenshot. No password in the packet.
If history once contained the secret, the packet says rotated and whether history was purged. A private repo is not a purge. Write the residual risk.
CI configuration proven not to print env. A redacted log snippet is enough. A full env dump is a new leak.
Staging and production are split or the packet accepts the shared-secret risk in a dated sentence. Silence is not acceptance.
Leftover MX listings if replies matter. AUTH proof is not inbound proof. Keep them in one packet so someone does not 'fix' AUTH with Google MX.
Appendix: places secrets hide besides .env
WordPress options table and site backups. Anyone with export can send as you. Limit admins. Rotate on admin offboard.
Docker images and layer caches. A COPY .env in a Dockerfile is a registry leak. Do not COPY .env. Mount at runtime.
Error trackers that attach request env. Filter SMTP_PASS. Rotate if it already shipped to Sentry.
Laptop backups and AirDrop. A leaked .env.zip in a family photo stream is still a leak. Rotate.
Terraform state. If you put the password in state, protect state like production. Prefer the platform's secret store.
Chat search. Search the workspace for smtp and password. Rotate what you find. Then forbid the pattern.
More operator notes on rotate order
Order for a live app: create or copy the new secret, deploy all consumers, revoke the old secret, probe. Reverse that and you 550 in production on purpose. Sometimes you want that. Write which.
Order for a leak: revoke first, accept 550, then deploy. Speed beats elegance. A leaked secret that still works is still sending.
Dashboard is the only port table. README numbers are defects. RFC 5321 will not tell you MailerZ's host. The dashboard will.
Free has no send-as. A template .env that implies otherwise wastes a day. Delete the implied AUTH from Free templates.
Internal links: /send-reply, /docs, /security, /pricing, /troubleshooting. No invented 587. No SOC 2 as a gitignore substitute.
Author: MailerZ editorial, Secuno LLC. Review when platforms, staff, or pricing change. Start free for inbound. Pay before AUTH.
Extended narrative of a rotate done in order
The secret landed in a public PR because .env.example was a copy of .env. You revoke first. Production 550s for twelve minutes. You put the new dashboard values in the platform env, not in git. You deploy. You send one unique receipt to a third mailbox. Header From is still the alias. You purge history or accept the residual risk in a dated note. You add a secret scan. That is SMTP credentials env security when it is not theoretical.
If you had deployed first and revoked later, the leaked secret would still send while you felt busy. Order is the control. Leak: revoke first. Clean rotate: deploy first, then revoke. Write which you are doing.
The README still says port 587 as if it were a MailerZ constant. You delete that line. You write 'copy the dashboard.' The next intern does not invent a port. Folklore is how AUTH tickets become MX tickets.
Staging shared the secret. You split identities or you write that staging is production. Agencies split per client. A folder of .env files on a bench laptop is a multi-brand incident.
Free was never in env. AUTH on Free is a 550 you can explain. Do not teach a template that implies otherwise. Start free for inbound. Pay before the first password exists.
Endnote on secrets that speak as your domain
Env is for machines. Git is for code. Chat is for neither. Copy the dashboard. Rotate on paste. Do not flap MX because AUTH failed. Do not use a Gmail password as MailerZ AUTH.
Product path: /send-reply, /docs, /security, /pricing. Author: MailerZ editorial, Secuno LLC. Review when platforms, staff, or pricing change.
Last checks before the next deploy
A fresh clone has no secret. Platform env has dashboard values copied today, not remembered. gitignore exists. CI does not print env. One third-mailbox probe succeeded after the last rotate.
Search chat and the repo for the old password. If you find it, you are not done. Rotate again. Delete the paste. Teach the rule after the rotate, not instead of it.
Staging is split or the risk is written. Agencies do not share one secret across clients. WordPress admins who can export SMTP are on the blast-radius list.
Free is not configured for AUTH. Ports are not folklore. Leftover MX is a different ticket. 550 unauthorized is a pair or a plan. It is not a reason to add Google MX.
Error trackers, Docker layers, and site backups still count as copies of the secret. If Sentry or a registry ever saw SMTP_PASS, rotate. A clean gitignore does not unsay a backup zip from last Tuesday.
Write the rotate order in the deploy notes: leak means revoke first; clean rotate means deploy first. The next person will guess. Guessing is a 550 window you did not choose. Copy the dashboard again after every rotate so the new pair is not last year's host from memory. A Gmail mailbox password is never MailerZ AUTH, even when the plugin label says email password.
FAQ
- What is the safest way to handle smtp credentials env security?
- Copy host, port, TLS or STARTTLS, username, and secret from the MailerZ dashboard into env vars. Gitignore .env. Rotate if the secret appeared in chat or a repo. Do not use Gmail’s password as MailerZ AUTH. Probe to a third mailbox.
- Does this require a new mailbox?
- No. MailerZ is not IMAP. Keep Gmail or Outlook unless you need a suite for other reasons.
- Will it work with Gmail or Outlook?
- Yes as destinations. Self-send is not proof. Use a third mailbox and open original.
- What DNS records are involved?
- Sending DNS from the dashboard if you send. Exclusive MX is inbound. AUTH failed is usually a client pair, not MX.
- What should I test before production?
- Send one operational message from the app to a third mailbox. Confirm Header From is the alias. Confirm you did not commit .env.
Key takeaways
- Dashboard values only.
- Never commit secrets.
- Rotate on leak and offboard.
- Free has no send-as.
- Do not invent ports.
- No lists on reply SMTP.
- Staging is not production SMTP.
- Probe after rotate.
Conclusion
Env files are fine when they never become git history. The secret is the product. Copy the dashboard. Rotate when people leave.
Start free for inbound, then put paid SMTP in env the boring way.