I'm running one such service (inboxes.app), and it often boils down to five really obvious give-aways: 1. The server accepts emails to all emails addresses.

I'm running one such service (inboxes.app), and it often boils down to five really obvious give-aways: 1. The server accepts emails to all emails addresses. If I want to check if a service is a temporary email service or not, hit a few random addresses. If they're accepted and do not bounce that's definitley a little suspect. 2. known addresses If I were going to prevent temp emails, I'd look out for temp-mail type domains. This is a game of cat and mouse though, but blocking the known ones is probably enough to wipe out 80% of these accounts. 3. Low open rate Speaks for its self, especially with disposable emails. 4. random addresses Usually emails are `first.last`, so getting f00b4rb4z@temporaryemailsite stands out 5. Your smtp server IPs are made available via your MX records Offer (paid?) users a new domain to point their domains to with an IP which won't have been blacklisted by providers. Ways of defending against boil down to: bounce addresses that haven't yet been created, allow users to use their own domains, offer random names rather than random strings as addresses. These are all areas I'm working on over time, but with all side projects it takes time :p