MailerZ vs Google Workspace: forwarding + SMTP or full office suite?

Quick answer for MailerZ vs Google Workspace

Choose Google Workspace when the company needs hosted mailboxes, admin, Calendar, Drive, and a vendor identity for every seat. Google describes that product as a suite; see Google Workspace — product overview for their current packaging. That page is marketing. It is not a MailerZ price list and it is not proof that you need the suite to own a domain From line.

Choose MailerZ when the job is a public domain identity and an inbox you already trust. A customer writes to hello@yourdomain.com. MailerZ accepts on MX, keeps the visible From, and forwards into Gmail or Outlook. Paid plans add authenticated SMTP so replies can leave as the same domain. MailerZ is not Workspace, not IMAP, and not an open relay. Envelope MAIL FROM can use Sender Rewriting Scheme. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten.

The safest MailerZ vs Google Workspace setup is exclusive. Name the store. Publish only that stack’s MX. Delete leftover records from the other stack. Prove inbound from a mailbox that is not the destination. Only then decide how replies leave. Running Workspace MX beside MailerZ MX is leftover MX. Leftover MX is a hard stop. Senders split. Mail looks randomly lost.

MailerZ is operated by Secuno LLC. 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. 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. Those are plan limits, not an inbox-placement promise and not a Workspace invoice.

If you want the shorter product comparison page, use MailerZ versus Google Workspace. This article is the decision path: when the suite is the purchase, when a delivery layer is enough, and how to cut over without splitting MX.

The user problem and the decision criteria

The usual complaint is cost dressed up as email. A founder lives in consumer Gmail. Customers expect @brand.com. A host or registrar offered “email” that rewrites From. Someone quoted Workspace per user for Calendar nobody asked for. The founder wants the domain identity without renting an office suite to store a backpack.

The opposite complaint is also real. A five-person team needs shared drives, admin offboarding, and calendar as the system of record. They bought a cheap forwarder, kept personal Gmail, and now nobody can find last quarter’s mail when a contractor leaves. That team does not have a forwarding problem. They have a store problem.

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

MailerZ vs Google Workspace is a poor comparison if you pretend they sell the same object. Workspace sells a suite. MailerZ sells inbound MX plus optional paid send-as around an inbox you already operate. If you need both a suite and a second forwarder, you have designed a loop. Do not do that.

Shared mailboxes are a Workspace-shaped job. If three people must search the same legal inbox with retention the vendor holds, a forward into one founder’s Gmail is the wrong store. MailerZ can route legal@ to that founder. It cannot give you Workspace-style delegated admin, eDiscovery, or a mailbox you revoke without also owning the destination account. Say that out loud before you pick the cheaper invoice.

Offboarding is the other tell. On MailerZ you change the alias destination or disable the route. The public address stays. The departed person’s Gmail is no longer in the path if you actually changed it. On Workspace you suspend a seat and the mail stays in Google’s store. If your risk is “contractor still has last year’s threads in their personal Gmail,” forwarding did not create that risk and Workspace does not automatically remove copies that already forwarded. Pick the store that matches the retention story you tell customers.

Technical mail flow

Internet mail is a sequence of SMTP conversations. IETF RFC 5321 — Simple Mail Transfer Protocol is the transport standard. A sending server looks up MX, connects, offers a return path in MAIL FROM, names recipients in RCPT TO, and transfers content. Who answers MX owns first acceptance. That is the fork between MailerZ and Workspace.

MailerZ inbound

A customer sends to hello@yourdomain.com. Their server asks DNS for MX. 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.

MailerZ stores required content and metadata before it returns SMTP 250. Acceptance is not “Gmail already has it.” After storage, MailerZ forwards to the destination you verified. The visible From stays the original sender. The envelope return path may be rewritten with SRS. Delivery history records the destination response. Gmail can still file the message in spam. That is Gmail’s decision. MailerZ recovery storage is 14 days on Free and 90 days on paid plans. It is not a Workspace archive and not a compliance vault.

Workspace inbound

