SMTP username, password and sender identity: what must match?

Quick answer for smtp sender identity authentication

What must match is the issued SMTP username and password with an identity you created and were allowed to send as. Authenticated SMTP is that login. Send as custom domain is the From. SMTP relay in the MailerZ sense is still not a mailbox login and not an open relay.

The username is not always the From. Some systems use a mailbox string as AUTH. MailerZ issues a credential you copy. Treat it as a secret. The From is hello@ or another named identity on a domain you verified. If you never created billing@, do not send as billing@.

Gmail Send mail as stores its own pair. Outlook stores a manual pair. The form plugin stores a pair. Each pair must be the MailerZ values, not a Google password, unless you are intentionally sending through Google as Google.

Inbound aliases do not grant outbound. Creating a route is not creating a send identity. People skip that sentence and file tickets.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as Off, SMTP Off, API Off, and unrouted mail held or rejected only. Solo is $40 per year only, with send-as, SMTP, and API On. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise. A 550 from a mismatched From still appears in Mail Box. Field maps: MailerZ documentation. Copy the dashboard username, password, host, and port as one set. Then set From to an identity you created on that same domain. If any one of those four disagrees, AUTH or From authorization fails. Do not paste a Gmail password into the SMTP field to “make it work.”

authenticated smtp: the real decision

Plugins ask for “email” and “password” as if every host were a mailbox. Operators type hello@ and a random password. AUTH fails or, worse, they reused the Gmail password.

Agencies reuse one credential across clients. A leak is then multi-tenant. Match identity to client, not to convenience.

Developers set From to noreply@ because a tutorial said so, then never create noreply@ as an approved identity. 550 follows. Create the name or pick a name that exists.

Criteria: who issued the secret, which From is approved, which client stores the pair, how you rotate, and whether you are still on Free.

Technical mail flow for smtp sender identity authentication

The client connects, negotiates TLS, and authenticates. Only then does it offer envelope sender and recipients. Policy checks the identity. DKIM signs according to the domain you publish. Receivers apply SPF and DMARC on the return path and From alignment rules they implement.

Header From is what people see. Envelope MAIL FROM is what bounces use. They can differ. They should not randomly differ because a plugin invented envelope-from@localhost.

Mailbox SMTP at Google or Microsoft authenticates as a hosted user. That is a different product. Do not paste those passwords into MailerZ fields or the reverse.

Rate limits apply after AUTH. Hourly send-as ceilings are on /pricing. Bursting a form is not a reason to share the password with a second unofficial app.

Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol. Envelope commands are not the header block people see. MailerZ may rewrite only the envelope return path with Sender Rewriting Scheme. MailerZ is a product of Secuno LLC. It is inbound MX plus authenticated SMTP. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. It is not Google Workspace, not IMAP, and not an open relay. Unhosted or unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Probe from another mailbox. MailerZ is not SOC 2, not ISO 27001, and not HIPAA.

send as custom domain: step-by-step setup

Write the From first. Then create that identity. Then create the credential. Then paste. Reverse order is how leftovers appear in From.

1. Verify the domain and prove inbound. Delete leftover MX.
2. Upgrade if you need send-as. Free has none.
3. Create the named identity you will put in From.
4. Create the SMTP credential. Store it in a manager.
5. Configure one client: Gmail, Outlook, or the form — one at a time.
6. Send to an external inbox. Confirm From and history.
7. Revoke and recreate if the secret leaked or a contractor left.
8. Never email the password to support. Describe the 550 and the Message-ID instead.

Client clicks for Gmail live in Google Gmail Help — Send mail from a different address. Outlook uses a manual SMTP identity when you also send as the domain. Incoming mail stays at the destination mailbox.

Failure modes and proof

Username looks like an email, password is the website admin password. Reset both mental models.

From is a catch-all leftover. Catch-all is not send-as.

Two plugins, one credential, parallel bursts hit the hourly ceiling. Split or rate limit.

STARTTLS on a port that expects implicit TLS. Copy the pair.

Support ticket with the password in the first sentence. Rotate immediately. We will ask for logs, not secrets.

MailerZ workflow and product boundary

MailerZ issues credentials for paid send-as on verified domains. It checks authorization. It is not a mailbox. It is not SOC 2. It stores failed hops inside the recovery window.

Gmail attach steps stay in Google’s help. Outlook attach steps stay in Microsoft’s. This page is the match rule, not a replacement for those UIs.

Unauthorized remains 550. That is success for everyone else on the internet.

Related pages: send and reply, docs, features. Those routes exist on this site. Do not invent a second MX religion beside them.

smtp relay

You pay for the right to send as identities, not for a decorative username. Solo starts that right. Higher plans raise hourly and monthly caps.

Reusing one cheap credential across ten apps looks efficient until rotation night.

A suite mailbox SMTP may be mandatory under corporate policy. Then match that suite’s identity rules instead.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise. Time is part of cost. An afternoon on leftover MX usually costs more than Solo.

Document the From string in the same runbook as MX. Future you will thank present you.

If you change the local-part, update every client the same day. Orphans become 550 and look like “SMTP is down.”

App passwords at Google are for Google. MailerZ passwords are for MailerZ. The words “app password” in a plugin do not make them interchangeable.

