I run AliasFleet, an email alias service that gives every website its own forwarding address, so your real inbox stays private and a leaked address names the site it came from. If a signup form rejects one of those addresses, it has almost always rejected the domain behind it. Not the alias. The domain.
You will have seen the message. You paste in an address that worked yesterday, an address that has mail sitting in it, and the form pushes back: "Please enter a valid email address." Or "This email address is not accepted." Nothing about the address is invalid. The form has looked at the bit after the @ sign, matched it against a list, and decided your kind of address stays out.
Hold onto that distinction, because everything useful follows from it. If aliases themselves were the problem, your only move would be to hand over your real inbox and be done. They are not. The domain is the problem, and a domain can be swapped without giving up the habit that protects you.
The block is aimed at the domain, not at you
Ask the two big providers and you get the same answer, in almost the same words. SimpleLogin's documentation says most websites allow registration with a SimpleLogin alias, then adds that some websites have been reported as not accepting a SimpleLogin domain. addy.io's FAQ puts it shorter. Asked whether websites accept its aliases, it answers "almost all do", with a few sites blocking their domains after mistaking alias services for short-lived inbox services.
An email alias is not a disposable email service. You open an account to get one. It points at an inbox you actually own, it stays live for years until you switch it off yourself, and you can reply from it like any other address. A signup form sees none of that. It sees a domain, shared by thousands of other people using the same provider, and it judges the crowd rather than the person. Put that domain on enough lists and every address sitting on it gets turned away at once, the careful and the careless together. One provider, twenty smooth signups, then a wall on the twenty-first. That pattern is the tell.
SimpleLogin also gives you a way to separate a block from a plain bug. A few sites just say it plainly. Plenty do not. You get a vague error, or no error at all, and the account quietly never appears. Try a different address from a mainstream provider instead. If that one sails through while the alias bounces, your typing was never the issue. The domain was.
A signup form runs your domain through a list
None of this machinery is secret. It is documented, open source, and blunter than most refused users expect.
Start with the layer you will meet most often: the blocklist. An open-source blocklist on GitHub keeps a file of domains it describes as often used to register dummy users in order to spam or abuse services. Its example code is the whole method in a few lines. Pull the domain out of the submitted address. Check it against the list, then check every parent domain above it. On a match, stop the signup and ask for a permanent email address instead. The project also quotes the Python Package Index on its own practice: PyPI blocks registration with listed domains using this list, topped up with an internal list of its own.
Site owners do not have to discover this for themselves. They get taught. Auth0's support guidance on fraudulent signups sets out two routes: build a list of domains and deny any registration that matches, or wire in an email reputation service and let its score decide who gets in. Oracle's NetSuite documentation sells the same flow as a built-in feature, where an address given at registration or checkout is checked for valid format and against the blocklist, and a blocked domain earns a message saying it cannot be used. Commercial services have packaged the check too. Kickbox, for one, offers it as an API that flags an address at the moment of capture, before the address ever reaches the database.
Two things about how email aliases actually work matter here.
First, the parent-domain check blunts the obvious workaround. Because the matching code walks up the chain, an address on a subdomain can still be caught by an entry for the parent above it. A subdomain is not a clean escape hatch. Providers have worked this out, which is why they keep several unrelated domains on offer rather than minting endless subdomains off a single name.
Second, the list is not the only gate, even if it does most of the work. Lists lag. New domains turn up faster than volunteers can catalogue them, so reputation services try to read signals around a domain instead of relying on its name alone, things like its mail server setup and how recently it appeared. How widely that second layer gets used against alias domains specifically is hard to verify, and most sites publish nothing about their checks. Put the blocklist at the centre of your thinking, then, and treat the rest as the likely explanation when a fresh domain fails and nobody will tell you why.
Refusals cluster where free accounts get abused
Nobody publishes refusal rates. Nobody credible publishes a ranking of which kinds of site refuse most, either, so a league table here would be made up. What the reports give you instead is a motive. The motive predicts where the walls go up better than a list of names would.
A site reaches for a blocklist when a free account is worth abusing. Fifty accounts for spam. Trials farmed one after another. A ban dodged by signing up again, a comment section stuffed. Follow that incentive and the cluster makes sense. Social platforms sit near the top of it. In the Privacy Guides thread that this article is built on, one poster says every SimpleLogin alias they tried was rejected while they were creating a Bluesky account. They contacted SimpleLogin support and Bluesky support. In the end a normal mailbox account worked. The same poster reports trouble with aliases at the Washington Post and the NY Times, although that report tangles the alias trouble up with VPN trouble and never separates the two. Read it as friction reported, not a clean refusal proven.
For your own signups, the working rule is rough and practical. Expect the hardest walls at social networks, forums, free-tier software carrying a valuable trial, and anywhere a brand new account is worth money or reach straight away. Expect an easier ride at shops, newsletters and paid services, where the site wants your address for receipts and a purchase already ties you to the account. That is a tendency pulled from the reports, not a measurement. Individual sites break it in both directions, regularly.
The fallback ladder, in the order worth trying
Members of the original Privacy Guides discussion talk through the ladder they actually climb when this happens, and the provider documentation lines up behind the same order. Start at the top and work down. Every rung you descend gives up a little more of what the alias was doing for you.
Rung 1: another domain from the same provider. Providers keep spare domains for exactly this moment. Refused on one? Generate the alias again on a different domain they offer and submit that. A minute of your time. Nothing else lost.
Rung 2: a provider subdomain. SimpleLogin's own advice for a blocked site is to use a subdomain or your own domain, and its subdomain feature puts addresses under a name you choose, sitting on a provider parent domain. Sometimes that passes where the plain shared domain failed. Sometimes it changes nothing, for the parent-matching reason covered above, which is why this rung ranks below the first on effort even if you end up trying it second.
Rung 3: a different alias provider. A blocklist entry names domains. It does not name an idea, and a second provider brings a completely different set of domains with it. Posters in the thread who were refused everywhere with one provider got through with another provider's address. You pay for that with a second account and a second dashboard to keep track of, and nothing stops the new provider's domains getting listed next year instead.
Rung 4: an alias on your own custom domain. This is where the ladder has been heading. A domain only you use has no place on a shared list, because there is nothing shared about it. The custom domain poster in the thread puts it without dressing it up: they run a custom domain with SimpleLogin and do not recall that domain being refused once. One person's experience is not a rate, and no domain is immune to being blocked. Still, the mechanism holds. You gain something else on this rung too, portability. addy.io points out that aliases on a domain you own keep working if you move providers, because you simply point the domain at the new service, while aliases on a provider's own domains only ever work through that provider.
On AliasFleet, this is the custom domain setup: managed subdomains come with the free plan, and full custom domains arrive with Pro, per the pricing page. The DNS side lives in the custom domain documentation and the notes on managed subdomains. Go in clear-eyed about the trade. Put every alias on a domain of your own and those addresses are visibly yours, so a service can see they belong to one person. Acceptance improves. Portability improves. The cover of a crowd of other alias users goes. The real email visibility question runs in both directions here.
Rung 5: a permanent address you control, kept for this purpose. A second real mailbox, opened at a mainstream provider and used rarely and on purpose, almost never gets refused, because to a signup form it looks like what it is: a normal mailbox. Its weakness is the old one, concentration. Every account you park there ends up sharing a single address again. The fuller argument, for and against, sits in the piece on whether you need a second email address. Save this rung for the accounts it would genuinely hurt to lose.
Rung 6: your real primary address, or walking away. Some accounts are worth your main address, if nothing else gets past the form. Plenty are not. Thread posters describe skipping a service altogether when it refuses aliases, on principle, and that is a proper final rung rather than a defeat. If you do hand the address over, write down which account got it. A leak years later is far easier to trace when that note exists. Whether aliases are safe for any given account is a judgement about the account in front of you, not about aliases in general.
| Rung | Why it can pass | What it costs you |
|---|---|---|
| Another provider domain | A different list entry, often unlisted | A minute; nothing structural |
| Provider subdomain | A name the list may not carry | Can still match a listed parent domain |
| A different alias provider | Fresh set of domains entirely | A second account and dashboard to manage |
| Your own custom domain | Nothing shared for a list to name | The domain visibly links your aliases to one owner; domain and plan cost |
| A permanent second mailbox | It is a normal mailbox, rarely refused | Many accounts share one address again |
| Your real primary address | Always passes | The exposure aliases exist to prevent |
A refusal stings, and when you need the account now, a public inbox that anyone can read starts to look like a shortcut. Posters in the Privacy Guides thread warn against using one for anything that matters, and they are right to. Whoever runs that inbox can read your mail, and can use password resets to take the account for themselves. A refused alias costs you a few minutes. An account registered to an inbox strangers can open costs you the account, on a date you do not get to pick.
Report the block while you are at it. It will help the next person more than it helps you, and it still counts. SimpleLogin asks users to send in the sites that block them, tracks the reports, tests the sites itself and contacts them to ask for the block to come off. addy.io wants the same thing reported, and for the same reason. A provider cannot argue against a block it has never heard about.
Acceptance at signup is not a promise for life
The worse version of this problem does not announce itself. A site takes your alias without complaint. You use the account for years. Somewhere in that time the site adds your provider's domain to its list, and nobody tells you. You find out at the worst available moment, when the site asks you to verify yourself, sends a code to your alias, and the code never turns up because the domain is blocked now.
The thread carries this in first person, and more than once. One long-standing alias user tells of a verification code that never came because the provider domain had been blocked. The only recovery route on offer was a photograph of their ID, which they were not willing to send. The account was gone. The same poster nearly lost a second account, held for years, when a password change code stopped arriving after the company blocked the alias. What saved them was an app on their phone where they were still logged in, which let them swap the email address to an alias at a different provider. A second poster strips it down further: an alias can stop working at any time, even years after a site accepted it, and they have lost online accounts exactly that way.
You cannot stop a site rewriting its list. You can decide beforehand which accounts would hurt to lose, and set those up so a listing cannot lock you out of them:
- Keep banking, government, health, your password manager, your main mailbox and anything holding money or identity documents on a domain you own or a permanent address, not on a shared provider domain. These services are not singled out because they block more often. They are singled out because a blocked code costs most there.
- Switch on an authenticator app or a security key wherever one is offered. Experience in the thread suggests sites reach for email verification less often when a stronger second factor is already in place. It lowers the risk rather than removing it. Some sites demand an email code anyway, and some send an email-change confirmation to the old address rather than the new one.
- Keep your own record of which accounts sit on which alias. The account inventory method is tedious once. On the day a domain gets listed, it is the thing that lets you move the important accounts before anyone demands a code.
- Hear that a provider domain has started failing at a service you use? Go and test your own account while you still have a live session somewhere. Swapping an email address takes a minute when you are logged in. Without a session, it can be close to impossible.
The domain is the negotiable part
So read a refusal for what it actually is. One domain. One list. One day. It tells you nothing about aliases as an approach, and it is no reason to go back to giving every site the one address you cannot change. Swap the domain first: another of your provider's, a subdomain, a different provider, then your own. Keep the permanent address back for the small set of accounts where a missed code would cost you more than your privacy is worth. You still get a different address for every website, which was the point of all of this. On a low-stakes site where you want sorting rather than separation, plus addressing is the lighter tool, and the alias setup guide walks through the full system in about two minutes.
Top comments (0)