Authenticated SMTP custom domain sending is a second hop. The first hop is inbound: MX delivers a named alias into Gmail or Outlook. The second hop is outbound: a client authenticates, offers an approved From, and leaves as that domain. Forwarding does not do the second hop. Free MailerZ does not either. Paid SMTP is a named identity with caps, not an open relay.
Quick answer for authenticated smtp custom domain
Use authenticated SMTP when replies or new messages must show a domain From you control. On MailerZ that means a verified domain, a named alias, leftover MX gone, inbound proven from another mailbox, then a paid plan. Solo is $40 per year and starts send-as. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm MailerZ pricing the day you buy. Free remains inbound-only: one domain, three aliases, 14-day store, send-as disabled, SMTP and API disabled.
Other forwarders document their own SMTP add-ons; see ImprovMX SMTP for that class and quote them live. Do not copy last year’s port list into production. Copy the pair your dashboard shows. STARTTLS and implicit TLS are different conversations. Mixing 587 and 465 fails before a message exists.
Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol. Inbound, a remote server looks up MX and offers an envelope recipient. Outbound, your client looks up the SMTP host you configured, authenticates, offers MAIL FROM and a header From you are allowed to use, and transfers content. Those are two sessions. Envelope SRS may rewrite the return path on the inbound hop so destination SPF can survive. Header From, Subject, Date, Message-ID, body, and MIME stay as received on that hop. Outbound Header From is the named alias you chose.
Google’s people-first guidance is about pages, not SMTP; see creating helpful, reliable, people-first content. A complete guide that skips leftover MX, Free versus paid, and Gmail Send mail as is a slogan. Product language for the outbound hop lives on send and reply.
Authenticated SMTP is not a campaign API, not mailbox IMAP, and not “the internet will accept mail from anyone on this IP.” Unhosted or unauthorized recipients get 550 / 550 5.7.1. Hourly and monthly caps apply. Limits are not an inbox-placement SLA. Destination filters still belong to the far side.
The user problem and the decision criteria
People search authenticated SMTP custom domain after a customer replies to billing@ and the answer leaves as a Gmail address. The thread looks unofficial. Plus addressing does not fix it. Catch-all FORWARD does not fix it. A registrar “include email” webmail does not fix it if you already live in Gmail. You need an outbound identity that matches the inbound name.
| Question | If yes | If no |
|---|---|---|
| Must the visible From be the domain? | Need paid SMTP and a named alias. | Inbound-only is enough. Stay on Free. |
| Is inbound already proven? | Add SMTP. Gmail confirmation can succeed. | Stop. Prove MX and the alias first. |
| Can leftover MX be deleted? | Cutover and Send mail as can work. | Hard stop. Split MX breaks confirmation. |
| Need IMAP folders on the domain? | You are shopping for hosting, not SMTP-on-Gmail. | Keep Gmail. Add authenticated SMTP. |
| Is this a newsletter or app blast? | Buy a campaign or transactional vendor. | People-sending caps may be enough. |
Mailbox SMTP inside Google Workspace or Microsoft 365 is a different object. Those products originate mail from a hosted store. MailerZ originates mail from a paid identity while the store stays Gmail. If every person needs a hosted mailbox, quote the suite live. If two people already live in Gmail and three printed names must send, authenticated SMTP on a forwarder is the smaller object.
Open relays are the failure mode this product exists to refuse. An unauthenticated server that accepts mail from anyone becomes a spam source and gets blocklisted. MailerZ requires authentication and an approved From. That is the “authenticated” in authenticated SMTP custom domain. Do not paste credentials into a random WordPress plugin and call it “just SMTP.”
Shared passwords are a team failure, not an SMTP feature. One SMTP secret in a chat is still a shared secret. Store it in a password manager. Rotate it when someone leaves. Operator seats on Starter and above are dashboard logins, not extra From names and not IMAP users.
Catch-all leftovers cannot send. If a partner still uses an old string and you must reply as that string, create it as a named alias and approve it. Enabling leftover FORWARD does not mint send-as.
Technical mail flow
Inbound remains the foundation. The sending server looks up MX, connects, offers MAIL FROM, names the alias, and transfers content. MailerZ accepts for a verified domain and a matching alias, stores required content, then forwards to the destination you verified. Envelope SRS may rewrite the return path. Header From stays the original author. Unknown local-parts on Free are held. Paid plans can forward them when you enable catch-all FORWARD. That hop does not grant outbound.
Outbound: the client connects to the SMTP host shown in the dashboard, negotiates TLS (STARTTLS upgrade or implicit TLS, not a mix), authenticates, offers a From that matches a named identity, and submits. Solo allows 100 outgoing per month and 5 send-as per hour. Starter is 200 and 10. Business is 400 and 15. Agency is 800 and 25. Those ceilings are stop signs. A 550 on cap is not a filter mystery.
SPF, DKIM, and DMARC evaluate authorization of the outbound hop. 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) are the documents. Publish the values the dashboard shows. They do not move mail into Primary. They do not replace leftover-MX cleanup. They do not turn Free into send-as.
Gmail Send mail as is a verification dance. Gmail wants to receive a confirmation as the alias, then it will submit outbound through the SMTP you paste. Leftover Google MX can swallow that confirmation. Inbound unproven is a hard stop. Outlook’s manual SMTP identity skips Gmail’s confirmation mail and still needs the same MailerZ credentials and a named From.
Thunderbird and Apple Mail use a manual outgoing server the same way Outlook does. The inbox can still be IMAP to Gmail. Mixing “IMAP to MailerZ” is the wrong object. MailerZ is not a store. If the client demands IMAP folders on the domain, you are shopping for hosting.
Self-send from Gmail to the same Gmail account can short-circuit inbound and hide outbound mistakes. Budget two external mailboxes: one to send the inbound probe, one to receive the outbound probe. The Sent folder is not proof.
Recovery is 14 days on Free and 90 days on paid. That store is hop evidence, not a second Sent archive and not legal hold. Gmail or Outlook remains the system of record you search next year. Confirm outbound on the far-side headers, not only in MailerZ history.
Campaign platforms and transactional APIs are other From sources. They need their own SPF and DKIM. Do not share MailerZ SMTP passwords with a random plugin. MailerZ outbound is for people sending as approved aliases within published caps.
Leftover MX is a hard stop for authenticated SMTP custom domain setups because Gmail’s confirmation and real customers share the same public set. Old Microsoft, Google, or registrar records beside MailerZ MX split inbound. Some probes work. Production dies. Delete leftovers before you debug passwords.
STARTTLS upgrades a clear connection. Implicit TLS starts encrypted, usually on 465. Copy the pair MailerZ shows. A dedicated STARTTLS versus TLS article exists for the port math. This guide’s rule is simpler: do not invent the pair. Do not mix them. Encryption in transit is not end-to-end privacy of the body at rest in Gmail.
Operator seats do not mint From identities. Creating five seats does not create five send-as names. Creating five named aliases does. Map destinations. Approve SMTP From for the names you will print. Feature surface: MailerZ features.
BCC does not create a second From. The visible From is the identity you selected. If you need a second public name, create a second alias and approve it. Plus suffixes on a custom-domain alias are not MailerZ send-as identities. Plus addressing is a destination filter convention.
Reply-all is where From leaks most often. A thread started as billing@ collects Gmail addresses when someone hits Reply instead of the Send mail as identity. Write a one-line rule: role threads leave as the role. Personal threads leave as the person.
Website contact forms are a different SMTP consumer. If the form sends as hello@, that is still a named identity and still counts against caps. Do not point a form at MailerZ SMTP on Free. Do not share the same secret with an unmaintained plugin. If the form is the only sender, treat it as an app: least privilege, rotate, watch counters.
rDNS and shared outbound IPs are the host’s problem, not something you configure in Gmail. You cannot pick MailerZ’s outbound IP. You can keep volume inside published caps and keep From aligned. That is the control you have. There is no inbox-placement SLA attached to it.
DMARC p=reject on a domain that still sends from Gmail’s servers as the Gmail address will fail the branded path you wanted. If you publish a strict policy, the only honest From is the one that authenticates. Authenticated SMTP custom domain sending is how that From exists. Publishing reject before SMTP works is how you break your own replies.
Step-by-step setup and decision path
Write the From in one line
Example: “Replies to billing@ must leave as billing@.” That line excludes Free and excludes catch-all leftovers. If the line is “we only need to receive,” stop after inbound.
Create the named alias and prove inbound
Verify TXT. Map a destination. Publish one MX set. Delete leftovers. Probe from another mailbox. Unique subject. Header From intact. Delivery history present.
Upgrade and open SMTP
Solo or higher. Confirm pricing. Copy host, port, encryption, and credentials. Do not paste a Free dashboard into Gmail Send mail as.
Publish SPF, DKIM, and DMARC as shown
Use the dashboard values. Do not merge leftover include: chains until you understand the 10-lookup SPF limit. One sending system is easier than five.
Add the identity in the client
Gmail Send mail as, Outlook manual SMTP, or Thunderbird outgoing. Select that From on reply and on new messages. Phone apps need the same identity or they leak Gmail.
Send outward to a mailbox you do not own
Confirm the visible From. Read raw headers on the far side. Check counters. Then print the alias. Setup notes also live under MailerZ docs.
Failure modes and proof
| What you see | Likely cause | Proof |
|---|---|---|
| Gmail Send mail as will not verify | Still on Free, leftover MX, or inbound unproven. | Plan flag, public MX, external inbound probe. |
| Reply leaves as the Gmail address | Identity not selected, or SMTP never added. | Compose From picker. Far-side headers. |
| 550 on send | Unauthorized From, unhosted domain, or cap. | SMTP response, hourly and monthly counters. |
| Client fails during TLS | Port and encryption pair mismatch. | Copy the dashboard pair. Do not invent 465 versus 587. |
| Self-send never appears | Client short-circuit. | Repeat both hops from other providers. |
| Catch-all leftover cannot send | Expected. Leftovers are not identities. | Create the named alias. Approve From. |
| Far side files spam | Destination filter. Not an inbox SLA. | Headers, alignment, volume. No placement promise. |
| Some customers never reach the alias | Leftover MX. | Public MX from two resolvers. |
Proof is a header block plus a MailerZ event. Do not send SMTP passwords. Do not publish verification tokens. An authenticated SMTP custom domain argument that only shows the Sent folder is still a guess.
Vacation responders on Gmail may reply as the Gmail address unless the alias identity is configured for that path. Check the first auto-reply after you add send-as. A branded invoice followed by an unbranded out-of-office teaches customers the Gmail address.
Shared Microsoft 365 mailboxes and Google Groups follow suite MX. A MailerZ alias follows MailerZ MX. Dual MX is not a hybrid that “covers SMTP.” It is split delivery. Pick one inbound owner, then add SMTP on that owner.
Burst sending on Solo can trip five send-as per hour. Wait, upgrade the card that matches the burst, or admit you need a campaign vendor. Do not open a second unauthorized relay to dodge the cap.
MailerZ workflow and product boundary
MailerZ is a custom-domain delivery layer operated by Secuno LLC. Point MX at MailerZ. Mail for a verified alias lands in Gmail or Outlook. Paid plans add authenticated SMTP so the same name can leave as From. Site: mailerz.net. App: mail.mailerz.net.
- Free $0: 1 domain, 3 aliases, 14-day store, send-as disabled, SMTP and API disabled.
- Solo $40/yr: 1 domain, 15 aliases, 90-day, 100 outgoing, 5 send-as/hr.
- Starter $8/$80: 5 / 50 / 5 seats, 200 outgoing, 10/hr.
- Business $19/$190: 25 / 200 / 25, 400 outgoing, 15/hr.
- Agency $39/$390: 100 / 500 / 50, 800 outgoing, 25/hr.
MailerZ is not IMAP, not a suite, not an open relay, not an inbox SLA, not SOC 2 / ISO 27001 / HIPAA. Controls: Security and Trust Center. Unauthorized send returns 550 / 550 5.7.1. Annual Starter, Business, and Agency include two months free versus monthly. Solo has no monthly option. Dashboard seats are operators, not Gmail logins.
Cost, alternatives, and trade-offs
The cheap-looking choice is inbound-only forever. The expensive choice is customers filing your Gmail address. Solo at $40 per year is the smallest authenticated SMTP card. If you only receive, Free is the honest plan. Do not prepay Agency to “unlock sending.” Sending unlocks at Solo. Agency is domains, aliases, seats, and ceilings.
| Approach | You get | You give up |
|---|---|---|
| MailerZ Free | Inbound aliases, Header From intact on receive. | Any branded reply or new message. |
| MailerZ paid SMTP | Named From, Gmail or Outlook as the store. | Still no IMAP, no inbox SLA. |
| Another forwarder’s SMTP add-on | Sometimes enough. Quote their live SMTP page. | Their rewrite rules, caps, and logging. |
| Suite mailbox SMTP | Hosted store and suite From. Quote live. | Per-user cost if Gmail already held the mail. |
| Campaign / transactional API | Bulk or app mail with its own auth. | People-shaped replies from Gmail. |
Time is a line item. Leftover MX costs more than Solo. A Free-plan branded-reply promise costs more than the upgrade. Budget one outbound probe to a mailbox you do not own.
Registrar cost sits next to SMTP. A .com renewal is often tens of dollars. Quote your registrar. That line does not change when you move from Free to Solo. The incremental bill is send-as capacity and a 90-day store.
Monthly versus yearly is cash flow. Starter, Business, and Agency yearly cards include two months free versus twelve monthly payments. Solo is $40 per year only. Do not prepay Maxi-sized cards because a competitor SMTP page used a large integer.
If every teammate needs a hosted mailbox, a suite is the honest product. A forwarder with SMTP will look incomplete because it is incomplete for stored humans. If two people need seats and twelve printed names are routes, price two Gmail habits plus MailerZ send-as, not fourteen mailboxes.
Open a held body for break-glass recovery and expect an audit row. That is a control, not a SOC 2 badge. Do not send SMTP passwords or verification tokens to support. The artifacts that close an authenticated SMTP custom domain argument are the named alias, exclusive public MX, inbound history, dashboard SMTP pair, and an outbound header on a mailbox you do not own.
VPS “install Postfix and hope” is not authenticated SMTP for a small team. You will fight rDNS, warm-up, and blocklists. MailerZ is not a bulk IP. It will not become one because a guide mentioned a VPS. Test low volume on a paid identity. Do not spray.
Quote vendors the day you buy. This page can drift. Gmail can change Send mail as. Outlook can rename the SMTP dialog. MailerZ limits can change. The tests do not: named alias, exclusive MX, inbound probe, paid From, outbound probe. That sequence is the complete guide that still works next quarter.
Phone From pickers leak more than laptops. After you add send-as, open the Gmail or Outlook app and send one outbound probe from the phone. If the far side shows the Gmail address, the identity is missing on mobile. Fix that before you print billing@ on an invoice.
Two founders sharing hello@ still keep separate Gmail accounts. Map both as destinations. Giving both people SMTP is a secret-sharing decision. Revoke it when one leaves. Routing copies inbound. SMTP is the credential you can rotate.
Interns should not inherit production SMTP on day one. Map them as a destination on a low-risk alias first. If they must send as the role, watch the hourly cap and revoke the same week they leave. Treat intern access as a dated secret. Write the date next to the alias list.
Legal hold is not MailerZ recovery. If counsel needs years of Sent mail, Gmail Vault or Microsoft retention is the store. The 14-day Free window and 90-day paid window will not satisfy that request. Say so in the same meeting where you add SMTP, so nobody treats hop history as the archive.
If you remember one sequence, remember this: named alias, exclusive MX, inbound probe, paid plan, dashboard SMTP pair, outbound probe to a mailbox you do not own. When those six proofs exist, authenticated SMTP custom domain sending is set up. Everything else is caps, clients, and leftover MX you already deleted.
Agencies should not reuse one SMTP secret across client domains. Each zone is a verified identity. Agency’s 100 domains and 25 send-as per hour are capacity, not a shared password. Rotate per client when the engagement ends. That is how authenticated SMTP stays authenticated.
FAQ
What is the safest way to handle authenticated smtp custom domain?
Prove inbound first: named alias, one MX set, leftover host MX deleted, external probe. Then upgrade. Free has no send-as. Copy the dashboard host, port, and encryption pair. Add Gmail Send mail as or a manual Outlook SMTP identity. Send outward to a mailbox you do not own. Do not treat forwarding as outbound.
Does this require a new mailbox?
No. Authenticated SMTP is an outbound hop. Gmail or Outlook remains the store. MailerZ is not IMAP and not webmail. Buy a hosted mailbox only if you need folders on the domain instead of Gmail.
Will it work with Gmail or Outlook?
Yes. Gmail Send mail as submits through the SMTP you paste after inbound confirmation. Outlook uses a manual outgoing server. Both need leftover MX gone and a paid plan. Self-send from Gmail to the same Gmail account can hide success and failure.
What DNS records are involved?
Inbound still needs a verification TXT, one MailerZ MX set, and leftover MX removed. Sending adds the SPF, DKIM, and DMARC values shown in the dashboard. SMTP credentials are not DNS records. Dual MX breaks Gmail’s confirmation mail.
What should I test before production?
Inbound probe from another provider. Then an outbound message as the named From to a second mailbox you control. Confirm the visible From and the far-side headers. Check hourly and monthly counters. Do not use the Sent folder as the only proof.
Key takeaways
- Authenticated SMTP custom domain sending is a paid named From, not a property of inbound MX.
- Free receives. Solo $40/yr starts send-as. Confirm /pricing.
- Copy the dashboard host, port, and encryption pair. Do not mix 465 and 587.
- Leftover MX is a hard stop for Gmail Send mail as and for customers.
- Catch-all leftovers cannot send. Caps are stop signs, not an inbox SLA.
- Envelope SRS on inbound only. Header From untouched on that hop.
- Not IMAP, not an open relay, not SOC 2. Unauthorized send is 550.
- Self-send lies. Probe both directions from other mailboxes.
Conclusion and next action
Authenticated SMTP is how a custom-domain alias leaves as itself. Forwarding only receives. Free only receives. Prove inbound, delete leftover MX, upgrade, copy the SMTP pair, and send outward to a mailbox you do not own. MailerZ fits that sequence. It does not become a mailbox, a campaign platform, or an inbox-placement guarantee.
Ready to prove both hops
Start free with one domain, then add SMTP.
Inbound on Free. Solo when the domain must leave as From. Sign in if the domain is already there.
Review quarterly, or sooner if MailerZ send-as limits or Gmail Send mail as steps change. Author: MailerZ editorial, Secuno LLC.