Domain aliases without extra Gmail accounts means support@, sales@, and billing@ are named routes into the inbox you already search. You do not buy three Google users. You create three aliases, publish one MX set, and prove inbound from another mailbox. Gmail send as is a later paid hop if those roles must reply as the domain.
Quick answer for domain aliases without extra gmail accounts
Create support@, sales@, and billing@ as named aliases. Map each to the Gmail you already read — or to different destinations if ownership is split. Verify the domain. Publish one MailerZ MX set. Delete leftover Workspace or registrar MX. Probe each name from an unrelated mailbox. That is domain aliases without extra Gmail accounts.
Custom domain Gmail does not require a Google user per role. Email forwarding to Gmail is the hop. A role address is not a mailbox. Plus tags on a personal Gmail are not custom-domain roles.
Free allows ten aliases. Those three names are the brochure set. A fourth printed string needs a paid ceiling or a shorter site. Do not enable catch-all to hide a missing name.
Gmail send as is optional per role. If support must reply as support@, pay and attach Send mail as for that From. If sales only receives, stay on Free for outbound.
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.
Google’s own Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a product is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol.
custom domain gmail: the real decision
Teams buy Workspace seats so each role has a login. They wanted printed names, not Calendar. The invoice grew. The leftover MX stayed after they “tried” the suite.
They print five roles and create two aliases. The other three sit in hold or vanish at leftover MX. Customers swear they wrote billing@.
One shared Gmail for all three roles without a reply owner produces double answers and leaked personal From lines.
Criteria: list the printed roles, one MX operator, external probe per name, send-as only for roles that reply as the domain.
| Need | Named alias | Extra Gmail/Workspace user |
|---|---|---|
| Printed support@ | Yes | Only if you need a hosted login |
| Searchable archive | Existing Gmail | A second store |
| Reply as the role | Paid send-as | Native on a suite user |
| Fourth public name | Paid alias ceiling | Another seat you may not need |
Prove inbound from another mailbox before you print hello@ on a homepage.
Start free — one domainTechnical mail flow for domain aliases without extra gmail accounts
Each sender looks up MX and offers RCPT TO support@ or sales@ or billing@. A named alias matches and forwards to the mapped Gmail. Header From stays the original author. SRS may rewrite the envelope.
Unknown leftovers are held on Free. info@ is not created because you printed three other names.
Outbound send-as is per approved From. Creating support@ inbound does not let you send as sales@.
Two destinations on support@ are a copy. Name who answers. Do not fan-out catch-all.
MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP or POP, not an open relay. 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. Not SOC 2, not ISO 27001, not HIPAA.
gmail send as
Write the three names. Then click. Do not invent a fourth on launch day.
- List support@, sales@, and billing@ — or the three you actually print.
- Add and verify the domain on the live nameservers.
- Create those three aliases. Map destinations you already read.
- Publish MailerZ MX. Delete leftover suite MX.
- Probe each alias from another mailbox with a unique subject.
- Decide send-as per role. Upgrade only if a From must travel.
- Document who answers each role.
- Review leftover MX after any host change.
Failure modes and proof
Bought three Google accounts. Still had leftover MX. Roles never arrived.
Created only hello@. Printed billing@.
Self-send certified all three names.
Catch-all instead of three aliases.
One SMTP password for every role and a form.
Leftover MX is the usual ghost. Check a public lookup before you blame Gmail.
Open leftover MX troubleshootingMailerZ workflow and product boundary
MailerZ Free is built for this three-name brochure. Paid plans raise alias and send ceilings. Not IMAP. Not a suite. Not an inbox SLA.
Related: email forwarding, send and reply, aliases and catch-all, docs.
Related pages: email forwarding, send and reply, compare Google Workspace, and docs.
email forwarding alias
Three Gmail accounts or three Workspace seats are the expensive wrong buy. Free receives three roles. Solo starts send-as for the roles that reply. Confirm pricing.
Time on leftover MX costs more than Solo.
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.
Field notes you can reuse
Put the three names in the same runbook as MX. When sales leaves, remap sales@ — do not reprint the site.
If finance wants a private store, map billing@ to a different Gmail. That is still not a new Google Workspace user unless they need the suite.
Do not use plus tags like you+billing@gmail.com on the homepage. Print billing@yourdomain.
Agencies: per-client three-name lists. Do not copy one client’s roles onto another zone.
Hold unknowns. A harvest of admin@ should not join support@ in Primary.
If you need more than three names on day one, read pricing before you promise the homepage.
Outlook can be a destination for one of the three. Document it.
This page is not the catch-all agency article. It is three printed roles.
Deeper field notes for domain aliases without extra gmail accounts
Why a role is not a Google user
support@, sales@, and billing@ are public strings. A Google user is a login, a Calendar, a Drive quota, and a seat on an invoice. Mixing those ideas is how a three-person studio ends up paying for three Workspace licenses so a homepage can print three addresses. Domain aliases without extra Gmail accounts keep the strings and drop the seats. The destination is the Gmail you already search. The hop is inbound MX plus a named alias. The login stays one.
People resist this because they watched a suite demo where each role had its own inbox pane. That pane is a mailbox product. MailerZ is not that product. If you need a private store for finance, map billing@ to a different Gmail you already own. That is still not a new Workspace user. It is a second destination. Document who holds the password. Do not invent a fourth Google account because the spreadsheet has a blank row.
The three-name inventory that actually ships
Write the three strings you will print this quarter. Not the five you might print after a rebrand. Free allows ten aliases. Those three slots are the brochure. If the site already prints hello@, support@, and billing@, sales@ is a fourth string and a plan conversation, not a catch-all workaround. Catch-all is not a missing-name feature. It is a leftover policy.
Put the inventory next to the MX operator name. When a contractor leaves, remap the alias. Do not reprint the site. That remap is why the role is cheaper than a seat. A seat offboard is an admin ticket. An alias remap is a destination change. Probe the remapped name from another mailbox the same day. Self-send after a remap is still invalid.
Who answers which role
Three aliases into one Gmail only work if someone owns the reply. Support that sits in a shared Primary tab with sales invoices produces double answers and a personal Gmail From on a customer thread. If support must reply as support@, that is paid send-as plus Gmail Send mail as for that From. If sales only receives inbound quotes, leave it receive-only on Free. Do not attach one SMTP password to every role “just in case.”
A simple ownership card: support answered by ops, sales answered by the founder, billing answered by the bookkeeper’s Gmail. Two destinations on support@ are a copy. Name the copy. Do not fan-out catch-all into both. Plus addressing on the personal Gmail is not a custom-domain role. Do not print you+support@gmail.com on a footer.
What leftover suite MX does to roles
If Google still answers the zone, support@ never hits the alias map. The suite mailbox for that local-part — or a reject — wins. Teams then buy more seats because “forwarding is broken.” Forwarding never saw the copy. Delete leftover Workspace MX after you have the named aliases and a probe plan. Save the old MX set. Wait for TTL. Probe each of the three names from an unrelated provider.
Registrar forwarding toggles are the other ghost. A host that still accepts mail is not load balancing. Priority numbers are an order. A leftover host with a better preference eats the role. Public lookup, not the registrar summary table, is the proof.
When the fourth name appears
Launch day prints three names. A month later legal wants counsel@. That is a paid alias ceiling or a retired brochure name. Do not enable catch-all so counsel@ “just works.” Hold unknowns. Review the store. Promote a leftover only when a real person used it. Unlimited aliases as marketing will not save a missing list.
Agencies copy one client’s three-name list onto the next zone. Stop. Per-client inventory. Separate SMTP if they send. Agency plan capacity exists so you can hold more domains. It does not replace a named list.
Gmail labels versus extra accounts
Filters on To: support@ yourdomain are enough for most studios. A second Gmail account is not a filter. It is another password and another place mail can hide. If two people must see support@, add the second person as a destination or share the Gmail. Do not buy Workspace so they can “have their own support login” unless they also need Calendar and admin.
Outlook as one of the three destinations is fine. Document it. Probe it. Do not assume a Microsoft destination inherits Gmail send-as. Each From is its own outbound hop.
A complete worked story
A studio that almost bought three Workspace users
A three-person studio was quoted three Workspace seats so support@, sales@, and billing@ would “look real.” They already shared one Gmail for operations. They needed printed names, not Calendar. They created the three aliases on MailerZ Free, cut leftover registrar MX, and probed each name from a colleague. All three landed. They did not buy the seats. A month later support needed to reply as support@. They paid Solo, attached Send mail as for that one From, and left sales receive-only.
The week that would have failed: printing five roles, creating two aliases, and certifying with self-send. billing@ would have sat in hold or at leftover Google. They wrote the three names first. That inventory step is the article.
When the sales contractor left, they remapped sales@ to the founder Gmail. The website did not change. That is why a role is not a seat.
Operator brief
A longer operator brief for domain aliases without extra gmail accounts
Teams that bookmark How to Create support@, sales@ and billing@ Without Extra Gmail Accounts 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 domain aliases without extra gmail accounts 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 domain aliases without extra gmail accounts. 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 how to create support sales and billing without extra gmail accounts. 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 domain aliases without extra gmail accounts 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 domain aliases without extra gmail accounts 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 How to Create support@, sales@ and billing@ Without Extra Gmail Accounts 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 domain aliases without extra gmail accounts stays a runbook instead of an incident.
A second worked pass for domain aliases without extra gmail accounts: 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 domain aliases without extra gmail accounts 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@.
FAQ
- What is the safest way to handle domain aliases without extra gmail accounts?
- Create named aliases for the printed roles, map them to Gmail you already use, publish one MX set, delete leftover hosts, and probe each name from another mailbox. Do not buy extra Google accounts for printed strings.
- Does this require a new mailbox?
- No. MailerZ is Mail Box portal webmail (Inbox, Sent, New email). It is not IMAP or POP. Gmail or Outlook remains the store unless you separately buy a hosted mailbox product.
- Will it work with Gmail or Outlook?
- Yes for inbound when the destination is a verified mailbox. Branded replies need paid send-as plus Gmail Send mail as or a manual Outlook SMTP identity. Free has no send-as.
- What DNS records are involved?
- A verification TXT, one MailerZ MX set on the authoritative nameservers, leftover host MX removed, and SPF, DKIM, and DMARC if you also send as the domain.
- What should I test before production?
- Send a uniquely titled message from an unrelated provider into each named alias. Confirm Header From and delivery history. Do not email yourself from the same Gmail account.
Key takeaways
- Roles are aliases, not seats.
- Free fits three names.
- Probe each name.
- One MX set.
- Send-as per From.
- Hold unknowns.
- Remap when people leave.
- No extra Gmail required.
Conclusion and next action
Print support@, sales@, and billing@ as named aliases into Gmail you already have. Cut leftover MX. Probe each name. Pay only for the Froms that must travel.
Start free on one domain. Sign in if the three names exist and the lookup still shows Google.
Three roles, one inbox
Start free, create the three names, prove each from another mailbox.
Do not buy Gmail accounts to print role addresses.
Review quarterly, or sooner if Gmail, Workspace, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.