Mailbox seat vs email alias cost: a 10-person team example

Quick answer for email alias vs mailbox cost

For a ten-person team that already lives in Gmail or Outlook, the cheapest durable pattern is usually ten existing inboxes plus named aliases for hello@, support@, billing@, and jobs@. You do not buy a mailbox for each role. You map a custom domain alias to the people who should see that mail. When someone leaves support, you change the destination. You do not migrate a seat.

Buy mailbox seats when the store is the product. If legal wants a vendor archive, if IT refuses consumer Gmail, or if people need Calendar, Drive, and admin in one suite, that is a per-user purchase. Google’s current packaging lives on the Google Workspace — product overview page and changes. Do not treat this article as Google’s price list. Treat it as a shape: seats scale with humans who need a hosted store. Aliases scale with printed strings.

MailerZ seats are not mailbox licenses. They are operator seats on a delivery layer run by Secuno LLC. One admin can run a domain that routes to ten Gmail accounts. Ten MailerZ logins are only required if ten people must operate the dashboard. Read the seat column on MailerZ pricing as capacity for operators, not as a tax on every human who receives a copy.

Free is one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. That is enough to prove inbound for a first role address. It is not enough for four public roles plus send-as. Solo is $40 per year only: one domain, fifteen aliases, one seat, a 90-day store, 100 outgoing per month, 5 send-as per hour. Starter is $8 monthly or $80 yearly: five domains, fifty aliases, five seats, 200 outgoing, 10 send-as per hour. Business is $19 or $190: twenty-five domains, two hundred aliases, twenty-five seats, 400 outgoing, 15 per hour. Agency is $39 or $390: one hundred domains, five hundred aliases, fifty seats, 800 outgoing, 25 per hour. Confirm those numbers on the pricing page before you quote them. They are plan limits, not an inbox-placement promise.

A worked ten-person year, if one operator runs MailerZ Business annual and the team keeps consumer Gmail as the store, is $190 for the delivery layer plus whatever those people already pay for Gmail. The suite alternative is ten hosted seats at whatever Google or Microsoft charges that month, plus extra seats if someone sold you a mailbox per role. The gap is the habit of treating every public name as a store.

MailerZ is not Google Workspace, not IMAP, and not an open relay. Envelope MAIL FROM can use SRS. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. If you need the routing model in product language, start with aliases and catch-all controls.

The user problem and the decision criteria

The quote that starts the argument looks reasonable. Ten people. A domain. Role addresses. A reseller multiplies seats by every string on the website. Finance approves it because “email” and “seats” are already a paired word in the spreadsheet. Six months later, three role mailboxes are unread, two people still send as @gmail.com, and leftover MX from a trial still splits inbound.

This example is invented for arithmetic. It is not a named customer. Ten people, one primary domain, four printed roles, Gmail already on every laptop. Variants change the answer. A regulated archive requirement changes it. A founder who is the only reader changes it again.

Compare the suite path in product language on MailerZ vs Google Workspace. That page is a category split, not a coupon. Workspace wins when the suite is the workplace. MailerZ wins when the workplace is already Gmail and the domain is a delivery job.

Agencies add a second multiplier: client domains. Ten people and twenty domains is an Agency-shaped ceiling on MailerZ, still without twenty hosted mailboxes per client. Do not use this ten-person example as a client-portfolio model without recounting domains and aliases.

Technical mail flow

Cost follows the hop you actually run. IETF RFC 5321 — Simple Mail Transfer Protocol delivers to a recipient string. MX selects the receiver. An alias accepts RCPT TO and copies the message to destinations. A mailbox accepts RCPT TO and stores it. Ten people can sit on either side of that copy.

Inbound aliases into ten Gmail accounts

A customer writes to support@yourdomain.com. MailerZ MX accepts the message if the domain is verified and the alias exists. The route can target one destination or several, depending on how you configured it. Header From stays the customer. Envelope return path may use SRS. Each destination Gmail account is a store you already operate. Delivery history records the destination response. Gmail can still file the copy as spam. That is not a refund event.

