The alias forwarder trick: 707 forwarding domains

By Adrian Crismaru · Founder, vrfymail · Published 2026-05-16

Someone signs up to your app with bob@neverbox.com. The domain looks vaguely throwaway — generic, doesn’t ring a bell — and your disposable blocklist probably misses it because the npm package you imported was last updated two months ago. You accept the signup, welcome email goes out, and two weeks later you notice the same person signed up 47 more times under bob@inboxclean.org, bob@9ox.net, bob@advantimal.com, bob@man-or-machine.com, bob@neverbox.net, bob@neverbox.org. Same Bob, same real Gmail, different alias forwarder domains pointed at it.

Welcome to the alias forwarder trick. In our database we currently classify 707 mail domains as alias-forwarders, run by 16 operators, behind which sits a small set of MX servers whose only job is to take an inbound email at a “disposable-looking” domain and forward it to a real Gmail / Outlook / Fastmail inbox the end user (or operator) controls. Your signup form sees bob@neverbox.com. Bob sees the email in his real Gmail at bob@gmail.com. The disconnect is the whole point.

This post explains the mechanism, names the operators we’ve identified, and shows the detection signals that separate alias-forwarders from disposable mail (which is a related but mechanically different attack on your signup form). At the end: what to do about it in your verification call.

How the trick works mechanically

Email routing is decided by DNS MX records. When mail.example.com tries to deliver to bob@neverbox.com, it looks up neverbox.com’s MX, finds the host listed there, opens an SMTP connection to that host, and delivers. After that, the receiving MX server gets to do whatever it wants with the message.

A normal mail provider parks the message in a mailbox and exposes it via IMAP or webmail. The user logs in, reads it, replies. Done.

An alias-forwarder MX server does something different. It looks up the local-part (bob in bob@neverbox.com), maps it to a configured destination address (e.g., bob@gmail.com), rewrites a couple of headers, and re-emits the message via SMTP to that destination. The user never logs in to neverbox.com — there’s no inbox to log into. They just receive the message in their real Gmail.

To anyone observing the email envelope, the message went to bob@neverbox.com. To anyone reading the inbox, the message arrived at bob@gmail.com. Same email, two valid-looking addresses, completely decoupled identity.

Some services do this transparently for legitimate users. Spamgourmet (founded 2000) has been doing it for 25+ years; their pitch is exactly the trick described above, framed as a privacy feature. DuckDuckGo offers @duck.com aliases that forward to your real inbox. SimpleLogin, AnonAddy/addy.io, Burnermail.io, Mozilla’s Firefox Relay (@mozmail.com), iCloud Hide My Email — all the same mechanism, all opt-in by the legitimate end user.

The same mechanism, used adversarially, lets one Gmail account sign up to your free trial 50 times under 50 different “different” email addresses. The catch: you need MX-server-level infrastructure to do the forwarding. So there’s a relatively small set of operators running the infrastructure that backs all of these domains. Find the operators, find the domains.

The 16 alias-forwarder operators we’ve identified

Pulled from production data:

The legitimate operators are the ones you’ve probably heard of — they have privacy-focused users who chose to use them. The reason all 16 land in the same bucket is mechanical: their MX servers receive your signup confirmation and forward it somewhere else. Whether the “somewhere else” is a real user’s Gmail (legitimate use) or a fraudster’s Gmail (signup abuse) is invisible from the outside.

One operator sits in a different category: yopmail-co runs 654 domains and is the only one in the table whose business model isn’t transparent user-opt-in. Yopmail’s user-facing brand is “free temp mail” — the famous one that’s been around since 2007 — but mechanically it runs the same alias-forwarder pattern, with the destination address controlled by Yopmail’s infrastructure rather than the end user.

The MX-server tell: park-mx.above.com

The MX hostname is the strongest signal. We track 7 distinct MX backends for the 16 operators:

gourmet.spamgourmet.com       → spamgourmet (48 forwarder domains)
gourmet7.spamgourmet.com      → spamgourmet
smtp.spamex.com               → spamex
mail.burnermail.io            → burnermail
mail.altmails.com             → altmails
smtp-inbound1.duck.com        → duck.com (DuckDuckGo Email)
park-mx.above.com             → yopmail-co (654 forwarder domains)

The interesting one is park-mx.above.com. Above.com is a commercial domain-parking service owned by NameMedia. They run MX infrastructure that domain owners can point at as a “we’ll handle email for you, just forward it to my real inbox” service. Yopmail’s 654 different brand domains all resolve to MX hosts under above.com’s parking infrastructure. That’s how one operator runs 600+ “different” email services without standing up 600+ mail servers — they use Above.com’s shared infrastructure.

The detection that catches this isn’t “look up if domain is in a list.” It’s:

1. Look up the MX hostname.
2. Match it against a small set of known alias-forwarder MX hostnames (the 7 above).
3. If matched, return verdict alias-forwarder.

This works even on a brand-new domain Yopmail spun up yesterday — as long as its MX still points at above.com, the new domain is flagged before it’s ever in any blocklist.

We also keep parent-domain MX patterns for numbered-MX rotation. Currently above.com is the only alias-forwarder pattern, but the same machinery catches numbered variants like mx1.above.com, mx99.above.com, etc., if/when the operator starts rotating them. The detection table runs at ~50ms per check (one DNS lookup; the hot path is 0 when the domain itself is already classified at ~5µs).

Why your blocklist misses these

The npm disposable-email-domains package, the GitHub Hexxeh/email-blacklist list, and the ZeroBounce / NeverBounce / Kickbox baseline lists all share the same shape: a static list of domain names, manually curated, refreshed on whatever cadence the maintainer feels like.

Three problems with the static-list shape for alias-forwarders specifically:

1. The operator can mint domains faster than the list refreshes. Yopmail’s 654 domains include long-tail brands the average maintainer has never seen — wuuvo.com, 1clck2.com, 0-mail.com, tempmail.com (yes, the domain literally called “tempmail.com” is a Yopmail-controlled alias-forwarder). Adding new ones takes minutes; getting them into the npm package takes weeks.
2. Legitimate alias-forwarders look identical to abused ones. DuckDuckGo’s @duck.com, SimpleLogin’s user-domain aliases, Firefox Relay’s @mozmail.com — same MX-forwarding mechanism as Yopmail. A blocklist that just says “duck.com is bad” will reject every privacy-conscious user. Static lists either include them and over-block, or exclude them and under-block. They can’t do both.
3. The signal lives in the MX record, not the domain. A domain like inboxclean.org looks generic in a list. Its MX (gourmet.spamgourmet.com) is the actual tell. Static lists don’t track MX provenance; they just track the domain.

The fix isn’t a longer list. It’s a different architecture: cluster domains by MX backend, classify the backends once, and let the lookup work on either side.

What this means for your signup form

When /v1/check hits an alias-forwarder, vrfymail returns:

{
  "result": "risky",
  "reason": "alias_forwarder",
  "reason_message": "This address forwards to another mailbox. Allow if the user is logging in via that mailbox; flag if you're enforcing one-account-per-person rules.",
  "did_you_mean": null
}

The verdict isn’t undeliverable — alias-forwarders deliver mail just fine, and a meaningful portion of your real users have legitimate reasons to use them (privacy, account isolation, signing up for things they don’t want in their main inbox). Blocking outright will alienate the exact users you want.

The pattern we recommend depends on what you’re protecting against:

• Newsletter signup, free download, low-stakes flow: accept. The user gets the email at their real inbox; you get a hand-raise. The fact that the recipient routes through a forwarder is none of your business.
• Free trial of a paid product, especially if you have a “one trial per person” rule: treat alias-forwarder as risky. Allow signup but stamp the account with a flag; if a fraud signal shows up later (chargebacks, abuse pattern), the flag corroborates that you’re seeing the same person twice.
• Signup with high-value benefits attached (free credits, referral bonuses, gated educational content with a per-user cap): canonicalize the forwarding destination if you can. SimpleLogin and Anonaddy don’t expose the destination; Spamgourmet’s older API does in some cases. The de-duplication target is the underlying real Gmail, not the alias.
• Account creation for a regulated service (KYC-style, financial, healthcare): block the alias-forwarder and require a real address. The compliance posture justifies the friction.

The verdict-handling pattern is the same shape as role_account (info@, support@) — soft warning, your form decides.

How we keep the alias-forwarder list current

Three channels feed the table:

1. Operator registry (945 operators total, 16 of which are alias-forwarders). Each operator has an MX-backend fingerprint that catches their domains regardless of whether any specific domain is in the static list. Add a new alias-forwarder operator once; we catch every domain they spin up after.
2. MX-pattern detection (Tier 2b). For operators that rotate numbered MX hosts (mx1, mx2, mx99), we maintain parent-domain regex patterns. The above.com pattern catches Yopmail’s continuous domain expansion automatically.
3. Customer-consensus promotion. If ≥3 different vrfymail customers report bounces or spam complaints on the same domain within 30 days, the domain promotes to a global flag. Free-mail providers (Gmail, Outlook, Yahoo) are explicitly excluded so a wave of bad signups against Gmail doesn’t pollute the table.

The detection latency for an MX-backend match: ~50ms (one DNS lookup; cached on hot paths). The signal stack runs alongside disposable detection, spam-trap detection, role-account detection, syntax checks, and your per-customer bounce overlay — all in one /v1/check call.

FAQ

Is using an alias-forwarder a red flag?

By itself, no. Millions of people use Firefox Relay, SimpleLogin, DuckDuckGo Email, and others as legitimate privacy tools — including, presumably, some of your best customers. The flag matters when paired with other signals (rapid resignup, payment-method reuse, IP overlap, abuse patterns) or when your business rules explicitly require a real address.

What’s the difference between an alias-forwarder and a disposable email?

A disposable email (mailinator, 1secmail, mail.tm) gives you a temporary, publicly-readable inbox at a throwaway domain. An alias-forwarder gives you a private, normally-permanent inbox at a throwaway-looking domain that forwards to your real one. Mechanically: disposable has its own MX + storage; alias-forwarder has an MX that immediately re-routes. From your form’s perspective: disposable signups never see your email; alias-forwarder signups read it in their real Gmail.

Can I block all alias-forwarders?

You can, and vrfymail will return the verdict so you can choose to treat alias_forwarder as undeliverable in your handler. We don’t recommend it for consumer-facing flows — you’ll reject paying customers using Firefox Relay or DuckDuckGo Email. For B2B or regulated flows where address verification matters more than signup conversion, blocking is the right call.

Why does Yopmail show up here? I thought it was a temp-mail site.

Yopmail’s user-facing product is “free temp mail” — public inboxes addressable by anyone who knows the email. Mechanically, the back-end runs through park-mx.above.com, an alias-forwarder infrastructure. Our verdict reflects the mechanical reality: Yopmail’s domains are alias-forwarders that happen to forward to a public, read-by-anyone destination. The signup-form implication is the same as for any other alias-forwarder: the address routes through infrastructure outside your control.

How do I tell my real users about this without sounding paranoid?

You don’t need to. The whole point of the risky verdict is that the signup completes; your application logic just keeps an extra flag on the account. The user never sees the check happen.

Try the verdict on a real address

vrfymail’s /v1/check returns the alias-forwarder verdict in 50ms p50 alongside disposable detection, spam-trap probes, and your per-customer bounce overlay. Free tier: 5,000 verifies/month, no card. Get an API key →

Updated 2026-05-16