MailerZ vs Tuta: forwarding control plane or encrypted mailbox?

A mailbox provider and a forwarding layer solve different jobs.

A full mailbox service receives, stores, indexes and displays mail. It may include calendars, contacts, mobile and desktop clients, search, offline access, spam controls, organizational administration and encryption features. Moving to that product changes where historical and future messages live, how users sign in, and which apps they use every day.

MailerZ does not attempt to become that system of record. It receives mail for addresses on your domain and forwards it to a mailbox provider you already use. That can avoid a data migration and preserve familiar client workflows, but the privacy, storage, search and collaboration characteristics of the destination remain in force. Forwarding cannot turn an ordinary destination inbox into an end-to-end encrypted mailbox.

Cost comparisons must therefore include the missing pieces. A per-user mailbox price may look higher, yet it can include storage, calendars and administration the team otherwise buys separately. A forwarding plan may look lower because it intentionally leaves those capabilities at the destination provider. Compare the complete stack required for the same outcome.

The deciding question is usually simple: do users want a new mailbox? If yes, evaluate the mailbox provider on its own terms. If no, and the objective is to attach domain identities to existing inboxes with a controlled reply path, MailerZ belongs on the shortlist.

Compare capabilities in the context that changes the decision.

Checks and crosses often hide the most important nuance. The table uses plain-language behavior and a verification note so you can translate each row into a real test.

Turn each plan into the same six-number worksheet.

A fair price comparison begins by normalizing what is counted. MailerZ publishes domains, aliases, seats, storage window, monthly outgoing mail and hourly send-as. Tuta (formerly Tutanota) may count messages, bandwidth, aliases, mailboxes, users or destinations differently. Write the required capacity beside each metric, then select the first tier that clears every requirement with headroom.

MailerZ currently offers Free; Solo at $40 per year; Starter at $8 monthly or $80 yearly; Business at $19 monthly or $190 yearly; Agency at $39 monthly or $390 yearly; and Unlimited at $99 monthly or $990 yearly. Free is one domain, three aliases, a 14-day store, send-as disabled, and SMTP/API disabled. Unrouted mail on Free is hold or reject only. Solo is three domains. Paid tiers from Solo through Agency use a 90-day store; Unlimited uses 180 days. Solo is annual-only. Pricing can change, so the product checkout remains the final source of truth.

The lowest subscription price is not automatically the lowest total cost. Include mailbox fees, migration time, support effort, API or automation work, staff onboarding and the expected cost of a missed high-value message. Conversely, do not buy enterprise features only because they look impressive in a grid. Unused complexity becomes configuration risk.

Choose the product that matches the daily job.

A useful pilot uses real shapes without real risk: one low-consequence domain, two aliases, two destinations, one external sender and one reply. Repeat the experiment with a message containing an attachment and another from a service known to enforce strict authentication. Record the visible From, Reply-To, Authentication-Results and downstream response rather than judging only by whether a notification appeared.

One identity, two directions, four places to verify.

MX points incoming domain mail at MailerZ. The routing layer resolves the alias and destination, preserves Header From, and attempts the downstream delivery. Use the live DNS diagnostic and delivery history when investigating a real domain. Open the full product guide.

DNS can be correct while a message is still filtered.

MX records advertise where other servers should deliver mail for the domain. A wrong hostname, missing record, stale answer or competing priority can prevent mail from reaching the intended edge. Yet a perfect MX answer proves only routing. SPF, DKIM and DMARC evaluate sending and alignment; they do not make every forwarded message safe or desirable.

Forwarding can complicate SPF because the forwarder sends from infrastructure not listed by the original sender. Modern systems use mechanisms such as SRS, DKIM preservation and ARC to retain or communicate authentication context, but downstream providers apply their own policy. Reputation, content, user feedback and local rules continue to matter. Ask every provider how it handles forwarding authentication, then test with destinations that resemble production.

When a message does not arrive, work from evidence in order: confirm public MX; confirm the sending server connected; identify whether the forwarding edge accepted or rejected; inspect the destination server response; search spam, quarantine, tabs and rules; then verify the address map. Avoid changing multiple DNS records at once because it destroys the evidence needed to isolate the fault.