Inbound to ten suite mailboxes

If MX points at Google or Microsoft, each accepted local-part is a mailbox that vendor stores. Role addresses become seats or shared mailboxes inside the suite. You now pay for those stores. You also inherit leftover-MX risk if you later add a forwarder without deleting the suite MX. Split records lose mail in a pattern that looks random.

Outbound identities

Receiving is not sending. Free has no send-as. Paid SMTP is capped per hour and per month. Ten people all sending as support@ through one identity will share those caps. Starter’s 200 outgoing per month is a team constraint, not a personal one. Business’s 400 and Agency’s 800 raise the ceiling. If the team needs campaign volume, use a campaign platform. MailerZ is not that platform. The send path is documented on send and reply as your domain. Gmail’s client labels are in Google Gmail Help — Send mail from a different address.

Authentication records belong to the sending domain. 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 specs. Publish the dashboard values. A suite path publishes the suite’s values instead. Mixing both outbound stacks without a From selector is how half the team still leaves as @gmail.com while you pay for a domain identity nobody uses.

Step-by-step setup and decision path

Do the arithmetic before DNS. The expensive failure is buying fourteen seats, then forwarding them into Gmail anyway.

1. Write the ten humans and the four printed roles

   Humans need stores. Roles need routes unless a role is actually a person with a private archive. If jobs@ is a shared intake, it is an alias. If a recruiter must search a private corpus with legal hold, that recruiter needs a mailbox.

2. Name the store you will keep

   Consumer Gmail, Outlook.com, or a suite you already pay for. If you are about to buy the suite for Calendar and Drive, count those seats honestly and stop pretending aliases replace the workplace. If you are only buying the suite because of email branding, keep going.

3. Count MailerZ operators, aliases, domains, and send volume

   One domain and four aliases fit Solo’s fifteen-alias ceiling. Five people who must administer the dashboard do not fit Solo’s one seat; they need Starter or Business. Ten administrators need Business’s twenty-five seats. Outbound replies from a busy support alias can exhaust Solo’s 100 outgoing per month. Estimate before you print the address.

4. Add the domain and verify

   Root domain, unique verification TXT, receiving off until the check passes. Create the four aliases and destinations. Complete destination verification. Do not loop a destination back to the same alias.

5. Publish one MX set and delete leftover records

   Leftover Google or host MX is a hard stop. Public lookup from two resolvers. Then probe each alias from an unrelated mailbox. Self-send lies.

6. Attach send-as only for identities that must travel

   Upgrade off Free. Copy SMTP values. Connect Gmail or Outlook. Send outward to a second external inbox. Not every role needs outbound. jobs@ can be inbound-only in year one.

7. Re-read the plan after the first busy week

   Alias count, hold queue, outgoing counter, and who actually logged into the dashboard. Promote the plan for a ceiling you hit. Do not promote it because headcount is ten. Ten receivers who never open MailerZ are still one operator and a list of destinations.

Mid-setup DNS reads belong on troubleshooting and DNS diagnostics. Those tools do not invent a cost score. They will tell you if leftover MX is still published. That record can waste a year of aliases by delivering half the mail to a dead suite trial.

Failure modes and proof

Cost failures show up as unused seats and as silent mail. Proof for routing is delivery history plus a sanitized destination view. Proof for spend is a seat list that names a human or an operator, not a role.

Do not send SMTP passwords to support. MailerZ does not claim SOC 2, ISO 27001, HIPAA, review counts, or an uptime SLA. Controls wording lives on Security and Trust Center.

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.

The conversion angle for this page is narrow: avoid buying full mailbox seats for addresses that only need routing. Product appears after the count. MailerZ does not become cheaper than a suite that you need for documents and calendar. It becomes cheaper than a suite you bought only to print support@.

What MailerZ does in this workflow

