Custom domain alias privacy is containment, not anonymity. Unique local parts stop a shop leak from naming every other shop. The registrable domain still ties those strings together for anyone who looks. WHOIS, certificate logs, MX, and your public site all point at the same operator. MailerZ will route and disable aliases. It will not make shop-west@yourdomain unlinkable from hello@yourdomain. If you need unlinkable, you need a different namespace, not a prettier prefix. Read this page as a kill-switch manual and a list of public join keys, then decide whether one domain is still the job.
A stranger with a resolver, a certificate log, and your website already has the join. Unique prefixes still earn their keep when a shop dump names one vendor. Hold both facts without turning either into stealth marketing. Confirm pricing if you need more aliases than Free allows. Confirm leftover MX is gone if you want the hop to match the story you tell.
Quick answer for custom domain alias privacy
Unique aliases give you a disable button per vendor. They do not give you unlinkability. Anyone who sees two addresses on yourdomain can join them.
If unlinkability is the job, use a mask or a separate domain you are willing to treat as a separate person. That has legal and operational cost.
If containment is the job, MailerZ named aliases plus HOLD unknown is enough. Say that sentence and stop.
DNS reality: IETF RFC 1035 — Domain names. Mail: IETF RFC 5321 — Simple Mail Transfer Protocol. Product: aliases, security.
User problem and decision criteria
People want the convenience of one domain and the mythology of many identities. Those wants fight.
Decision criteria: who are you hiding from, what they can already see, whether a leak should name one vendor, and whether you will operate a second zone.
A casual shop dump reader sees one string. Unique aliases win that fight.
A determined researcher sees the domain, the website, and the MX. Unique aliases lose that fight. They were never entered in it.
A destination provider sees many aliases arriving in one Gmail. If that provider is the adversary, you already lost.
If the adversary is a leaky merchant, stay on one domain and isolate. If the adversary is the public internet joining your hobbies to your company, split namespaces.
Where correlation lives
Local part: shop-west versus hello. Unique local parts stop a dump from listing every vendor in one row. Good.
Domain part: yourdomain. This is the join key you published on the site. Inescapable on a single zone.
MX: resolvers tell the world which hop you use. That is operationally required and publicly readable.
Certificates: if the site is on the same name, CT logs exist. Email and web join for free.
Payment: registrar and MailerZ invoices join identities even when DNS is clever.
Behavior: you reply From founder@ to a vendor who only knew shop-west@. You just drew the line yourself.
Step-by-step reduction (not removal)
- Write the honest sentence: containment yes, anonymity no.
- Put company and junk on different namespaces if that sentence is not enough.
- Use unguessable local parts for login aliases.
- HOLD unknown. Guessing is a correlation attack with extra steps.
- Do not publish the alias list on a status page.
- Do not CC personal Gmail together with a 'private' alias.
- Lock WHOIS privacy at the registrar if you are eligible. It hides some fields, not the domain.
- Separate payment if you are doing a real second identity. Most people should not.
- Disable leaks. That is the privacy you actually bought.
- Re-read this page when someone asks for a stealth guarantee.
Failure modes and proof
Marketing your aliases as anonymous. A journalist will resolve MX in four seconds.
A catch-all FORWARD that confirms every guess exists.
A second subdomain with the same WHOIS and the same card. Theater.
Using MailerZ send-as From a 'private' alias to a person who knows founder@.
Putting the alias map in a public Notion.
Proof of honesty: you can disable one string, and you can show a stranger the same MX on every alias. Both facts together.
MailerZ workflow and product boundary
MailerZ positioning for this cluster is durable routing over disposable anonymity. This article is that sentence at length.
We do not mint unlinkable identities. We do not hide MX. We do not claim SOC 2.
HOLD, disable, exclusive MX, intact Header From, paid send-as. Those are the knobs.
Free three aliases. Paid more. Confirm /pricing. Limits are not a privacy feature except as a brake on sloppy maps.
If you need a mask, use a mask. Do not file a support ticket asking MailerZ to become Apple.
If you need legal anonymity, talk to counsel. A blog will not do that job.
Cost and alternatives
One domain plus MailerZ is cheap containment.
N domains plus N hops is expensive unlinkability you will mis-operate.
Hide My Email moves correlation to Apple. Different adversary.
A suite mailbox aliases internally and still correlates at the seat.
Tor and anonymous remmailers are another class. Do not mix them into a company invoice path.
The cheapest honesty is one domain and a clean disable story.
Public records people forget
Registrar privacy hides some contact fields. It does not hide that the name exists or who the NS speak for.
Certificate logs list names you requested. A surprise subdomain is not a surprise.
Git commits, app store listings, and Stripe descriptors join harder than MX.
Agency retainers that reuse one MailerZ workspace across clients create a metadata join. Split workspaces if that matters.
Historic website copies keep old addresses. Disabling the alias does not unpublish the footer from 2022.
Custom domain alias privacy that ignores these records is a prefix hobby.
An honest privacy sentence
Say: we use unique aliases so a leak names a vendor, not every vendor. We do not claim to be unlinkable on this domain.
That sentence is good enough for a founder, an agency retainer, and a security questionnaire that is not asking you to lie.
If a questionnaire asks for anonymity, the answer is no. Fill no. Do not poetically redefine the word.
If a friend asks whether MailerZ hides them from their employer, the answer is no. The employer can see the domain if they see the mail.
If you cannot say the sentence, buy a different tool or accept a different risk.
Correlation risk explained is just that sentence plus the public records. You can stop when it is boring. Boring is the goal.
Worked scenarios for correlation
A researcher lists every address on yourdomain found in public dumps. Unique prefixes tell them which vendors you used. The domain told them it was you. Custom domain alias privacy did its small job and failed the large one. That is expected.
You split junk onto a second domain you paid with the same card and the same WHOIS. A payment trail joins them. You bought DNS work, not unlinkability.
You reply From founder@ to a vendor who only knew shop-west@. You drew the line in a header. No MX setting can undraw it.
An agency puts twenty clients in one MailerZ workspace. A support export could join them. Split workspaces if that join matters.
Certificate logs show app.yourdomain. The email aliases on yourdomain now sit next to the product. That is normal for a company and fatal for a stealth hobby.
HOLD is off. A stranger guesses prefixes and learns which exist by the 250 versus 550. Existence is correlation. HOLD exists partly for this.
You tell a journalist you are anonymous because you use aliases. They run an MX lookup on the live call. Do not do this.
Practice and anti-patterns about unlinkability
Practice: the honest sentence. Anti-pattern: stealth in the privacy policy.
Practice: unguessable login prefixes. Anti-pattern: paypal@.
Practice: HOLD unknown. Anti-pattern: existence oracles.
Practice: do not CC personal Gmail with a 'private' alias. Anti-pattern: convenience headers.
Practice: WHOIS privacy if eligible. Anti-pattern: thinking it hides the domain.
Practice: a real second identity only if you will operate it. Anti-pattern: a subdomain hobby.
Correlation risk explained is mostly what you refuse to claim.
Operator closeout for an honest map
Write the sentence on the alias map: containment yes, anonymity no.
List public join keys you already published: site, MX, certs, app stores, Stripe descriptors.
Confirm HOLD. Confirm disable still works on a lab alias.
Confirm you did not promise unlinkability in a customer FAQ.
If you run two domains, write why, and write which payment and WHOIS they share. If they share both, write 'theater.'
If an agency, write whether workspaces are split.
Revisit after any press, any new cert, and any new footer. Public records grow.
Edge cases people call privacy
Plus addressing: still one mailbox identity. Forms strip it. Not unlinkable.
Subaddressing on a suite: the suite vendor still sees all. Different adversary.
A disposable provider with a shared domain: you blend into a crowd and you cannot send-as a brand. Different product.
VPN plus aliases: the VPN hides an IP, not a From domain.
Encrypted body plus a public From: confidentiality of content is not unlinkability of identity.
Staff who reuse founder@ in their bios. Your MX hygiene cannot save a LinkedIn field.
A court order to the destination inbox. Aliases will not help. Counsel will.
Field notes from claims that died in public DNS
The fastest way to lose a privacy argument is to say anonymous while MX is public. Custom domain alias privacy dies on a live lookup. Say containment. Stay seated.
Payment trails join 'clever' second domains. If the same card and WHOIS paid both, you bought theater. Write theater on the map so the next operator does not add a third.
Reply-From is how people correlate themselves. founder@ answering a 'private' alias is a header you wrote. No hop setting undoes it.
Agency workspaces that mix clients create a metadata join. Split them if that sentence matters to the retainer.
Certificate logs and footers from 2022 outlive a disable. Privacy that ignores history is a prefix hobby.
HOLD off is an existence oracle. Strangers learn which prefixes 250. That is correlation with extra steps.
Questionnaires that ask for anonymity get no. Do not poetically redefine the word to keep a deal. The deal will die in review.
The honest sentence is the field note. Repeat it until it is boring.
Handoff memo for the honest map
The sentence: containment yes, anonymity no. The public join keys: site, MX, certs, app stores, Stripe. The HOLD policy. The last disable test.
Whether two domains exist and what they share in payment and WHOIS.
Whether workspaces are split for clients.
What you refused to promise in FAQs and questionnaires.
When to reread this page: new cert, new footer, new press, new staff bio.
Acceptance criteria for honesty
You can disable one alias. A stranger can see the same MX on every alias. You have said both facts out loud.
No stealth claim in policy, sales, or support macros.
HOLD on. Unguessable login prefixes on high-risk items.
No personal Gmail CC beside a private alias in living threads.
If unlinkability was the real job, you bought a mask or a real second identity, not a prettier prefix.
Operations review of public join keys
Once a quarter, resolve your own MX from a guest network and read it as a stranger. Custom domain alias privacy that cannot survive that view is a prefix hobby. Write down what the stranger learned: hop vendor, domain, maybe policy records.
Search certificate logs for names you forgot. A surprise subdomain is a surprise join key.
Search Git, app stores, and Stripe descriptors for the domain. Those join harder than MX.
Read HOLD. Existence oracles are correlation. If 250 versus 550 teaches prefixes, tighten policy.
Read recent threads for founder@ answering a private alias. You are the join key.
If you run two domains, re-check payment and WHOIS. If they still match, keep the word theater on the map.
If you are an agency, re-check whether client workspaces stayed split.
If a FAQ or sales macro gained the word anonymous, delete it. That word is how arguments die on a live lookup.
If staff bios gained founder@ next to a hobby domain, that is a people join. Talk to them. DNS cannot.
If unlinkability became the real job this quarter, buy a mask or a real second identity. Do not add prettier prefixes and call it done.
Quarterly honesty review
Say the sentence out loud: containment yes, anonymity no. If you cannot, you drifted.
Re-run a disable. Re-run a stranger MX view.
Re-read questionnaires you answered. If a no became a maybe, fix the maybe.
Re-read the privacy policy. Stealth adjectives are bugs.
Update the join-key list. Public records grow.
Confirm HOLD and unguessable login prefixes still exist on high-risk items.
Confirm you did not promise MailerZ would hide someone from an employer or a state.
If a journalist asked, write what you said. Support should say the same sentence.
If you added a third domain, write why or delete it.
Boring is the goal. If the review is exciting, you claimed too much last quarter.
Appendix notes
Plus addressing remains one mailbox identity. Forms strip it. Custom domain alias privacy does not include plus tags as unlinkability. Stop selling them as stealth.
Suite subaddressing still has a suite vendor as the viewer. Different adversary. Same honesty rule.
A disposable shared domain blends you into a crowd and cannot send-as your brand. Different product. Do not mix it into a company invoice path.
A VPN hides an IP, not a From domain. Buying both does not multiply anonymity. It hides a path and still publishes a name.
Encrypted bodies with a public From are confidentiality of content, not unlinkability of identity. Do not confuse the words in a questionnaire.
Staff bios that put founder@ next to a hobby domain are a people join. Talk to them. MX cannot edit LinkedIn.
A court order to the destination inbox will not be stopped by aliases. Counsel will. Do not promise otherwise.
Git commits, app store listings, and Stripe descriptors join harder than MX. Review them when you review certs.
Historic website copies keep old addresses. A disable does not unpublish a 2022 footer from an archive.
Agency retainers that reuse one workspace across clients create a metadata join. Split workspaces if the retainer cares.
WHOIS privacy hides some fields and never hides that the name exists. Write that on the map.
A third domain without a written why is theater. Delete it or write the why, including payment and WHOIS overlap.
If a journalist asks live, let them resolve MX. Then say containment. If you cannot do that, you claimed too much.
If unlinkability is now the job, buy a mask or a real second identity with separate payment. Prettier prefixes will not get you there.
Questionnaires get no for anonymity. Maybe is how deals die later. No is how they die early or survive.
Closing notes
Closing note: say containment yes, anonymity no, then resolve your own MX as a stranger. Custom domain alias privacy that cannot survive that view is a prefix hobby.
Join keys include the domain, MX, certs, Git, app stores, Stripe, payment, WHOIS, one destination inbox, and the From you pick when you reply. Prefixes are the small wall.
HOLD stops existence oracles. Disable is the privacy you bought. A second domain with the same card is theater.
Questionnaires get no for anonymity. Sales macros do not say stealth. Journalists may look up MX on the call. Let them.
If unlinkability is the job, buy a mask or a real second identity. If containment is the job, start free, isolate leaks, and stop calling that stealth.
Agency workspaces that mix clients are a metadata join. Split them if the retainer cares. Staff bios are a people join. Talk to people.
Boring is the goal. Exciting privacy claims are how live lookups go badly. Repeat the sentence until nobody wants a meeting about it.
Final operator pass
Final pass: say the sentence. Resolve MX as a stranger. Disable a lab alias. Read HOLD. Search certs and Stripe. Custom domain alias privacy is honest when those five still match the memo.
No stealth in policy. No in questionnaires. No founder@ answering a private alias in living threads. No third domain without a why.
If unlinkability showed up as the real job, you started a mask or a real second identity with a different card. If not, you stopped calling prefixes stealth.
Agency workspaces split if required. Staff bios checked. Archive footers accepted as history you cannot unpublish.
Start free if you want the kill-switch. Do not start free if you wanted invisibility. Those are different purchases.
More operator notes
More notes: if you publish SPF and DMARC, those records are also public join keys. Custom domain alias privacy includes them. They are good for sending and visible to strangers. Both facts stand.
If you use the same support mailbox for 'private' aliases, support is a join key. Split tickets or accept the join.
If analytics on the marketing site show the same people who receive hobby aliases, the site is a join key. That is normal for a company. Do not call it stealth.
If you screenshot the alias map into Slack, Slack is a join key with search. Use the ticket system with access control.
If a contractor's laptop has the map, collect it at offboard. Laptops outlive retainers.
One last note
One last note: if you use a privacy-focused registrar, you still published a name. Custom domain alias privacy does not become unlinkability because the registrar markets privacy. The name is public. The hop is public. The kill-switch is yours.
If you mentor another founder, give them the sentence before the dashboard. People who hear stealth first will spend a year unlearning it.
If you need a citation for mail transport while you say this, use the SMTP RFC and keep the product claims inside what MailerZ actually does: exclusive MX, named aliases, HOLD, intact Header From, paid send-as. Nothing about hiding the domain.
FAQ
What is the safest way to handle custom domain alias privacy?
Use unique aliases for leak isolation. Assume the domain correlates them. HOLD unknown. Do not publish the alias map. Do not claim anonymity.
Does this require a new mailbox?
No. A new mailbox does not remove domain correlation. A new registrable domain does, at the cost of a second identity.
Will it work with Gmail or Outlook?
Yes as destinations. Those providers also see that many aliases land in one inbox. That is another correlation, inside their account.
What DNS records are involved?
MX and TXT on the zone are themselves correlation. Public resolvers will show MailerZ or whoever you chose.
What should you test?
That disabling one alias leaves others up, and that a stranger can still see the same MX for every alias on the zone.
Can a subdomain per vendor remove correlation?
It reduces casual prefix matching and increases DNS work. The parent organization and payment trail often still join them.
Key takeaways
- Custom domain alias privacy is a kill-switch, not stealth.
- The registrable domain correlates every alias.
- MX and certificate logs are public.
- One destination inbox is another join key.
- HOLD unknown stops guessed extras, not correlation.
- A second domain is a second identity, not a setting.
- MailerZ will not sell anonymity.
- Say the honest sentence before you buy.
Conclusion and next action
Explain custom domain alias privacy as a kill-switch and a map, not as invisibility. Correlation risk is the domain, the MX, and the public site. MailerZ does not remove those. It makes the leak smaller. Start free if that trade is the one you want.
Want containment you can operate
Start free, isolate leaks with named aliases, and stop calling that stealth.
HOLD unknown. Disable a leak. Do not expect the domain to hide you.
Review quarterly, or sooner if provider behavior, pricing, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.