Workspace answers MX at Google. The message is stored in a Google mailbox. Users log into that store with a Workspace identity. There is no MailerZ hop and no SRS rewrite because Google is not forwarding into consumer Gmail as the product. If you still have registrar or MailerZ MX beside Google MX, you do not have Workspace inbound. You have split delivery.

Outbound identities

On MailerZ, sending as the domain is authenticated SMTP on a paid plan. You add MailerZ as Gmail’s outgoing server or Outlook’s manual SMTP identity. MailerZ authenticates the session, checks the From identity, applies plan limits, and submits the message. Unhosted or unauthorized recipients get SMTP 550. MailerZ is not an open relay. SPF, DKIM, and DMARC are published from the dashboard. They do not “make mail inbox.” 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 protocol texts.

On Workspace, sending is the suite’s own SMTP or web client. Recipients see the Workspace address because Google hosts it. You do not paste MailerZ SMTP into Workspace to “add forwarding.” That mixes two stores.

Authentication records follow the sender. If MailerZ sends, publish the SPF, DKIM, and DMARC values MailerZ shows for that domain. If Workspace sends, publish Google’s. Mixing includes from both stacks because you “might switch later” is how receivers see a policy that authorizes everyone and explains nothing. DMARC alignment still depends on the visible From domain matching what those records authorize. Neither vendor can promise the Primary tab.

Self-send is a special Gmail behavior, not a MailerZ defect. Gmail can short-circuit a message from an account to itself and skip the public MX path you think you are testing. The same trap exists when you send from a Workspace user to that same user’s alias that forwards back into Google. Probe from a mailbox on another provider. Title the message uniquely so you can find it in history and in the destination.

Step-by-step setup and decision path

Do this in order. The expensive failure is buying Workspace, leaving old MX in place, then adding MailerZ because send-as “felt incomplete.”

1. Write the job in one sentence

   If the sentence is “we need Calendar, Drive, and admin-managed mailboxes,” stop and buy the suite. If the sentence is “customers write to our domain and we live in Gmail,” continue with MailerZ.

2. Name the store

   Consumer Gmail, Outlook.com, or a hosted Workspace mailbox. MailerZ is never the store. If you cannot name the archive, you are not ready to cut MX.

3. If the store is Gmail, add one domain to MailerZ

   Use the root domain, not a mailbox and not https://. Publish the verification TXT. Receiving stays off until that check passes.

4. Create the alias and destination

   Map hello@ or a role address to the inbox that should receive it. Complete destination verification. Do not point a destination back at the same alias.

5. Publish one MX set and delete leftovers

   Copy MailerZ MX exactly. Remove Google, Microsoft, or host MX that still answers. If you chose Workspace instead, publish Google’s MX and do not leave MailerZ MX in the zone. Treat leftover MX as a hard stop. Use DNS diagnostics if the public set looks mixed.

6. Prove inbound from a different mailbox

   Send a uniquely titled message from an unrelated provider. Confirm Header From. Read delivery history. Self-send from the same Gmail account can short-circuit and hide routing errors.

7. Upgrade only when you need send-as

   Free stops here. When replies must leave as the domain, move to Solo or another paid plan, create the SMTP credential, and add Gmail Send mail as. Field clicks live in the Gmail send-as guide.

8. Send to a second external inbox

   Check the visible From. Check that a reply returns to the alias. Check MailerZ history. Inbox placement on the far side is still their filter.

Failure modes and proof

Most “MailerZ vs Google Workspace is broken” reports are leftover MX, a Free plan used for send-as, or a self-send test. Work the evidence.

Proof is a pair of artifacts: a destination copy or sanitized headers, and the MailerZ event with timestamp plus remote response. Do not send SMTP passwords to support. Do not publish verification tokens. Inbox placement is not proof of a correct setup.

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. Positioning for this row: a focused forwarding plus SMTP layer around the inbox you already use.

What MailerZ does in this comparison

• Accept inbound mail for verified domains and configured aliases.
• Preserve Header From on the forward into Gmail or Outlook.
• Hold unknown recipients on Free; allow paid catch-all forward when enabled.
• 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.

What MailerZ does not do

• Replace Workspace with IMAP, webmail, Calendar, or Drive.
• 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. Those certifications are not held. Controls live on Security and Trust Center.
• Act as an open relay. Unauthorized send gets 550 / 550 5.7.1.
• Send newsletters or purchased lists.

