Email alias vs mailbox: the difference that saves money

Quick answer for email alias vs mailbox

An email alias is a routing rule. support@yourdomain.com is a recipient the domain’s MX must accept. After acceptance, a forwarder sends a copy to Gmail, Outlook, or another mailbox you already use. Nobody logs into the alias. There is no IMAP password for support@. The destination inbox is the store. That is why email alias vs mailbox is not a quality ranking. It is two different objects that happen to share an address shape.

A mailbox is a stored inbox. Someone authenticates, reads, searches, and archives there. Google Workspace, Microsoft 365, and consumer Gmail are mailbox products. They may also provide calendars, admin, and file storage. You pay per seat because the vendor holds the corpus. If you need that store, buy it. If you only need a public domain identity, a mailbox seat for every role address is the expensive habit.

Internet mail delivers to a recipient string, not to a product category. IETF RFC 5321 — Simple Mail Transfer Protocol is the transport standard. The sending server looks up MX, offers a return path in MAIL FROM, and names each recipient in RCPT TO. The receiving system decides whether that local-part is a mailbox, an alias, or unknown. SMTP does not care which retail name you bought.

MailerZ sits on the alias side. It is a delivery layer operated by Secuno LLC: inbound MX plus authenticated SMTP on paid plans. Envelope MAIL FROM can use Sender Rewriting Scheme. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. MailerZ is not Google Workspace, not IMAP, and not an open relay. Unhosted or unauthorized recipients get SMTP 550 / 550 5.7.1.

Free includes one domain, three 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: one domain, fifteen aliases, one seat, a 90-day store, 100 outgoing per month, and 5 send-as messages per hour. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Confirm current numbers on MailerZ pricing. Those figures are plan limits, not an inbox-placement promise.

If the job is durable role addresses that route to existing inboxes, start with aliases and catch-all controls. Catch-all is a policy for unknown local-parts. It is not a mailbox. It is not a reason to skip mapping the addresses you actually publish.

The user problem and the decision criteria

The usual bill starts with a reasonable request. A founder wants hello@, billing@, and a personal name on the domain. A hoster or a suite quote arrives as three mailbox seats. Calendar and Drive come along for the ride. The team still lives in consumer Gmail. Mail now has two homes, or the founder pays for seats nobody opens.

The other mess is the reverse. Someone creates twenty aliases for every experiment, treats each as if it were a private vault, and then wonders why there is no search, no shared label, and no audit trail inside the alias itself. Aliases do not store a second archive. They point at one. If you needed a second archive, you needed a mailbox.

Decide with jobs you can test, not with adjectives like “professional” or “real email.”

Role addresses are the cleanest alias win. jobs@, billing@, press@, and support@ are public contracts. People change. The printed string should not. A mailbox seat per role turns staff turnover into a DNS and password event. An alias turns it into a destination edit.

A custom domain alias is also the right object when two brands share one operator. Agencies and product studios often hold several domains and one working inbox. Buying a hosted mailbox for every brand local-part multiplies seats without multiplying readers. The custom-domain email alias guide is the longer product-language version of that split.

Mailboxes win when the destination is the product. Legal hold, shared team inboxes with vendor admin, device IMAP, or a company that refuses consumer Gmail as the store: those are seat problems. Do not force aliases to imitate a records system they are not.

An email forwarding alias is still an alias. The word “forwarding” describes the hop, not a second product. People search both phrases because hosts sell “email forwarding” as a registrar toggle and “mailbox” as a control-panel account. The registrar toggle is often a thin redirect with no leftover-MX stop, no stored failed hop, and no send-as. Treat it as a different operational class even when the public address looks the same.

Shared-mailbox products sit in the middle. Microsoft and Google both sell group inboxes that several people open. That is still a store. It is useful when the team must search one corpus together. It is wasteful when three people only need a copy of support@ in the inboxes they already live in. Route first. Promote to a shared mailbox only after the search-and-assign job shows up in real work.

Technical mail flow

Senders treat aliases and mailboxes the same. They write to an address. Their server asks DNS for MX. They deliver. Only the receiving system decides whether that local-part is a stored account or a route.

Inbound to an alias

A customer sends to hello@yourdomain.com. If MailerZ MX is the published answer, the message arrives at MailerZ. The edge checks that the domain is verified and that the recipient matches an alias, a route, or an intentional catch-all rule. Unknown addresses on Free are held. Paid plans can forward unknown recipients when you enable that behavior. Holding unknown mail is the safer default.

