Email alias security: what it hides and what it does not

Quick answer for email alias privacy security

Use a custom-domain alias when the job is operational privacy: vendors, forms, and partners should write to hello@ or billing@, not to the Gmail string you actually read. That is email alias privacy security in the narrow sense. The correspondent never learns jane.founder@gmail.com unless you put that string in a signature or a reply header they can see.

Do not use a MailerZ alias as a privacy-mask product. MailerZ sees the envelope, the destination map, and delivery history. The destination mailbox still stores the body. A court, a workplace admin, or a leaked SMTP credential is outside this article’s comfort story. If you need per-signup random masks on a provider domain, that is a different category. Cite their docs, not this page.

A role address is stronger than a plus tag when the printed string must survive a staff change. plus addressing lives on a mailbox that already implements subaddressing. A custom-domain alias is a name you own. You can remap support@ without reprinting the website. You cannot pretend the old plus tag is a separate legal person.

Inbound still needs one MX set. Leftover Google, Microsoft, Cloudflare routing, or registrar MX splits mail. Prove inbound from a mailbox that is not the destination. Self-send lies. Then decide whether anyone must send as that alias. Free cannot finish send-as.

MailerZ Free is one domain, ten 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. Limits are not an inbox-placement promise.

custom domain alias: the real decision

Founders ask for “secure aliases” and mean four different jobs. One person wants vendors off their personal Gmail string. One wants a role that can move between contractors. One wants to look untraceable. One wants to stop a leaked address without rebuilding the company domain. Only the first two are MailerZ jobs. The third is a threat-model problem a forwarding layer cannot close. The fourth is operational hygiene: retire the alias, keep the domain.

The dangerous mix is publishing a personal name on the domain, forwarding it to a personal inbox, then answering as that personal Gmail address. The alias hid nothing after the first reply. Email alias privacy security fails at the From line, not at MX.

Another failure is catch-all forward sold as security. Accepting every guessed local-part increases the surface. Harvested names become working hops into the same inbox. Holding unknown recipients is the safer default on Free. Paid catch-all forward is a watched window, not a shield.

Decide with tests, not adjectives. Can you list the public names? Can you remap a destination without reprinting? Can you retire one name without killing the domain? If a reply must show the domain, you also need paid SMTP and a client identity. If you need Calendar, Drive admin, and a hosted login per person, you are shopping for a suite.

Technical mail flow for email alias privacy security

A sender looks up MX for the domain, offers an envelope recipient such as billing@yourdomain, and transfers content. Your receiving layer accepts a named alias, holds or rejects unknowns, and forwards a copy to a verified destination. The person at Gmail or Outlook reads the same body. Header From on inbound stays the original author so DKIM and DMARC still describe that author, not a rewritten mask.

SRS rewrites the envelope return path so bounces can travel back through a forwarder without breaking SPF at the next hop. That is not encryption. That is not anonymity. It is bounce hygiene. If you rewrite Header From instead, authentication breaks and spam folders fill for reasons that look like “the alias failed.”

Outbound is a second hop. Authenticated SMTP proves a credential may send as an approved identity. Unauthorized or unhosted send is 550. Gmail Send mail as and a manual Outlook SMTP identity are client features. They do not appear because you created an inbound alias.

DNS still decides the first hop. If two MX sets remain, some senders will use the leftover host. The alias map on MailerZ never sees that copy. Privacy conversations that ignore leftover MX are unfinished.

Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol. Envelope commands are not the header block people see. MailerZ may rewrite only the envelope return path with Sender Rewriting Scheme. MailerZ is a product of Secuno LLC. It is inbound MX plus authenticated SMTP. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. It is not Google Workspace, not IMAP, and not an open relay. Unhosted or unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Probe from another mailbox. MailerZ is not SOC 2, not ISO 27001, and not HIPAA.

email forwarding alias: step-by-step setup

Treat setup as a list you can fail in public. Do not enable a dozen aliases on day one. Do not keep registrar forwarding beside MailerZ MX. Do not paste a Google password into a random SMTP form.

1. Write the threat in one sentence: hide the Gmail string, keep a role portable, or retire a leak. If the sentence is “be anonymous,” stop and pick a different product class.
2. Add and verify one domain. Publish the verification TXT the dashboard shows. Do not invent records from a blog screenshot.
3. Create only the named aliases you will print. Map each to a destination mailbox you already read. Three names fit Free.
4. Publish one MailerZ MX set. Delete leftover suite, routing, and registrar MX. Wait for the cut you can see in a public lookup.
5. Send a uniquely titled message from an unrelated provider into each alias. Confirm Header From and delivery history. Do not trust a self-send.
6. Decide send-as separately. If replies must show the domain, pay Solo or another published plan, create the SMTP credential, and attach Gmail Send mail as or Outlook SMTP. Free has no send-as.
7. Document who owns each role address. A role without an owner becomes a leak you cannot retire cleanly.
8. Schedule a quarterly review: unused aliases, leftover MX, and any destination that left the company.

