An email alias and a forwarding address are not the same object. The alias is the public local-part people type: hello@yourdomain.com. The forwarding address is the mailbox that stores the copy, usually the Gmail or Outlook you already search. Mix the words and you will debug the wrong hop, leave leftover MX published, or expect a destination string to appear as the From on replies.
Quick answer for email alias vs forwarding address
Use an alias when you need a durable name on a domain you control. Use a forwarding address when you need to name the inbox that will actually hold the mail. In a MailerZ setup those are two fields on one route: the alias is accepted at MailerZ MX, then the message is forwarded to the destination you verified. Envelope MAIL FROM can use Sender Rewriting Scheme. Header From is never rewritten. Subject, Date, Message-ID, body, and MIME stay as received.
Hosting panels and ISPs reuse “forwarding address” for a different job: “this mailbox on our host should send a copy to that other mailbox.” That toggle still depends on the old host’s MX. It is not a custom-domain alias. If customers type hello@yourdomain.com and leftover MX still points at the ISP, some messages never reach MailerZ. Price does not merge two MX sets. IETF RFC 5321 — Simple Mail Transfer Protocol is still the transport: lookup, connect, envelope, content.
Privacy-alias products add a third meaning. They mint random local-parts to hide a personal inbox from forms. That is a useful pattern for shopping accounts. It is not the same as printing support@ on a invoice. A SimpleLogin-style writeup is research for that privacy pattern, not proof of MailerZ behavior; see SimpleLogin’s blog if that is the job you actually want.
MailerZ Free allows 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 with 15 aliases and paid send-as. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Confirm the live cards on MailerZ pricing. Limits are not an inbox-placement SLA.
The user problem and the decision criteria
The usual mess is vocabulary. A registrar sells “email forwarding.” A cPanel screen says “forwarding address.” Gmail has “Send mail as.” A founder says “I set up an alias” and means they typed their Gmail into a form on the domain host. A week later invoices go to hello@ and land nowhere, or land with a rewritten From that breaks replies. The words were never mapped to objects.
Decide with objects you can point at, not synonyms.
| Question | If yes | If no |
|---|---|---|
| Must strangers type a name on your domain? | You need an alias (or a suite mailbox on that domain). | Give them the Gmail and skip domain mail. |
| Do you already trust Gmail or Outlook as the archive? | That inbox is the forwarding address. Keep it. | You are shopping for a mailbox, not a route. |
| Is the old host still publishing MX? | Its “forwarding address” still intercepts some senders. | A clean MailerZ MX set can own inbound. |
| Must replies leave as the alias? | Paid send-as. An alias does not send by itself. Free has no send-as. | Inbound routing may be the whole job. |
| Are you hiding from forms with random strings? | A privacy-alias product may fit better than a role address. | Print named aliases you can support for years. |
The email alias vs forwarding address guide that helps is the one that refuses to collapse those rows. If you want named routes on a domain without buying seats, start at aliases and catch-all after you understand the inbound hop on custom-domain email forwarding.
Technical mail flow
A sender never “sends to a forwarding address” unless you printed that Gmail in public. They look up MX for the domain on the alias. If MailerZ MX is the 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 local-parts on Free are held. Paid plans can forward unknown recipients when you enable that behavior.
What the alias is
The alias is a public identity and a routing key. It is not a mailbox login. It does not create an IMAP folder. Free allows three. Solo allows fifteen. Higher plans raise the ceiling. If you print sixteen role addresses on Free, the sixteenth is not “almost an alias.” It is an address you did not create, which means hold or bounce depending on policy.
What the forwarding address is
The forwarding address is the destination mailbox MailerZ will try after storage. You verify it so a typo does not silently feed a stranger. Do not point it back at the same alias. Loops look like vanished mail. Gmail or Outlook then files the copy. Their spam tabs are still theirs. Delivery history can show a destination 250 while the user stares at an empty inbox.
What an ISP forwarding address is
If the registrar still hosts a mailbox named hello@ and that mailbox is set to “forward to you@gmail.com,” senders who hit the registrar MX never talk to MailerZ. You now have two forwarding addresses and one public name. That is leftover MX, not a feature. Treat leftover MX as a hard stop until the obsolete records are gone.
SPF, DKIM, and DMARC evaluate authorization on the visible From. 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 documents. A forwarder that rewrites Header From to its own domain is no longer delivering the author’s identity. MailerZ does not do that rewrite. Alignment still does not move a message into Primary.
People also collapse “forwarding address” with “plus addressing.” A plus tag is a filter on one mailbox, such as you+billing@gmail.com. It is not a name on your domain and it is not a MailerZ alias. If a form rejects plus signs, the tag never existed for that vendor. A named alias on your domain still works because the local-part is ordinary. That is a different article’s comparison. Keep it in mind so you do not “fix” an alias problem by adding a plus tag to the forwarding address.
Disposable inboxes are another false synonym. A burner address is built to die. An alias on your domain is built to stay on the invoice next year. If you recover a bank account with a disposable forwarding target, you will lose the recovery mail when the burner expires. MailerZ aliases are durable routes into a store you control. They are not throwaway identities.
Role addresses make the split obvious. billing@ is the alias you print. The finance lead’s Outlook is the forwarding address. When that person leaves, you change the destination, not the printed string. If you had given vendors the Outlook address, every form becomes a migration. That is the operational reason the two names exist. It is not decoration.
Catch-all is not a third kind of forwarding address. It is a policy for local-parts you did not create. Free holds those messages. Paid plans can forward them when you enable that behavior. Turning on catch-all FORWARD so you can avoid creating aliases is how harvested directories become your inbox. Name the aliases you print. Leave unknown held until you have a reason.
Step-by-step setup and decision path
Do this in order. The common email alias vs forwarding address setup failure is creating a destination first and never publishing MX, or publishing MX and never mapping the printed local-part.
Write both strings on one line
Example: “Public: hello@brand.com. Store: founder@gmail.com. No catch-all. No send-as yet.” If you cannot fill both blanks, you are not ready to change DNS.
Add one domain and verify it
Use the root domain, not a mailbox and not
https://. Publish the verification TXT MailerZ shows. Receiving stays off until that check passes.Create the alias and the forwarding address as separate fields
Map the local-part to the destination inbox. Complete destination verification if asked. Do not paste the alias into the destination field. That is the loop.
Publish MailerZ MX and delete leftover MX
Copy hosts and priorities from the dashboard. Read the public MX set from more than one resolver if you can. Disable the ISP mailbox forward after MailerZ owns MX, not before, if you still need a rollback window. Do not run both MX sets in production.
Prove inbound from a different mailbox
Send a uniquely titled message to the alias from an unrelated provider. Open the forwarding address. Confirm Header From is the original sender. Read MailerZ delivery history. Self-send from Gmail to the same Gmail account can short-circuit the path.
Add send-as only if the alias must appear on the way out
Upgrade off Free. Create the SMTP credential. Add Gmail Send mail as or Outlook’s manual SMTP identity. Send to a second external inbox. Unauthorized or unhosted recipients get SMTP 550. MailerZ is not an open relay.
Failure modes and proof
Most “my alias does not work” tickets are a forwarding address that was never verified, leftover MX that still feeds the ISP forward, a loop, or a send-as attempt on Free. Work the evidence.
| What you see | Likely cause | Proof to collect |
|---|---|---|
| Some senders reach the old host mailbox | Leftover MX. The ISP forwarding address still wins those lookups. | Public MX from two resolvers. Remove obsolete records after MailerZ MX is live. |
| Nothing arrives and history is empty | The alias was never created, or MX never pointed at MailerZ. | Dashboard alias list, public MX, the exact recipient string the sender used. |
| History shows accept, Gmail is empty | Wrong forwarding address, destination filter, or a loop that bounced later. | Verified destination, spam folder, remote SMTP response, loop check. |
| Visible From is a relay identity | A different forwarder rewrote Header From, or you are reading the ISP copy. | Raw headers on the destination copy. MailerZ should keep the original Header From. |
| Replies leave as @gmail.com | You configured an inbound alias only. Send-as was never added, or you are on Free. | Plan send-as flag. Gmail From selector. Outbound history. |
| Self-send never appears | Gmail short-circuited a message to itself. | Repeat from a different provider. Expected, not an outage. |
| Unknown local-parts sit in hold | Free HOLD, or paid catch-all not set to FORWARD. | Hold queue. Do not enable catch-all FORWARD just to hide a missing alias. |
| 550 on send | Unauthorized From, unhosted domain, or plan limit. | Exact SMTP response. Hourly send-as and monthly outgoing counters. |
Proof is a pair of artifacts: a sanitized header block at the forwarding address, and the MailerZ event with timestamp plus remote response. Do not send SMTP passwords to support. Do not publish verification tokens. MailerZ recovery storage is 14 days on Free and 90 days on paid plans. That store is evidence, not a second archive.
MailerZ workflow and product boundary
MailerZ is a custom-domain email delivery layer operated by Secuno LLC. Point MX at MailerZ. An alias on a hosted, verified domain can land in Gmail or Outlook. Paid plans add authenticated SMTP so that same alias can send and reply. The live site is mailerz.net. The app is mail.mailerz.net.
What MailerZ treats as an alias
- A named local-part you create on a verified domain.
- A route to one or more verified forwarding addresses, according to the dashboard mapping.
- A recipient check at the edge. Unknown strings follow hold or paid catch-all policy.
What MailerZ treats as a forwarding address
- The destination mailbox you verify.
- The place delivery history quotes when the hop completes.
- Not a public identity unless you foolishly print it.
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 live on Security and Trust Center.
- Act as an open relay. Unauthorized send gets 550 / 550 5.7.1.
Catch-all is a policy for leftovers, not a substitute for naming aliases you print. 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. Annual Starter, Business, and Agency billing includes two months free relative to paying monthly for a year. Solo has no monthly option.
Cost, alternatives, and trade-offs
An alias is cheap because it is not a seat. A hosted mailbox is expensive because it is a store, an admin model, and often a suite. The email alias vs forwarding address best practice is to pay for the object you actually need. If the store already exists in Gmail, do not rent another one to hold the same thread.
| Approach | You get | You give up |
|---|---|---|
| MailerZ alias to a Gmail forwarding address | Public domain name, existing archive, Header From intact, delivery history. | No hosted mailbox. Send-as only on paid plans. Published limits. |
| ISP mailbox plus “forwarding address” | A toggle you already know on the old host. | That host’s MX, their rewrite rules, and a second place mail can hide. |
| Suite mailbox named like an alias | Vendor login, admin, Calendar if you buy the bundle. | Per-user cost and a migration if you already live in consumer Gmail. |
| Privacy aliases with random local-parts | Form isolation. | A string you cannot print on an invoice or support SLA. |
Free is the right first purchase when you will print three aliases or fewer and only need inbound proof. It is the wrong plan if the acceptance test includes “reply as the alias.” Solo exists for one person who needs more aliases, a 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.
Count aliases before you count dollars. Fifteen role addresses on Solo is still one Gmail seat. Fifteen Workspace users is fifteen suite seats. That is the cost shape, not a claim about Google’s current list price. Google’s packaging lives on Google’s site and changes. Do not quote a Workspace number from this page. Quote MailerZ numbers from the pricing page the day you buy.
If you already run Cloudflare Email Routing, read their docs for their inbound model. It does not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because this article named it. ImprovMX is the closest commercial class for forwarding. Compare live plans, not memory. A best-practice email alias vs forwarding address setup is the one where you can recite both strings and the MX set before anyone prints a card.
Teams that announce the alias on Free and promise branded replies create a support queue they cannot close. Verify inbound on Free if you want the cheaper probe. Pay before the address is public if send-as is part of the acceptance test. That sequence is slower by a day and cheaper than an apology thread.
FAQ
What is the safest way to handle email alias vs forwarding address?
Print the alias as the public local-part on your domain. Point that alias at a verified forwarding address you already read, usually Gmail or Outlook. Publish one MX set, delete leftover host records, and prove inbound from a different mailbox. Do not treat an ISP “forward this mailbox” toggle as a domain alias.
Does this require a new mailbox?
No. An alias is a route, not a seat. MailerZ is not IMAP and not webmail. The forwarding address is the store you already use. Buy a suite if you need a hosted mailbox, Calendar, or Drive as the company system of record.
Will it work with Gmail or Outlook?
Yes for inbound when the forwarding address is a mailbox those products already provide. Replies that must leave as the alias 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, and the SPF, DKIM, and DMARC values shown in the dashboard when you send. Leftover Google, Microsoft, or registrar MX must be deleted at cutover. An ISP forwarding address on the old host still follows that host’s MX until you remove it.
What should I test before production?
Send a uniquely titled message from an unrelated mailbox to the alias. Confirm Header From and delivery history at the forwarding address. If you will send as the alias, upgrade first, then send outward to a second external inbox. Self-send from Gmail to the same Gmail account can hide routing errors.
Key takeaways
- An email alias is the public local-part on your domain. A forwarding address is the mailbox that stores the copy.
- ISP “forwarding address” is a host toggle. It still follows that host’s MX.
- MailerZ routes the alias, then forwards. Envelope SRS only. Header From stays the author.
- Leftover MX is a hard stop. Two MX sets mean two forwarding stories.
- Do not loop the destination back to the alias.
- Test inbound from a different mailbox. Self-send lies.
- An alias does not send. Paid SMTP does. Free has no send-as.
- Free: 1 domain, 3 aliases, 14-day store, unknown held. Paid: 90-day store and higher ceilings.
- MailerZ is not a mailbox host, not an open relay, and not SOC 2.
Conclusion and next action
If you came here for email alias vs forwarding address, stop using one phrase for both jobs. Name the string strangers will type. Name the inbox you will search. Put MX in one place. Prove the hop from a mailbox that is not the destination. Only then decide whether the alias must also appear on the way out.
MailerZ fits when those two strings are enough and you want delivery history you can read. 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 aliases. Move to Solo or another paid plan when the From identity has to travel.
Next action: add one domain, create one alias, verify one forwarding address, and send a uniquely titled message from somewhere else. When that lands, print the alias. The register path is one domain, not a suite migration.
Ready to map both strings
Start free with one domain and prove the alias.
Inbound on Free. Paid send-as when the public name has to leave as From. Sign in if the domain is already there.
Review quarterly, or sooner if MailerZ plan limits, provider behavior, or DNS guidance changes. Author: MailerZ editorial, Secuno LLC.