• Accept inbound mail for verified domains and configured recipients.
• Preserve Header From on the forward into existing inboxes.
• 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.
• Cap domains, aliases, seats, store window, and send volume by plan.

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.
• Act as an open relay. Unauthorized send gets 550 / 550 5.7.1.
• Send newsletters, purchased lists, or cold blasts.

Catch-all is a policy. Ten people plus catch-all forward will collect guessed local-parts. Hold-unknown on Free, and on paid until you choose otherwise, is the safer default while you learn volume.

Cost, alternatives, and trade-offs

Work the example with current public numbers, then replace the suite line with the vendor’s live page. MailerZ annual cards, if still accurate when you read this: Solo $40, Starter $80, Business $190, Agency $390. Monthly Starter, Business, and Agency are $8, $19, and $39. Annual billing includes two months free relative to paying monthly for a year. Solo has no monthly option. Free is $0 with the limits already listed.

Cloudflare Email Routing is inbound routing. It does not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because a cost article mentioned it. ImprovMX is the closest commercial forwarding class; compare live plans. Registrar “email forwarding” toggles are often thin redirects.

Hidden costs sit outside the sticker. Training people to pick a From identity. Watching hold queues. Raising a plan when send-as/hour is the real bottleneck. Buying Business because someone assumed ten humans needed ten MailerZ seats. The last one is the same category error this article exists to stop, pointed at the other vendor.

If volume is unknown, start Free, prove inbound, then pick Solo or Starter from measured outgoing counts. Do not start Agency because the slide said “team.” Agency is for domain and alias ceilings you can name.

A second worked variant: ten people, two brands, eight role addresses, one operator. Solo cannot hold two domains. Starter can: five domains, fifty aliases, five seats. Annual Starter is $80 if those outgoing and send-as/hour numbers hold. The suite variant is still ten human seats if you also host mail there, or twenty if someone sold a mailbox per brand name. The alias layer does not double because a second brand exists. The domain ceiling does.

A third variant: ten people who must all administer aliases for clients. That is a seat problem on MailerZ. Business annual at $190 includes twenty-five seats. Agency annual at $390 includes fifty. Those dollars still do not buy IMAP. Each client’s recipients still land in Gmail or Outlook. If a client demands a hosted mailbox, that client’s suite bill is separate and honest.

Do not annualize a blog estimate into a board deck without opening the live pricing pages. Vendors change packs. MailerZ numbers in this article match the published cards at the time of writing. If they diverge, the pricing route wins. Limits remain limits. They are not a deliverability contract.

FAQ

Key takeaways

• Email alias vs mailbox cost is a unit problem. Stores and printed strings are different units.
• A ten-person example is arithmetic, not a case study and not a review count.
• Keep existing Gmail or Outlook stores when they are good enough. Map role aliases in front.
• Buy suite seats when you need the hosted store or the suite, not when you need a public name.
• MailerZ seats are operators. Confirm ceilings on the pricing page.
• Free has three aliases and no send-as. Solo, Starter, Business, and Agency raise different knobs.
• Outgoing caps are shared. Ten people can empty a monthly counter together.
• Leftover MX is a hard stop. Split records waste the money you just spent.
• Header From stays. Envelope SRS is the allowed rewrite. No inbox SLA.
• MailerZ is not SOC 2, not IMAP, and not a bulk sender. Quote those boundaries in the same sentence as the price.

Conclusion and next action

If you came here for email alias vs mailbox cost, print two lists: humans who need a store, and strings the public will type. Buy seats for the first list only when the store is new. Route the second list. A ten-person team that already lives in Gmail usually overpays when every role becomes a mailbox.

MailerZ fits when you want that routing split with delivery history and a recovery window you can 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 aliases, seats, store days, or send-as require it.

Next action: add one domain, create one role alias, and send a uniquely titled message from a mailbox that is not the destination. Then count real outgoing and real operators before you pick an annual card. The MailerZ documentation has the field maps.

Review quarterly, or sooner if MailerZ plan limits, suite packaging, or DNS guidance changes. Author: MailerZ editorial, Secuno LLC.