Client clicks for Gmail live in Google Gmail Help — Send mail from a different address. Outlook uses a manual SMTP identity when you also send as the domain. Incoming mail stays at the destination mailbox.

Failure modes and proof

The first failure is leftover MX. You created aliases, sent a test from your own Gmail, and declared victory. External senders still hit Google or the old host. The alias never ran. Proof is a public MX view plus a probe from a second provider.

The second failure is a reply that reveals the destination. Gmail sends as the Gmail identity unless you paid for send-as and selected the domain From. The correspondent now has both strings. The alias did not fail. The From did.

The third failure is treating catch-all as security. Unknown forward collects guessed names. Hold unknowns. Promote a leftover string to a named alias only when a real customer used it.

The fourth failure is sharing one SMTP password across a form, a laptop, and a contractor. Rotate. MailerZ is not an open relay. A leaked credential still sends as identities you approved until you revoke it.

The fifth failure is asking support to “make us anonymous.” We will not invent SOC 2, encryption, or a legal veil. Collect delivery history, the probe Message-ID, and the MX set. That is the useful ticket.

MailerZ workflow and product boundary

MailerZ fits durable aliases that route to existing inboxes. You add a domain, map names, cut leftover MX, and read mail in Gmail or Outlook. Delivery history and a recovery window exist so a failed hop is not a ghost story. Free holds unknown recipients. Paid plans can forward unknowns when you enable that behavior.

MailerZ does not fit a privacy-alias browser extension, an encrypted mailbox, or a disposable inbox that should die on Friday. It does not host IMAP. It does not promise inbox placement. It does not store a second copy as a compliance archive. Fourteen days on Free and ninety days on paid are recovery windows, not legal hold.

If you already use SimpleLogin-style masks for shopping, keep that tool for shopping. Use MailerZ for the domain customers will still write next year. Mixing those jobs on one MX set creates a mess you will blame on “security.”

Related pages: aliases and catch-all, email alias service guide, custom-domain email alias. Those routes exist on this site. Do not invent a second MX religion beside them.

role address

The cheap path is Free: three durable names, inbound only, unknown held. That is enough to stop printing a personal Gmail on a homepage. Solo at $40 per year adds send-as when the role must reply as the domain. Starter, Business, and Agency raise alias, seat, and send ceilings. Confirm /pricing.

A suite seat per person is the expensive alternative when you only needed a role route. A privacy-mask subscription is the wrong alternative when the printed address must be yours. Registrar forwarding is the fragile alternative that hides leftover MX until a customer disappears.

Do not buy Agency to feel secure. Buy the plan that matches named aliases and send-as volume you can measure. Security here is a short public list, one MX set, and a From you control — not a higher invoice.

MailerZ Free is one domain, ten 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. Limits are not an inbox-placement promise. Time is part of cost. An afternoon on leftover MX usually costs more than Solo.

Agencies should give each client domain its own named list. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases, not so you can stop naming things.

Personal domains follow the same split. A plus tag on Gmail is not a custom-domain alias. If you own two personal domains, map hello@ on each. Do not reuse one leaked name across both and call it compartmentalization.

Field notes you can reuse

Worked example: vendor leak without changing Gmail

A founder printed jane@brand.com on a SaaS trial. The vendor leaked a spreadsheet. The instinct is to change the Gmail password and the company domain. The useful move is smaller. Pause jane@ on MailerZ. Create procurement@ or a dated local-part. Update the vendor. Leave the inbox and MX alone if those are healthy. That is email alias privacy security as an operational control: the leaked string dies, the store stays.

If the founder had been answering as jane.personal@gmail.com, the leak already included the destination. Retiring the alias still stops new vendor mail from arriving on the old string. It does not unsay the Gmail address. Paid send-as would have kept replies on the domain. Free would not. Do not claim the alias hid what the From revealed.

WHOIS, invoices, and Stripe receipts still carry a legal name. An alias never promised to erase those. Security questionnaires that ask “do you offer anonymous email?” get a no. MailerZ routes. It does not mint a second legal person. Point at the security page for the real control list. Do not invent SOC 2 to make the questionnaire shorter.

