You paste the alias into the signup form and the form hands it back. Sometimes the message is honest: this email provider is not supported. More often it is a flat please enter a valid email address, which is untrue. The address is valid, the domain has MX records, mail sent to it arrives. The site has simply decided it does not like what comes after the @.
Occasionally it is worse than a form error. The account is created, you use it for a week, and then it is suspended, or a password reset quietly never arrives.
This is a common and demoralising complaint about forwarding aliases, and the reflex fix, generating a different alias and trying again, usually fails for the same reason the first one did. The fix that works takes a little more effort and then holds.
Why sites block alias and forwarding domains
Two things are going on, one defensible and one careless. The defensible one is fraud filtering. Free trials, referral credits, review farms and giveaway abuse all depend on one person looking like a thousand people, and a throwaway inbox is the cheapest way to manage that. One widely used open-source blocklist describes its purpose in exactly those terms: preventing fake signups, trial abuse and evasion of verification.
The careless part is where the lists come from. Few sites have any reason to build one, so most import a list somebody else maintains. The best known community list is deliberately conservative, requiring a screenshot of a page where an address on that domain can actually be generated before anything gets added, and it grows slowly as a result. Other lists take the opposite approach, aggregating several feeds into a single file that is rebuilt and committed automatically every day, running past a hundred thousand domains with nobody reviewing the additions.
Aggregation is how forwarding services get swept in. Once a forwarding domain appears in one input feed, every list that consumes that feed inherits it, and every site using any of those lists starts refusing the address. Some maintainers hold the line: one states plainly that forwarders such as anonaddy.com, icloud.com or relay.firefox.com are fine and do not belong in a disposable list. That distinction is a judgement call made by volunteers, and it is not made consistently.
A third mechanism is blunter than either. Some sites abandoned blocklists for allowlists of the large consumer providers. Mozilla's FAQ for its own masking service warns users that some sites refuse addresses containing a subdomain, and that others have stopped accepting anything except Gmail, Hotmail or Yahoo. RFC 5321 is explicit that the local part of an address must be interpreted only by the host named in the domain part, so a signup form inventing rules about somebody else's mail system is guessing, and it guesses wrong more often than its authors think.
You are not the abuse being filtered
The irony is worth sitting with, because it explains why arguing rarely helps. A disposable inbox is designed to stop existing. That is its whole function, and that is what makes it useful to somebody opening a hundred accounts in an afternoon. A forwarding alias is the opposite. It points at a mailbox you read every day, it is attached to an account you maintain, and you expect to still be receiving mail through it in three years. Aliases exist so you can tell which site leaked your address, not so you can vanish.
Measured on the thing the site actually cares about, whether it can still reach you next year, someone using a forwarding alias is usually the safer bet, not the riskier one. The filter is not measuring that. It matches the text after the @ against a list, and a string match has no appeal process. The suspicion is not invented, though. The suspicion is not invented either: a forwarding domain does hand one person an endless supply of addresses, which is the property the fraud filters exist to catch. That makes the filtering imprecise rather than irrational.
What sometimes works, and how often it does not
In ascending order of effort, here is everything you can try without changing your setup, with an honest reading of each.
- Wait and retry. Blocklists do accept removal requests, but the site still has to pull a fresh copy, and a licensed commercial list refreshes on somebody else's schedule. This occasionally works over months. It almost never works today.
- Contact support. Worth about five minutes for a service you genuinely need. Where a human reads the ticket and can add an exception, it does work. The likelier outcome is a template reply asking you to use a real email address, because the agent has no control over the validation rule and often does not know it exists.
- Try a different alias domain. The best of the three, because list coverage is uneven and a domain one list carries another has never heard of. If your provider offers more than one shared domain, the second may sail through. You cannot inspect what the site is checking, so it is a guess, and the more popular a shared alias domain becomes, the more lists eventually carry it.
- Do not reach for an actual disposable inbox to get past the check. It will expire, and with it goes your ability to reset the password. That converts a signup annoyance into a lost account.
None of these are dependable, and the third is dependable only until it is not. Try each once rather than treating them as a plan.
What actually fixes it: an alias on a domain you own
A domain you registered yourself is very unlikely to be on a disposable list, and the reason is structural rather than lucky. The exception is a domain that had a previous owner, so check the one you want against a couple of the public lists before you pay for it. Nobody can generate an address on it except you. There is no public signup page to screenshot, which is the exact evidence the careful lists demand before adding anything. If it has never been registered before, it has no history of abuse, because it has had no other users. To a validator it looks like a small company's mail domain, which is precisely what it is.
You keep everything you wanted from aliases: a fresh address per site, visibility into which one leaked, the ability to shut one off. If you like, a catch-all makes every address on the domain live without creating it first, so you can invent one at the counter and it simply works. This is the only option here that removes the problem instead of dodging it, and it is why alias services offer custom domains.
Two honest costs. A domain carries a registration fee and an annual renewal, and if you let it lapse every address on it dies at once, including any account whose password reset points there. Put the expiry in a calendar the day you buy it. The second cost is a privacy trade. Every address on your own domain is visibly related to every other one, and the domain can be looked up. On a large shared alias domain you are one of thousands of people; on your own you are the only one. For most people, escaping the blocklists is worth that, but it is a genuine difference and not everybody should make the same call.
Roughly what setting that up involves
The work takes an evening, most of it waiting.
- Register a domain. Short and boring is fine, but stay on a mainstream extension such as .com or .net. The bargain-bin TLDs are the ones abused most heavily, so validators and spam filters treat them with the same suspicion you are trying to escape. Unless it is going on a business card, nobody needs to find it memorable.
- Point the MX records at whoever will handle the mail. MX records are how a sending server works out where to deliver a message for your domain, and you set them in the DNS section at the registrar you bought it from. Google's own documentation warns that MX changes can take up to 72 hours to be recognised, so a delay is normal rather than a sign of failure.
- Add the verification and authentication records your provider asks for: a TXT record proving you own the domain, plus the SPF and DKIM entries.
- Create one address and send yourself a test message before you use the domain anywhere real.
Do the DNS first and use the domain second. Some validators check that a domain has a working MX record before accepting an address on it, so a domain registered ten minutes ago with nothing configured will be rejected too, for a completely different and entirely fair reason.
When to just use your real address
There is a category of account where an alias is the wrong tool, and it is worth being blunt about it. Banks, brokers, tax and government services, health providers, your employer, anything where a message that fails to arrive costs you money or a deadline. Use your real address for those.
The logic is simple. An alias buys containment: when a shop leaks its customer list, one address is exposed and you can kill it, and that is what makes the cleanup manageable. It costs you one more component sitting between the sender and your inbox. For a newsletter or a forum that trade is obviously good. For a bank statement or a recovery code, a single failed delivery outweighs years of containment.
Your email address is also the recovery route for everything else you own. NCSC guidance on hacked accounts notes that attackers set up mail forwarding rules precisely because receiving your mail is what lets them reset your passwords. Any address that can reset something important should have as few moving parts as possible.
So what to do about a rejection depends on what you were signing up for. If it is a shop, try another alias domain and move on. If it is something you will depend on for years, the rejection is a decent prompt to set up a domain of your own, or to use your real address, rather than spending an evening generating masks until one slips through.