Ask which party can see which data at each hop.

Email forwarding necessarily processes message envelopes and content long enough to route and transmit them. TLS can protect transport between cooperating servers, while encryption at rest can protect stored operational data. Neither claim means ordinary Internet email is end-to-end encrypted. If only the correspondent and recipient may read content, use an end-to-end encrypted design and verify its key model directly.

The destination inbox remains a major boundary. Forwarding a message into Gmail, Outlook or another provider places the durable copy under that provider's storage, retention, scanning and account-security controls. MailerZ does not host the final mailbox. Review MailerZ's security and privacy pages together with the destination provider's policies and your contractual requirements.

Administrators should protect the domain registrar, DNS account, MailerZ account and destination mailbox with strong unique credentials and multi-factor authentication wherever available. Domain renewal is part of email security: if control lapses, an attacker may eventually receive mail intended for former addresses. Maintain more than one trusted recovery method and a written ownership record for business-critical domains.

Move the address map before you move the traffic.

The safest migration is boring: inventory, pre-create, test, cut over, observe and only then retire. Do not begin by deleting old records or closing the previous account. Preserve a configuration export and make one accountable person responsible for the rollback decision.

1. 01

   Decide whether to leave the mailbox

   Moving from Tuta to MailerZ means choosing a destination inbox provider. This is an architectural change, not a like-for-like toggle.

2. 02

   Plan historical mail

   MailerZ does not import or host old mailbox contents. Export or retain historical messages under Tuta's supported process before any subscription change.

3. 03

   Recreate identities

   Add the domain and create important aliases in MailerZ. Verify each destination and set outbound identities for addresses that send.

4. 04

   Change DNS and clients

   Update MX for inbound MailerZ routing, publish required authentication, then configure MailerZ SMTP in supported clients. These are separate steps.

5. 05

   Run parallel validation

   Keep Tuta accessible during the transition, test account recovery and confirm old messages remain available before cancellation.

After cutover, send from at least two unrelated providers to every high-value alias. Verify a reply from each outbound identity, inspect visible headers, and exercise account recovery for the services that would create the highest loss. Keep the previous service until traffic, DNS and operations are stable—not merely until the first test succeeds.

Reasons MailerZ may not be the right choice.

MailerZ also does not provide IMAP or POP mailbox hosting, calendar, contacts, bulk marketing delivery, guaranteed inbox placement or control over recipient-side spam rules. Its paid 90-day store is an operational window, not a permanent archive. The outgoing and hourly send-as limits shown on pricing are product boundaries, not targets to circumvent.

If Tuta (formerly Tutanota) is stronger for your primary use case, choose it. A comparison page earns trust by narrowing a decision, not by declaring one vendor universally superior. Re-evaluate when the team, domain portfolio, message volume, privacy requirements or client ecosystem changes.

Eight checks that prevent a cheap email decision from becoming an expensive incident.

Use this handbook after the feature comparison and before checkout. It is intentionally provider-neutral: the same evidence should be collected for MailerZ, Tuta (formerly Tutanota), and any additional finalist. A clear “no” from a product is more useful than an ambiguous “yes” that fails in production.

Use the 7-day refund window as an engineering evaluation.

New users are eligible under the published refund policy for a full refund within seven days, subject to that policy. Use the period to test the highest-risk behavior immediately rather than spending it on cosmetic setup.

A successful evaluation produces artifacts: a route inventory, DNS record set, test-message IDs, screenshots or copied status evidence, a plan-capacity worksheet, an administrator list and a rollback note. Those records remain useful even if you choose another provider.

Direct answers for buyers and technical reviewers.

How this comparison was researched.

We classified each product by its primary job, read first-party product, pricing, help and policy pages, and compared observable capabilities rather than marketing adjectives. MailerZ statements use the current published pricing and service-scope language. Competitor pricing and features can change after review; source links below are provided so readers and answer engines can verify the current state.

We do not claim that a vendor lacks a feature merely because a marketing page did not mention it. “Not found in the reviewed source” is different from “does not exist.” Likewise, vendor-authored security and privacy claims are descriptions to evaluate, not independent audit findings. For high-consequence procurement, request current contracts, data-processing terms, incident history and assurance reports directly.