The send-and-reply surface is send and reply as your domain. Inbound routing is custom-domain email forwarding. Migrations are a DNS cutover plus a two-direction test, not an IMAP export from Workspace.

Alias inventory is finite. Free allows three aliases. Solo allows fifteen. Starter allows fifty. Business allows two hundred. Agency allows five hundred. Workspace aliases live inside Google’s admin and do not consume MailerZ counts because they are a different product. Do not expect MailerZ catch-all to replace a Workspace grouping strategy. Catch-all on paid MailerZ forwards unknown local-parts when you enable it. That collects typos and harvested guesses. Holding unknown mail on Free is the safer default.

Seats on MailerZ are operators of the delivery layer, not mailbox licenses. Free and Solo are one seat. Starter is five. Business is twenty-five. Agency is fifty. If you need fifty people to read mail in their own hosted inbox, that is Workspace math, not Agency math. Agency is for more domains, more aliases, and higher send ceilings around inboxes those people already have.

Cost, alternatives, and trade-offs

Workspace pricing is a per-user suite cost. Google’s current packaging lives on their site and changes. Do not treat this article as Google’s price list. The comparison that matters is economic shape: you pay per hosted user for a suite, or you pay a delivery layer while Gmail remains the seat you already have.

MailerZ Free is the right first purchase when you only need to prove inbound. 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. Starter, Business, and Agency raise domains, seats, aliases, and send ceilings. Annual Starter, Business, and Agency billing includes two months free relative to paying monthly for a year. Solo has no monthly option.

Microsoft 365 is the other suite. The same store rule applies. ImprovMX is a closer commercial class for forwarding; compare live plans rather than memory. Cloudflare Email Routing is inbound routing. It does not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because a comparison article mentioned it.

Paid MailerZ send-as is metered. Solo is 5 messages per hour and 100 outgoing per month. Starter is 10 per hour and 200 per month. Business is 15 and 400. Agency is 25 and 800. Those numbers are capacity, not reputation. If your “office suite” need is actually a burst of invoices at month-end, count the burst against the hourly cap before you decline Workspace. If your need is twenty people in shared drives, the hourly cap is the wrong spreadsheet.

A Workspace trial that still has Google MX published will steal MailerZ inbound until those records are gone. A MailerZ test domain that still lists Google MX will steal Workspace inbound the same way. Cutover is deletion plus cache, not a dashboard toggle labeled “make it professional.” Query more than one resolver. Keep a rollback MX plan until the external inbound test passes twice.

FAQ

Key takeaways

• MailerZ vs Google Workspace is a store decision: delivery layer versus hosted suite.
• MailerZ keeps Gmail or Outlook as the mailbox. It is not IMAP.
• Workspace is the right buy when you need Calendar, Drive, and admin-managed seats.
• Publish one MX set. Leftover MX is a hard stop.
• Header From stays the original sender on MailerZ inbound. Envelope SRS is the rewrite that is allowed.
• Free has no send-as. Add a paid plan before Gmail SMTP will have a legal identity to use.
• Test inbound from a different mailbox. Self-send lies.
• Plan limits are not an inbox-placement SLA. MailerZ is not SOC 2.
• Do not run MailerZ MX and Workspace MX on the same domain.

Conclusion and next action

If you came here for MailerZ vs Google Workspace, the useful answer is narrow. Buy the suite when the suite is the job. Buy a forwarding plus SMTP layer when Gmail is already the store and you only need the domain identity. Do not stitch both MX sets together. Do not expect MailerZ to become Calendar. Do not expect Workspace to become a cheap forwarder with leftover registrar MX still published.

MailerZ fits when you want that split with delivery history and a recovery window you can inspect. It does not fit when every teammate needs a hosted mailbox, 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 leave as your domain.

Next action: write the one-sentence job. If it is the suite, stop here and buy Workspace. If it is domain identity on Gmail, add one domain, create one alias, and send a uniquely titled message from a mailbox that is not the destination. The MailerZ documentation has the field maps. The register path is one domain.

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