After acceptance, MailerZ forwards to the destination you verified. The visible From stays the original sender. The envelope return path may be rewritten with SRS so bounce handling does not impersonate that sender. Delivery history records the destination response. Gmail can still file the message in spam or a filter. That is Gmail’s decision, not proof that the alias failed.

Inbound to a mailbox

If the domain’s MX points at Google, Microsoft, or another host, the suite accepts RCPT TO as a mailbox it stores. There is no second hop into consumer Gmail unless you configured forwarding inside that suite. You now have a vendor archive. You also have leftover-MX risk if you later add a forwarder without deleting the old records. Split MX looks random to the founder and deterministic to the sending servers.

Plus addressing is not this question

Plus tags such as you+shop@gmail.com stay inside one mailbox that implements subaddressing. IETF RFC 5233 — Sieve Email Filtering: Subaddress Extension describes how a filter language can split a local-part. Google documents Gmail’s behavior as an address alias; see Google Gmail Help — Using an address alias (plus addressing). That is a mailbox feature on the vendor’s own domain. It is not a custom-domain alias, and it does not create a new seat. If you are choosing plus tags versus named aliases, that is a different article.

Sending is a third object

Receiving an alias is not the same as sending as that alias. Free has no send-as. Paid plans add authenticated SMTP within published hourly and monthly limits. Recipients should see the domain address, not a MailerZ mailbox, because MailerZ is not hosting a mailbox. The send path is documented on send and reply as your domain. A hosted mailbox sends through the suite’s own SMTP. Mixing both outbound identities without a From selector is how replies still leave as @gmail.com.

Authentication records belong to the sender domain. SPF, DKIM, and DMARC are published so receivers can evaluate the bounce domain and the signed identity. 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 specifications. A forwarder that rewrites Header From breaks that alignment. MailerZ does not rewrite Header From. Envelope SRS is the rewrite that is allowed.

Step-by-step setup and decision path

Do this in order. The failure that wastes the most money is buying seats for role addresses that only needed routes. The failure that wastes the most time is publishing an alias while leftover suite MX is still live.

1. Write every public address you will print

   Website, invoices, App Store, job posts, and support macros. If the string is a role or a brand, it is an alias candidate. If the string is a person who needs a private store, calendar, and device sync, it is a mailbox candidate.

2. Name the store you already trust

   If the team already lives in Gmail or Outlook and will keep living there, do not invent a second IMAP home for the same readers. If legal or IT requires a vendor mailbox, stop the alias path for those users and buy seats.

3. Add one domain you control

   Use the root domain, not a mailbox and not https://. MailerZ gives a unique verification TXT. Publish it on the authoritative nameservers. Verify in the dashboard. Receiving stays off until that check passes. This step does not apply if you chose a hosted mailbox and will use that vendor’s MX instead.

4. Create the named aliases and destinations

   Map hello@, billing@, or another role address to the inbox that should receive it. Complete destination verification if asked. Do not point a destination back at the same alias. Free allows three aliases. Solo allows fifteen. Starter allows fifty. Business allows two hundred. Agency allows five hundred. Treat those ceilings as inventory, not as a dare.

5. Publish one MX set and delete leftover records

   Leftover Google, Microsoft, or registrar MX is a hard stop. Senders split. The pattern looks random. Remove obsolete records only after the intended set is live. Use a public lookup from two resolvers, not only the registrar panel.

6. Prove inbound from a different mailbox

   Send a uniquely titled message from an unrelated provider. Confirm arrival, Header From, and delivery history. Gmail self-send can short-circuit. That is expected, not an outage.

7. Add send-as only if the public From must travel

   Free cannot finish outbound identity. Upgrade, copy the SMTP values from the dashboard, and attach Gmail Send mail as or a manual Outlook SMTP identity. Then send outward to a second external inbox. See Google Gmail Help — Send mail from a different address for Gmail’s own labels.

Mid-setup diagnostics belong on troubleshooting and DNS diagnostics. Those tools read public DNS. They do not grab SMTP banners or invent a health score.

Failure modes and proof

Most alias-versus-mailbox failures are category errors. People buy the wrong object, then debug the right object. Proof is a pair of artifacts: a destination inbox view you sanitized, and a delivery event with timestamp plus remote response.

Inbox placement is not proof of a correct setup, and a spam folder is not proof of a broken one. MailerZ can record “delivered” when the destination SMTP server said yes. Gmail can still hide the copy. Those statements can both be true.

Do not send SMTP passwords to support. Do not publish verification tokens. If you open a body for break-glass recovery, expect an audit row. That is a control, not a marketing badge. MailerZ does not claim SOC 2, ISO 27001, or HIPAA.

MailerZ workflow and product boundary

