Sites detect email alias providers when you use a well-known mask domain they already block. A custom domain you own looks like any other domain. MailerZ is the latter: hello@yourdomain, exclusive MX, durable routing. It is not anonymous disposable email. If a site blocks addy-style provider domains, your own zone usually still works. That is not a stealth promise. MX and WHOIS still exist. No inboxing percentage.
Quick answer for detect email alias provider
Blocklists target famous provider domains, not every zone on earth.
RFC 5321 does not hide MX. Anyone can look up who receives.
Your company domain on MailerZ is identifiable as your brand. That is the point.
Disposable provider domains are a different aisle. They get fingerprints.
Do not dual-use a public brand as a stealth mask. You will confuse customers and still be visible.
Start free on your zone if the job is routing, not hiding.
Authoritative mail transport is defined in IETF RFC 5321 — Simple Mail Transfer Protocol. Product path: email alias service, custom-domain email alias, and aliases and catch-all.
User problem and decision criteria
Decision criteria: durability vs anonymity, whether the site blocks known masks, whether you own the zone.
If a bank requires a “real” domain, a mask domain may fail. Your zone may pass.
If you needed to hide from the site, you picked a fight MailerZ will not win as a feature.
Agencies should not sell MailerZ as stealth.
WHOIS privacy is registrar, not MailerZ.
No SOC 2 as stealth.
Catch-all increases guessability, not stealth.
Plus-addressing is a Gmail fingerprint of another kind.
Technical mail flow
Signup form → maybe a deny list of known mask domains → accept or reject.
Custom domain: MX lookup shows MailerZ hosts. That is visible to anyone who looks. Most forms do not look.
Abuse desks can look. Expect that.
Header From is your domain. That is intended.
Step-by-step setup / decision path
- Pick the job: brand vs mask.
- If brand, use your zone on MailerZ.
- Do not print a mask domain as careers@.
- HOLD unknown.
- Exclusive MX.
- Do not promise sites cannot see MX.
- Keep throwaways on a mask app if you still want them.
- Probe your own signups on a spare account.
Classify the next failure before a second DNS edit.
HOLD unknown unless you wrote a FORWARD reason.
Quote live pricing before promising alias counts.
Failure modes and proof
Sold as stealth.
Brand zone used as a mask firehose.
Known mask domain blocked—user blames MailerZ.
Catch-all FORWARD.
Self-send.
Inboxing claim.
Header rewrite to hide.
Open relay.
Invented detection stats.
WHOIS confusion.
Dual MX.
No job split.
MailerZ workflow and product boundary
MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. Not Workspace, not IMAP, not an open relay, not a campaign ESP.
Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. Exclusive MX. Hold unknown on Free. Copy SMTP host, port, and TLS or STARTTLS from the dashboard when you send.
Free: one domain, three aliases, one seat, fourteen-day store, fifty outgoing a month, no send-as. Solo forty dollars a year, fifteen aliases, ninety-day store, one hundred outgoing, five send-as per hour. Starter eight or eighty. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote pricing. No SOC 2, ISO, HIPAA, SLA, or inboxing percentage.
Cost, alternatives, and trade-offs
A blocked mask domain costs a signup. Expected.
A burned brand domain from catch-all costs more.
Stealth marketing is refund cost.
Your own zone is the durable spend.
Agencies: honesty is cheaper.
WHOIS privacy is a registrar SKU.
No fake detection rate.
HOLD is cheap hygiene.
Operational depth
Tell founders: MX is public. Always. Detection is a policy at the site, not a MailerZ toggle.
If a site blocked you, read whether they blocked the domain string or something else (VPN, cards).
Do not change MX to “look like Google” as stealth. That is leftover MX and a lie.
Privacy-alias pages on this site are about durable custom-domain aliases, not anonymity theater.
HOLD so you do not look like a spam cannon, which gets domains listed for a different reason.
Agencies: write “not anonymous” in the SOW.
Security page for enterprise. No badges.
Probe important signups.
Keep ESP reputation off this domain if you also blast.
No legal advice on ToS evasion. Do not evade.
Quote plans.
Disable leaked aliases.
What is visible and what is not
Sites can see the domain you typed. If that domain is yours and MX points at MailerZ, a curious operator can look up MX and guess you use a forwarder. That is DNS. We do not hide that you have a website. A privacy mask on a provider-owned domain is a different class. Popular mask domains get blocklists. Owned domains get MX lookups. Pick the job.
MailerZ does not claim to strip plus tags, randomize local-parts, or look like a consumer mailbox provider. Header From on inbound stays the original sender. Envelope uses SRS on the forward. A destination admin who reads Authentication-Results will see a forward, not a magic cloak.
If you need the destination to look like you received mail at Gmail only, you are asking Gmail to be the identity. The domain in To: is still yours. Shops that reject “role” addresses may reject hello@yourdomain whether or not a hop exists. That is their policy. We do not sell a bypass.
Disposable and shared-domain aliases are detectable because the domain is famous. Moving those identities onto a domain you own changes the detection surface from “known mask provider” to “your brand.” That can be better or worse. Banks may like a brand. Trackers may correlate all local-parts on that brand. Correlation risk is a different article. This page is detection of the hop.
Do not dual-publish a mask provider’s MX beside MailerZ to “look like both.” Leftover MX splits mail and makes detection the least of your problems.
Send-as makes the domain more visible, not less. Recipients see your From. SPF, DKIM, and DMARC exist so they can authenticate it. Hiding a hop while sending as the domain is a contradiction. Free cannot send. Paid send-as is meant to be seen.
Catch-all FORWARD increases the local-parts that exist in the wild. More strings to harvest. HOLD on Free keeps unknowns off the public path. That is an operations choice, not anonymity.
Self-send tests do not tell you what a shop’s risk engine sees. They tell you what Gmail did with your own message. Probe inbound for delivery. Do not treat a sign-up form as a hop test.
If a site blocks you, the fix is rarely MX. It is their list. Creating a new local-part on the same domain may not help. Changing to a suite MX will not hide the brand. Changing to a mask provider changes class and portability.
Exclusive MX still matters. Empty history from leftover Google MX is not “stealth.” It is mail in the wrong store.
No claim that MailerZ is undetectable. No claim that we defeat KYC. No review counts. No inbox SLA if a shop files you as spam.
Agencies: client brand domains are supposed to be visible. If a client wanted masks, they wanted a privacy app. Do not sell the hop as a cloak.
Read /security for product controls. Read a privacy-alias vendor’s docs if hiding the mailbox is the job. Quote them live. Nofollow commercial links.
If you still want the hop, start free, create the names you will print, delete leftovers, and accept that MX is public. That honesty is the product.
MX, From, and blocklists without folklore
Anyone can query MX. If MailerZ hosts are there, a script can label you as using a forwarder. That is public DNS, same as RFC 1035. We do not offer stealth MX. If stealth is the job, you are in the wrong class.
Recipients of your paid send-as see your domain. Authentication-Results will show SPF and DKIM as the dashboard published them. That is the opposite of hiding. Do not buy send-as to be invisible.
Inbound, the shop sees the address the user typed. If they typed hello@yourbrand.com, they see yourbrand.com. The hop behind it is not a mask. If they typed a SimpleLogin or Relay mask, they see that provider’s domain. Different class. Quote those vendors if that is the job.
Blocklists that target forwarder IP space can affect any hop. We do not publish a placement rate when that happens. Destination Gmail can also file mail. Neither fact is proof a site “detected MailerZ” specifically. Copy hop rows before you change brands.
Role addresses (sales@, info@) are often blocked by forms regardless of hop. That is role policy, not MX detection. Using firstname@ on the same domain is a different local-part, still the same brand.
Changing MX to Workspace does not hide the brand. It changes the store. Detection of “this is a company domain” remains. Do not buy seats to dodge a form.
Leftover MX makes detection worse: some mail hits Google, some hits MailerZ, forms still see the same To:. You gain split inbound and lose nothing on visibility.
Catch-all FORWARD increases harvested local-parts. More strings for the same brand. HOLD keeps the public set small. That is operations, not anonymity.
Self-send does not reveal what a shop’s fraud engine does. Sign-up tests are not hop tests. Probe inbound separately.
Agencies: do not tell a client the hop is “private email.” It is branded routing. Privacy apps are the other brochure.
No claim we defeat KYC, credit checks, or government forms. No claim we are undetectable. No review counts.
If a form rejects the domain, create a different printed name only if you also update the account. MX tricks will not pass their list.
Read /security. Read competitor privacy docs with nofollow. Decide class. Then exclusive MX for the class you bought.
Start free if you accept MX is public and Gmail stays the store. If you cannot accept that sentence, do not buy the hop.
Header From intact means the world sees the original sender on inbound. We will not rewrite it to look local. Detection of a forward is sometimes that intact From plus SRS envelope. That is the product working.
Worked scenarios for detect email alias provider
A signup form blocks @addy.io and a list of famous mask domains. Your hello@yourdomain.com still submits. That is the usual story. The site detected a provider domain, not 'aliasing' as a concept. Your zone is just a zone. MailerZ did not hide you. It hosted a name you already publish on a website.
A bank blocks any domain younger than a year or any domain whose MX points at a known forwarder. Then a custom domain can fail too. That is a risk list, not magic detection of MailerZ specifically. If unlinkability or bank onboarding is the job, a consumer mask and a business domain are different purchases. Do not promise stealth.
A newsletter wants to reject 'role' local-parts. They regex sales@ and info@. That is not provider detection. That is a local-part policy. Use a person-shaped alias if you must subscribe, or do not subscribe from a role address.
A dating app or marketplace fingerprints plus-tags and disposable MX. Your durable domain alias is a different class. Still, WHOIS, reused password emails, and sibling aliases on the same zone correlate. Detection of a provider is only one join key. Correlation is the rest.
An agency puts all clients on one obvious forwarder-looking subdomain pattern. Sites that list that pattern will treat you like a mask farm. Use each client's registrable domain. Do not invent a shared 'alias.agency.com' as a privacy product. That is a blocklist magnet.
A user wants MailerZ to look like Gmail MX so sites 'trust' them. That request is leftover MX and a lie. Exclusive MailerZ MX. If a site requires Google Workspace, buy Workspace or walk away. Do not dual-publish to impersonate a suite.
Practice and anti-patterns around detection
Practice: own the zone you print. Anti-pattern: expecting a famous mask domain to pass every signup forever. Those domains are on lists because they are famous.
Practice: unique local-parts per vendor if leak isolation matters. Anti-pattern: one hello@ everywhere and then asking why a site 'knows' you.
Practice: HOLD unknown. Anti-pattern: catch-all FORWARD so a site that guesses names confirms you receive them all. That is a detector you built yourself.
Practice: tell privacy buyers the domain is public. Anti-pattern: marketing 'anonymous email forwarding' as stealth. This product is durable routing on a name you own.
Practice: if a site blocks you, read whether they blocked the domain, the MX, the local-part, or your IP. Anti-pattern: flapping MX to look like Google.
Practice: keep exclusive MX. Anti-pattern: adding Google MX so a checker shows Workspace. Checkers that care will also see the split. Customers will too.
Practice: quote /security and refuse HIPAA or SOC 2 as a detection workaround. Anti-pattern: a badge to soothe a bank form.
Operator closeout when a site blocks you
Closeout names what they blocked: domain, MX provider list, local-part class, or something else. If you do not know, you will 'fix' the wrong layer.
If they blocked a mask domain, the fix is your own zone on MailerZ, not a second mask. If they blocked your zone, the fix may be a different relationship with that site, not DNS theater.
If they blocked role local-parts, change the string you use there. Do not change MX.
If leftover MX is present, delete it before you blame detection. Split inbound looks like chaos and some risk engines hate chaos.
Do not write to the site claiming SOC 2. Write nothing invented. Use the printed support path.
If unlinkability was the real job, closeout says you chose the wrong tool and names a mask app class. Honesty here prevents a refund fight later.
Edge cases in provider detection
MX-based lists go stale. A host change can get you blocked or unblocked without you changing product. Re-check the live MX the site sees. Two resolvers.
Some sites resolve MX from a server far from you. Your 'it looks fine here' is not their view. Ask what they resolve, or use a public lookup.
Sibling aliases on one zone are a correlation even when the provider is invisible. shop@ and founder@ on the same domain tell a story. Unique prefixes reduce blast radius, not linkage of the zone.
Plus-addressing at Gmail is easy to detect and is not MailerZ. Do not confuse a plus tag with a custom-domain alias when a site says they 'detected an alias.'
A site that requires an A record or a website on the same domain is not detecting MailerZ. They are detecting a parked name. Publish a site or pick a domain you actually use.
Legal identity checks will ask for documents. No MX trick passes KYC. Do not try.
Field notes from blocklist tickets
People hear 'alias' and think 'hidden.' Sites hear 'alias' and think 'abuse farm' when the domain is famous. Your own zone usually sits in the middle: visible as a name, not famous as a product.
The tickets that fail are stealth requests. The tickets that succeed are leak-isolation requests. Sell the second. Decline the first.
Agencies that reuse one zone for many clients get treated like a provider. That is detection you earned. Give clients their domains.
Do not scrape blocklists as a product promise. They change. This article will not publish a list of domains that currently fail. Measure the site in front of you.
Link /aliases-catch-all and /security. Privacy is isolation and disable, not invisibility.
RFC 1035 MX is public by design. Anyone can ask. That is the internet. A custom domain makes you more identifiable than a mask, which is the other article. This one is about lists, not WHOIS philosophy.
Handoff memo for privacy-minded buyers
MailerZ: your domain, exclusive MX, named aliases, HOLD unknown, Header From intact, envelope SRS. Not a mask network. Not disposable.
Detection: famous provider domains get lists. Your zone usually does not, until a site writes a custom rule against your MX or your name.
If they need stealth, they need another product. If they need killable prefixes on a name they own, they are in the right place.
Exclusive MX still required. Looking like Google is not a privacy feature and not a deliverability feature we will claim.
Free has no send-as. Privacy of inbound aliases is a different chapter from sending. Do not mix them in the memo.
Acceptance criteria for a detection conversation
The buyer can say whether they needed stealth or isolation. You did not sell stealth.
A blocked signup has a named layer: domain, MX list, local-part, or other. You did not flap MX to impersonate a suite.
HOLD is on unless a written reason exists. Catch-all FORWARD is not a detector you run against yourself.
Unique aliases exist for the vendors that matter. One hello@ everywhere is a choice you documented.
No leftover MX. No invented badges. No inboxing percentage as a workaround for a block.
If they left for a mask app, the note says that without bitterness. Fit over trophies.
Operations review of public identity
Review which zones are client brands versus a shared agency pattern. Shared patterns attract lists.
Review printed local-parts that look like roles if you subscribe to picky newsletters. Change those strings, not MX.
Review WHOIS privacy as a separate registrar control. MailerZ does not replace it and does not contradict a public website.
Review whether anyone dual-published to 'look hosted.' Delete the leftover. That trick is an outage and a tell.
Quote /pricing if they thought unlimited unique aliases were free. Caps are real. Confirm the card.
Start free on a domain you already publish. Do not buy a throwaway zone and expect it to pass every bank.
Quarterly review of detection reality
Did any important site start blocking your MX class? Measure. Do not mythologize. Do not impersonate Google MX.
Did we market anonymity? Delete that sentence. Durable aliases yes. Anonymity no.
Did catch-all FORWARD confirm guessed names to strangers? Turn HOLD back on.
Did a client still want a mask? Refer them. Keep the hop for the brand domain.
Did leftover MX return? Re-query. Delete.
Author: MailerZ editorial, Secuno LLC. Review when blocklists, pricing, or scope change.
Closing notes on lists versus zones
Sites detect email alias providers when you use well-known mask domains they already list. A custom domain you own usually looks like any other domain. MailerZ is that second class. It will not hide yourdomain. MX and WHOIS still exist.
If you need stealth, buy a mask and accept blocks. If you need killable prefixes on a name you own, start free, HOLD unknown, and keep exclusive MX.
Product path: /aliases-catch-all, /security, /email-forwarding. No inboxing percentage. No badges.
Honest answers to “will they know?”
Will they know the domain? Yes. They typed it or you did.
Will they know MX is a forwarder? They can look up MX. Public DNS. We do not hide hosts.
Will they know Gmail is the store? Not from To:. They might from behavior, filters, or if you tell them. We do not cloak Gmail.
Will send-as hide you? No. Send-as shows your domain on purpose. Free cannot send. Paid send-as is visible identity.
Will HOLD hide unknown names? It keeps them off the public path. It is not anonymity. It is a missing-name signal.
Will FORWARD hide you? No. It publishes more local-parts into the world.
Will Workspace MX hide the brand? No. Different store. Same brand.
Will a privacy mask hide the mailbox? Often the mask domain is famous and blocked. Different class. Quote them live.
Will leftover MX help stealth? No. It splits mail and still shows the To: domain.
Will we rewrite Header From so inbound looks local? No. Intact Header From is a hard line. SRS is envelope only.
Will we beat KYC or bank forms? No. Do not buy the hop for that.
Will we promise placement if a form drops you? No inbox SLA. Copy hop rows. Their list is theirs.
Agencies: say “branded routing,” not “private email,” unless you sold a privacy app.
Self-send will not answer “will they know?” Sign-up forms are not hop tests. Probe inbound separately.
Start free if you accept MX is public. If you cannot, do not start.
/security for controls. No SOC 2 sentence. No review count. No stealth SKU.
If a site blocks role addresses, change the local-part they accept or accept the block. MX tricks will not pass their policy.
Detection of a hop is often working authentication and public MX. That is mail on the internet, not a breach of a promise we never made.
FAQ
- What is the safest way to handle detect email alias provider?
- If you need durability, use a domain you own on MailerZ. If you need anonymity, a mask app—and accept that popular mask domains get blocked. Do not expect MailerZ to hide that you have a website. Exclusive MX. HOLD unknown.
- Does this require a new mailbox?
- No. MailerZ is not IMAP. Keep Gmail or Outlook unless you need a suite for other reasons.
- Will it work with Gmail or Outlook?
- Yes as destinations. Self-send is not proof. Use a third mailbox and open original.
- What DNS records are involved?
- Exclusive MX, verification TXT, one SPF if you send-as. Leftover MX is a hard stop. Dashboard values only for sending.
- What should I test before production?
- A uniquely titled probe from an unrelated provider to each public alias. Confirm Header From and hop history.
Key takeaways
- Known mask domains get lists.
- Your zone is public MX.
- MailerZ is not anonymity.
- Do not stealth a brand.
- HOLD unknown.
- Split throwaways to a mask app.
- No leftover MX theater.
- No detection statistics invented.
Conclusion
Sites can list famous alias providers. They can also look up MX on any domain. Own a zone for durability, not for invisibility.
Start free if you want hello@yourdomain to work like a normal address.