Identity match is also a security control. It stops a leaked form from sending as billing@ if billing@ was never approved for that credential’s policy.

Field notes you can reuse

Worked example: noreply@ that never existed

A developer set From to noreply@ because a tutorial used that string. AUTH succeeded. Send failed with 550. The username was valid. The identity was not. SMTP sender identity authentication is a pair. Create noreply@ as an approved name or send as hello@ that already exists. Catch-all does not mint outbound identities.

A second developer reused the Gmail app password in the same plugin fields. Sometimes it sent as Gmail. Sometimes it failed. The words “username” and “password” are not a standard. Copy the MailerZ dashboard pair for MailerZ. Copy Google’s pair only when you intend to send through Google as Google.

Two plugins sharing one credential in parallel can hit hourly send-as limits. That looks like an outage. It is a ceiling. Confirm pricing. Split apps or rate limit.

Envelope versus header

MAIL FROM can differ from Header From. Plugins that stamp envelope-from@localhost create bounce and SPF noise. Set both to the approved domain identity unless you have a written reason. RFC 5321 is the transport. It does not bless localhost as a brand.

STARTTLS versus implicit TLS is a third pair: host, port, mode. Mixing them fails before AUTH. Copy the dashboard. Do not invent 587 versus 465 from memory.

Support should receive a 550 line, a timestamp, and a Message-ID. Support should not receive the password. If you already pasted it, rotate. That is smtp sender identity authentication as hygiene.

Humans and apps

Gmail Send mail as and a form can share an identity. They should not share a password in Slack. Issue two credentials if the product allows, or accept that rotation logs both out. Document the From string in the MX runbook so a rename does not look like “SMTP is down.”

Free users will keep hitting this page. The answer stays short: inbound can work. Send-as cannot. Upgrade before AUTH.

Operator brief

A longer operator brief for smtp sender identity authentication

Teams that bookmark SMTP Username, Password and Sender Identity: What Must Match? usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about smtp sender identity authentication as a send-as, catch-all, or comparison problem.

MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is Mail Box portal webmail, not IMAP, not POP, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.

If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening smtp sender identity authentication. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.

Catch-all forward is not a safety feature for smtp username password and sender identity what must match. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.

Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.

Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear smtp sender identity authentication works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.

Agencies should keep smtp sender identity authentication per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.

Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.

Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.

When SMTP Username, Password and Sender Identity: What Must Match? is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how smtp sender identity authentication stays a runbook instead of an incident.

A second worked pass for smtp sender identity authentication: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a smtp sender identity authentication mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.

A third worked pass: print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.

How to debug a match failure without guessing

Write three lines: the issued username, the From you configured, and the plan name. If the plan is Free, stop. There is no send-as to match. If AUTH failed, the secret is wrong or the TLS pair is wrong. If AUTH worked and the server returned 550 5.7.1, the From is not an approved identity. Create the local-part or pick one that exists. Catch-all does not approve outbound.

If the plugin labeled the first field “email,” it still wants the issued username, not a wish. If Outlook or Gmail stored a Google password, you are on mailbox SMTP for that host, not on MailerZ. Those pairs are not interchangeable. App password language in a UI does not merge vendors.

Envelope MAIL FROM that says localhost is a plugin default. Set it to the approved domain identity unless you have a written reason. Then send to an external inbox with a unique subject. Confirm the visible From. Confirm delivery history. Do not self-send. Do not put the password in the ticket if it failed. Rotate if you already did.

Two apps sharing one credential in parallel can look like an outage when they hit an hourly ceiling. Check pricing. Rate limit the form or the cron. Split credentials if the product allows. Document the From in the same runbook as MX so a rename does not look like SMTP is down.

FAQ

What is the safest way to handle smtp sender identity authentication?

Use the MailerZ-issued username and password on a paid plan, set From to an approved identity on a verified domain, and copy the dashboard TLS pair. Do not use Gmail passwords or uncreated local-parts.

Does this require a new mailbox?

No. Authentication is for a delivery identity. The store remains Gmail or Outlook.

Will it work with Gmail or Outlook?

Yes as SMTP clients when you attach Send mail as or a manual Outlook identity using the MailerZ pair.

What DNS records are involved?

Inbound MX plus SPF, DKIM, and DMARC for the sending domain. Leftover MX does not fix AUTH.

What should I test before production?

Send to an external inbox. Confirm From. Confirm a wrong password fails. Confirm an unapproved From is 550. Do not self-send only.

Key takeaways

• Credential and From are a policy pair.
• Username is not automatically the From.
• Free has no send-as.
• Catch-all is not an outbound identity.
• 550 5.7.1 means unauthorized.
• Copy host, port, and TLS together.
• Do not send passwords to support.
• Rotate at handover.

Conclusion and next action

Match the issued secret to an approved From on a verified domain. That is SMTP sender identity authentication. Everything else is a tutorial that assumed a mailbox host.

Next action: write the From, create it, pay if needed, paste one pair into one client, send outward. Start free only to finish inbound first.

If AUTH already works and From fails, you do not have a password problem. You have an identity problem.

Review quarterly, or sooner if provider behavior, pricing, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.