MailerZ is a custom-domain email delivery layer operated by Secuno LLC. Point MX at MailerZ. Mail for a hosted, verified domain can land in Gmail or Outlook. Paid plans add authenticated SMTP so the same domain can send and reply. The live site is mailerz.net. The app is mail.mailerz.net.

Aliases are addresses and routes, not extra Gmail accounts. The learning-center version of that sentence lives on the email alias service guide. This article is the money split: do not buy a mailbox for a route.

What MailerZ does in this workflow

• Accept inbound mail for verified domains and configured recipients.
• Preserve Header From on the forward into Gmail or Outlook.
• Hold or forward unknown recipients according to plan and settings.
• Store messages for 14 days on Free or 90 days on paid plans for recovery and evidence.
• Send through authenticated SMTP from approved identities on paid plans.
• Record delivery history for inbound and outbound hops.
• Surface leftover MX and other DNS problems as diagnostics, not as a guaranteed health score.

What MailerZ does not do

• Replace Gmail or Outlook with IMAP or webmail.
• Rewrite header From, Subject, Date, Message-ID, body, or MIME.
• Offer send-as on Free.
• Promise inbox placement, uptime SLAs, or review counts.
• Claim SOC 2, ISO 27001, or HIPAA. Controls and wording live on Security and Trust Center.
• Act as an open relay. Unauthorized send gets 550 / 550 5.7.1.
• Send newsletters, purchased lists, or cold blasts. Use a dedicated campaign platform.

Catch-all is a policy, not a feature to turn on because it sounds complete. Multi-domain use is a plan-capacity question: Free is one domain. Solo is three domains; Starter, Business, and Agency raise the domain and alias ceilings. Migrations are a DNS cutover plus a two-direction test, not an IMAP export.

Cost, alternatives, and trade-offs

The money difference is shape, not a spreadsheet of every vendor on the internet. A mailbox suite charges per stored user. An alias layer charges for domains, routes, store window, and send limits while the inbox you already have remains the seat. Google’s current packaging lives on the Google Workspace — product overview page and changes. Do not treat a blog number as Google’s price list.

A ten-person company that needs hello@, support@, billing@, and personal names does not automatically need thirteen seats. It may need ten human stores and three aliases, or one shared Gmail and a handful of routes. The later cost article in this roadmap works a team example. This page is the object lesson: count stores, then count printed strings.

MailerZ Free is the right first purchase when you only need to prove inbound aliases. It is the wrong plan if the acceptance test includes “recipient sees my domain on the reply.” Solo exists for one person who needs more aliases, 90-day store, catch-all forwarding, and 5 send-as messages per hour with 100 outgoing per month. Annual Starter, Business, and Agency billing includes two months free relative to paying monthly for a year. Solo has no monthly option.

Cloudflare Email Routing is inbound routing. It does not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because a blog post mentioned it. ImprovMX is the closest commercial class for forwarding; compare current plans on the site rather than memory.

FAQ

Key takeaways

• Email alias vs mailbox is a store decision. An alias is a route. A mailbox is an archive with a login.
• Buy seats for people who need a hosted store. Create aliases for printed role and brand addresses.
• MailerZ is not IMAP. Gmail or Outlook remains the mailbox.
• Header From stays the original sender on inbound. Envelope SRS is the rewrite that is allowed.
• Leftover MX is a hard stop. Split records lose mail in a pattern that looks random.
• Test inbound from a different mailbox. Self-send lies.
• Free has no send-as. Add a paid plan before the domain From can leave the building.
• Catch-all is a policy for unknown local-parts, not a substitute for mapping public aliases.
• Delivery history is evidence. Inbox tabs are the destination provider’s.
• MailerZ is not SOC 2 and not a bulk sender. Quote those boundaries out loud.

Conclusion and next action

If you came here for email alias vs mailbox, the cheaper mistake to avoid is paying for stores you will never open. Keep the inbox you already use when it is good enough. Put durable public names in front of it. Buy mailbox seats when the store itself is the product. Do not run both MX sets while you decide.

MailerZ fits when you want that alias split with delivery history and a recovery window you can actually see. It does not fit when you need a hosted mailbox for every user, a certified compliance report, or campaign-scale sending. Start on Free if you only need to watch inbound. Move to Solo or another paid plan when the From identity has to travel as your domain.

Next action: add one domain, create one role alias, and send a uniquely titled message from a mailbox that is not the destination. When that lands, decide whether send-as is in scope. The MailerZ documentation has the field maps. The register path is one domain, not a suite migration.

Review quarterly, or sooner if MailerZ plan limits, provider MX behavior, or DNS guidance changes. Author: MailerZ editorial, Secuno LLC.