Email alias vs plus addressing: which is better?

Quick answer for email alias vs plus addressing

Plus addressing is a mailbox convention. You keep one login, then append a plus and a tag: you+shop@gmail.com still lands in you@gmail.com if that provider implements subaddressing. Google documents the Gmail behavior as an address alias; see Google Gmail Help — Using an address alias (plus addressing). The protocol name for the idea is subaddressing. IETF RFC 5233 — Sieve Email Filtering: Subaddress Extension describes how a filter language can split a local-part on a separator, usually +, and treat the detail as extra data. That RFC does not require every mail system to do it.

An email alias is a different local-part. hello@yourdomain.com is not a tag on you@gmail.com. It is a recipient the domain’s MX must accept, then route. The destination can be Gmail, Outlook, or another mailbox you already use. The public name can stay when the person behind it changes. That is the job a custom domain alias exists to do.

Email alias vs plus addressing is therefore not a quality ranking. Plus is better when you only need disposable tags on a mailbox that already strips them. A named alias is better when the address is a brand, a role, or a domain identity. Mixing them is how people publish founder+press@brand.com, watch the message sit in a hold queue, and conclude forwarding is broken.

MailerZ sits on the named-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. 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. Confirm current numbers on MailerZ pricing.

If you need the durable routing model in product language, start with aliases and catch-all controls. Catch-all is a policy for unknown local-parts. It is not plus-address parsing. A plus tag on your domain is just another recipient string until you map it or decide what happens to unknown mail.

The user problem and the decision criteria

The usual mess starts in a consumer inbox. Someone learns that Gmail accepts name+newsletter@gmail.com, builds a filter, and feels organized. Then they buy a domain. They want hello@, billing@, and a private personal address. They paste plus tags onto the domain because that is the trick they know. Forms reject the plus. A vendor stores the tagged string as the account email. Support later cannot change it. Or the domain forwarder never accepted the tagged recipient at all.

The other mess is the reverse. A founder creates twenty named aliases for every experiment, burns the Free alias ceiling, and still uses plus tags in their head as if those aliases were infinite. Aliases are inventory. Plus tags on Gmail are not.

Decide with jobs you can test.

Plus addressing is a poor public identity. It leaks the base mailbox. Anyone who sees you+acme@gmail.com can guess you@gmail.com. It also ties the tag to one login. When a contractor leaves, you cannot retarget you+vendor@ without keeping that person’s mailbox alive.

A named alias is a poor disposable tracker if you treat every campaign as a new local-part and never retire routes. You will hit plan ceilings and create addresses you forget to monitor. Use aliases for durable roles. Use plus tags, where the mailbox supports them, for personal sorting. Use a real campaign platform if the job is list mail. MailerZ is not a newsletter engine.

Technical mail flow

Internet mail delivers to a recipient string, not to a vibe. IETF RFC 5321 — Simple Mail Transfer Protocol is the transport standard. The sending server looks up MX for the domain after @, connects, offers a return path in MAIL FROM, and names each recipient in RCPT TO. The local-part to the left of @ is opaque to SMTP. The receiving system decides whether that string is a mailbox, an alias, a subaddress, or unknown.

Plus addressing inside a mailbox product

On Gmail’s own domain, the product implements subaddressing. Mail to you+invoices@gmail.com is accepted as mail to you@gmail.com. The To: header can still show the tagged address, which is why filters work. Nothing in DNS changed. No forwarder ran. The mailbox vendor folded the detail away. Outlook.com and some other hosts have similar behavior on their own domains. That is a product feature, not a universal internet rule.

Subaddressing is optional. RFC 5233 tells a Sieve interpreter how to read a user and a detail when a separator is present. It does not tell MailerZ, Cloudflare, or a random VPS to strip +. If your MX answers on yourdomain.com, the recipient is the full local-part unless that software was written to parse tags.

Named alias on a custom domain

A customer sends to support@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. 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.

What happens to a plus tag on a MailerZ domain

If someone writes to hello+vip@yourdomain.com and you only created hello@yourdomain.com, MailerZ sees a different recipient. Free holds unknown mail. Paid catch-all forward, if you turned it on, can send that unknown local-part to a destination. That is not Gmail-style plus stripping. It is “accept everything else.” You will collect typo spam along with clever tags. Do not turn on catch-all because you wanted plus addressing and did not want to create two aliases.

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. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Plus addressing on Gmail does not give you a custom-domain From. Recipients still see Gmail unless you add a verified send-as identity. The send path is documented on send and reply as your domain.

Step-by-step setup and decision path

Do this in order. The failure that wastes the most time is publishing a plus-tagged domain address that no system accepts, then debugging Gmail filters that never saw the message.

1. Write the address people will see

   If the string belongs on a website, invoice, or App Store listing, it is a named alias or a hosted mailbox, not a plus tag. If the string exists only so you can filter newsletters inside Gmail, plus addressing on the Gmail account is enough and you can stop.

2. Check whether plus is even legal for that form

   Many banks, government portals, and SaaS signups reject + or treat it as a different person than the untagged address. If the address must survive a password-reset form, do not use plus addressing as the account email.

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 to plus tags on @gmail.com.