What to tell a client who wants “encrypted aliases”

Encryption in transit is TLS on the hops you control. Encryption at rest is a property of Gmail or Outlook, not of a forwarder recovery window. End-to-end encryption is a mailbox product such as a locked store the recipient decrypts. MailerZ sees envelope and destination maps because it must forward. Saying “encrypted alias” in a proposal is how you inherit a threat model you cannot meet.

If the client needs masked per-site addresses on a provider domain, send them to a privacy-alias product and cite that product’s docs. If they need hello@ on a domain they own, keep MailerZ. Mixing both jobs on one MX set creates leftover routing and a support week. Custom domain alias and email forwarding alias are the same receiving idea with different words. Role address is the durable print. Privacy mask is the other aisle.

Contractors should not keep personal plus tags on the company domain. Plus addressing is a mailbox feature. It is not a MailerZ local-part. If you print sales+secret@yourdomain, you need that full string as an alias or you need hold to catch it as unknown. Do not assume Gmail-style stripping.

Evidence that belongs in the ticket

Collect the public MX set, the alias map screenshot, the probe Message-ID, the visible Header From, and whether send-as is even on the plan. Do not collect passwords. Do not ask the customer to forward a secret. If leftover MX is present, stop talking about privacy until the cut exists. The alias cannot hide a mailbox that Google still accepted on a leftover host.

Fourteen days on Free and ninety days on paid are recovery windows for hops this layer saw. They are not legal hold. If counsel wants an archive, buy an archive. If counsel wants a DPA, use the published legal pages. This article stays in routing.

Quarterly, list every printed local-part. Kill names that no longer appear on the site. Remap destinations for people who left. That review is more security than a higher plan. Agency capacity helps you hold more names. It does not think for you.

Operator brief

A longer operator brief for email alias privacy security

Teams that bookmark Email Alias Security: What It Hides and What It Does Not usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about email alias privacy security as a send-as, catch-all, or comparison problem.

MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is Mail Box portal webmail, not IMAP, not POP, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.

If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening email alias privacy security. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.

Catch-all forward is not a safety feature for email alias security what it hides and what it does not. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.

Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.

Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear email alias privacy security works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.

Agencies should keep email alias privacy security per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.

Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.

Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.

When Email Alias Security: What It Hides and What It Does Not is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how email alias privacy security stays a runbook instead of an incident.

A second worked pass for email alias privacy security: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a email alias privacy security mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.

A third worked pass: print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.

FAQ

What is the safest way to handle email alias privacy security?

Print named aliases you can retire, map them to a mailbox you already read, cut leftover MX, and prove inbound from another mailbox. Do not enable catch-all forward as a shield. Do not treat MailerZ as anonymity or encryption.

Does this require a new mailbox?

No. MailerZ is Mail Box portal webmail (Inbox, Sent, New email). It is not IMAP or POP. Gmail or Outlook remains the store. An alias is a route, not a hosted login.

Will it work with Gmail or Outlook?

Yes for inbound when the destination is a verified mailbox. Branded replies 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, leftover host MX removal, and SPF, DKIM, and DMARC if you also send as the domain. Two MX sets split mail.

What should I test before production?

Send a uniquely titled message from an unrelated provider into each alias. Confirm Header From and delivery history. If you will reply as the domain, upgrade first and send outward to a second external inbox.

Key takeaways

• An alias hides the destination string from a correspondent who only knows the alias.
• It does not hide the body from the destination inbox or the forwarder.
• Replies reveal the From you actually used. Free has no send-as.
• Catch-all forward is not a security control.
• Leftover MX is a hard stop. Prove inbound from another mailbox.
• MailerZ is a delivery layer, not an anonymity product and not SOC 2.
• Retire a leaked local-part. Keep the domain.
• Three named aliases on Free are enough to stop printing a personal Gmail.

Conclusion and next action

If you came here for email alias privacy security, write the threat first. Hide a mailbox string, keep a role portable, or retire a leak. Those are forwarding jobs. Anonymity, encryption, and certified compliance are not. MailerZ can own MX and named routes around the inbox you already use. It will not invent a second identity law.

Next action: list the three names you will print, add one domain, delete leftover MX, and probe from a mailbox that is not the destination. Pay only when the From must travel. Sign in if the domain is already there.

Review the list when a contractor leaves or a vendor leaks a name. The durable part is the domain. The disposable part should be the local-part you can kill without a press release.

Review quarterly, or sooner if provider behavior, pricing, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.