my registration form is getting flooded with signups on disposable email domains, hundreds a day. they never confirm but they bloat my user table and some slip through and spam the comments. i already have a honeypot on the form. is anyone actually keeping disposable emails out cleanly, or do you just let them in and clean up after? trying to decide if a blocklist is worth maintaining or if thats a losing game
still worth filtering but a static domain blocklist on its own is a losing game, the throwaway services spin up new domains faster than you can list them. what tends to work is requiring email confirmation before the account can do anything, plus a maintained disposable-domain list as a second layer. if your junk signups never confirm, confirmation gating kills most of the damage by itself
i see same thing on my site. the blocklist help but it is never complete, so i add a check on the mx record also, many disposable domain have no real mail server behind them. i keep the list for the obvious ones but the mx check catch the new domains i dont know yet. together it cut my junk signup a lot
that lines up with what im seeing, the junk never confirms so gating everything behind confirmation makes the flood harmless even when a new domain gets through. the table still fills with unconfirmed rows but i can purge those on a schedule. good, ill gate first and treat the blocklist as cleanup not the main defense
Worth being precise, blocking disposable email is not the same goal as blocking bots, and conflating the two is why people overbuild this. The disposable address is a symptom, the automation is the cause. A confirmation gate plus a rate limit on the signup endpoint stops the automated flood regardless of which domain it uses. Chase the automation, not the ever changing domain list.
one small thing, whatever you block, log what you rejected and read it sometimes. i had a blocklist quietly rejecting a real provider my users actually used and i lost signups for weeks before i noticed. the filter was working too well. keep the rejects in a log so you can see what it is actually catching