4. Create the named alias and destination

   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. Do not create hello+vip@ unless you truly want that exact local-part as a second alias. Free allows three aliases. Solo allows fifteen. Higher plans raise the ceiling.

5. Publish MX and delete leftover MX

   Copy the exact MX hosts and priorities from the dashboard. Then look at the public MX set. Old Google, Microsoft, or host records sitting beside MailerZ split inbound traffic. Treat leftover MX as a hard stop until those records are gone. Plus addressing will not save a split MX.

6. Prove inbound to the exact public string

   Send a uniquely titled message from an unrelated provider to hello@yourdomain.com, not to a Gmail plus tag. Open the destination. Confirm the visible sender is the original person. Open MailerZ delivery history. If you only tested you+test@gmail.com, you tested Gmail, not the domain.

7. Leave catch-all off until you have a reason

   Unknown recipients are held on Free. Paid plans can forward catch-all when you enable it. That is a policy for leftovers and typos, not a substitute for naming support@. If you enable it so plus tags on the domain “just work,” you also accept every guessed local-part.

8. Add send-as only for addresses you will reply from

   Free stops before outbound identity. When replies must leave as the alias, move to a paid plan, create the SMTP credential, and add that exact address in Gmail Send mail as or Outlook’s manual SMTP identity. A plus tag is not an approved From unless you created and verified it.

Failure modes and proof

Most “plus addressing does not work on my domain” reports are a category error. The mailbox trick never moved with the MX. Work the evidence.

Proof is a pair of artifacts: the destination copy or a sanitized header block, 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 alias, and a spam folder is not proof of a broken one.

If DNS looks wrong, use troubleshooting and DNS diagnostics. Those tools are DNS-only. They do not invent a plus-addressing score.

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.

An alias in this product is a durable routing rule. You name the public address, pick a destination inbox, and change that destination later without reprinting the address. That is the positioning in the roadmap row: durable aliases that route to existing inboxes. It is not a second Gmail account. It is not plus-address generation.

What MailerZ does in this workflow

• 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 you enable it.
• 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.
• Count aliases against the plan ceiling: 3 on Free, 15 on Solo, 50 on Starter, 200 on Business, 500 on Agency.

What MailerZ does not do

• Strip plus tags on your custom domain the way Gmail strips them on gmail.com.
• 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. 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.

Catch-all is not “unlimited plus addressing.” Multi-domain use is a plan-capacity question: Free is one domain. Solo is three domains. Starter, Business, and Agency raise domain and alias ceilings. If you need many role addresses without many mailbox seats, aliases are the fit. If every teammate needs a hosted mailbox and a calendar, buy a suite.

Cost, alternatives, and trade-offs

Plus addressing is free on Gmail because it is a feature of a mailbox you already pay for with attention, or with Workspace if you upgraded. It costs nothing extra and gives you nothing extra on a domain you do not host there.

Named aliases cost inventory on a delivery layer or seats on a suite. MailerZ Free is the right first purchase when you only need to prove three role addresses inbound. It is the wrong plan if you need send-as or more than three aliases. Solo exists for one person who needs fifteen aliases, 90-day store, optional catch-all forward, 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.

Cloudflare Email Routing and other inbound routers can also map named addresses. They do not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because this article mentioned them. Read their docs if that is the stack you run. ImprovMX is the closest commercial forwarding class; compare current plans on the live sites rather than memory.

FAQ

Key takeaways

• Email alias vs plus addressing is a recipient-string decision, not a quality ranking.
• Plus addressing works when the mailbox vendor implements subaddressing on that vendor’s domain.
• A named alias is a public local-part the domain MX must accept and route.
• MailerZ does not strip plus tags on your custom domain.
• Unknown plus-tagged recipients on Free are held, same as any unknown local-part.
• Catch-all forward is not a plus-addressing feature.
• Role addresses belong on named aliases so you can move the destination later.
• Free has three aliases and no send-as. Paid plans raise both.
• Test the exact printed address from a different mailbox. Gmail plus tests do not prove domain aliases.

Conclusion and next action

If you came here for email alias vs plus addressing, the useful answer is narrow. Keep plus tags inside the mailbox that documents them. Put brand and role strings on named aliases. Do not expect a forwarder to treat + as Gmail does. Do not burn alias inventory on tags you could have filtered locally. Do not turn on catch-all to fake unlimited plus addressing unless you also want unknown mail.

MailerZ fits when you want durable aliases that route to Gmail or Outlook, with Header From left alone and a recovery window you can inspect. It does not fit when you need a hosted mailbox for every user, certified compliance reports, or campaign-scale sending. Start on Free if three aliases and inbound proof are the whole job. Move to Solo or another paid plan when you need more aliases, catch-all forward, or send-as from those addresses.

Next action: write the one address you will print. If it is a Gmail plus tag, create the filter and stop. If it is a domain role, add one domain, create that 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 provider plus-addressing behavior, MailerZ alias limits, or DNS guidance changes. Author: MailerZ editorial, Secuno LLC.