How to detect and block temporary email addresses at signup

What are temporary email addresses?

Temporary email — also called disposable email, throwaway email, or temp mail — is a short-lived inbox provided by services like Temp-Mail.org, Guerrilla Mail, 10 Minute Mail, Mailinator, and hundreds of others. The user gets a working address instantly, no registration required. Emails arrive in real time. The inbox expires anywhere from 10 minutes to a few days.

From a purely technical standpoint, these addresses are valid. The domain has MX records. The inbox receives email. A regex check passes. A basic MX lookup passes. The address looks identical to a legitimate one.

Why temp mail hurts your product

Developers often underestimate the problem until they look at their user table. Common patterns:

• Free tier abuse. A single person creates dozens of accounts to get repeated access to a free trial or free quota.
• Skewed analytics. Signup numbers look healthy but most accounts are one-time throwaways that never convert.
• Dead email lists. Marketing emails bounce at a high rate once the temp addresses expire, damaging your sender reputation.
• Fraud and spam. Bad actors use disposable addresses to post spam, file fake support tickets, or exploit referral bonuses.
• Wasted onboarding cost. Every automated welcome email, verification email, and drip sequence fired at a dead address costs money and deliverability reputation.

The challenge: temp mail evolves faster than blocklists

The naive solution is a domain blocklist — a text file of known disposable providers. That list exists. You can find it on GitHub with 100,000+ domains. The problem is the list is always stale. New temp mail services appear daily, and existing ones cycle through domains to evade filters.

A purely blocklist-based approach catches the obvious cases (mailinator.com, guerrillamail.com) but misses the long tail. The detection problem is fundamentally an ongoing one, not a one-time list import.

How to detect temporary email addresses

1. MX record checks

Most temp mail providers share infrastructure. Certain mail servers handle thousands of disposable domains. Checking whether a domain's MX record points to a known temporary mail provider's servers catches a large slice of the problem, including domains that don't appear on any blocklist yet.

# DNS lookup for MX records
dig MX tempinbox.com
# → points to a shared disposable mail server

The limitation: large providers like Gmail and Outlook also run shared infrastructure, so you can't block on shared servers alone. You need to combine MX analysis with domain reputation data.

2. Domain blocklist lookup

A curated blocklist handles the well-known providers reliably. The key is using a maintained list, not a static file you imported once. Providers like Tickstem update the blocklist continuously, so you get coverage for new domains without any work on your end.

3. Domain age and registration signals

Temp mail domains are often newly registered or have minimal web presence. WHOIS data and domain age can supplement other signals. A domain registered two days ago with an MX record pointing to shared mail infrastructure is almost certainly disposable.

4. Pattern matching on common structures

Many temp mail services use predictable address formats: [email protected] where the local part is a UUID or random string, or a username that looks machine-generated. Pattern matching alone has too many false positives to be reliable, but it adds signal when combined with other checks.

5. API-based verification (the reliable approach)

All of the above signals need to be combined and weighted. The practical approach is to use a purpose-built verification API that handles the signal aggregation, keeps blocklists current, and returns a single verdict per email address.

Here's what a one-call check looks like with Tickstem:

curl -X POST https://api.tickstem.dev/v1/verify \
  -H "Authorization: Bearer tsk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]"}'

{
  "email": "[email protected]",
  "valid": false,
  "disposable": true,
  "mx": true,
  "reason": "disposable_domain"
}

The disposable field is the one to act on. Block or flag any address where it returns true.

Implementation patterns

Block at the point of entry

The right place to check is on your signup form, before writing anything to your database. Call the verification API on form submission. If disposable: true, return an error to the user immediately:

// Node.js example
import { VerifyClient } from '@tickstem/verify';

const verify = new VerifyClient({ apiKey: process.env.TICKSTEM_API_KEY });

async function handleSignup(email) {
  const result = await verify.check(email);

  if (result.disposable) {
    throw new Error('Please use a permanent email address to sign up.');
  }

  if (!result.valid) {
    throw new Error('That email address does not appear to be valid.');
  }

  // proceed with signup
}

Soft-block vs hard-block

For most products, a hard block (reject the signup entirely) is the right default. Some products prefer a soft block: allow signup but flag the account for manual review, restrict access to paid features, or require additional verification before granting full access.

The choice depends on your tolerance for friction. Hard blocks eliminate the problem entirely; soft blocks let you study edge cases before committing to a policy.

Don't check on every request

Email verification is a signup-time check, not a per-request check. Cache results by domain if you're processing bulk imports. For real-time signup forms, one check per submission is the right pattern.

Popular temp mail services your users are using

Service	Notes
Temp-Mail.org	Very popular, cycles through many domains
Guerrilla Mail	Long-running, multiple domains
10 Minute Mail	Fixed 10-minute expiry
Mailinator	Public inboxes at mailinator.com and aliases
Throwam	Newer, used to evade basic blocklists
Dispostable	API-accessible disposable inboxes
Yopmail	Persistent but anonymous inboxes
Sharklasers / Guerrilla Mail aliases	Same infrastructure, different domains

What about legitimate use cases?

Privacy-conscious users sometimes use alias services — Apple's Hide My Email, SimpleLogin, or Fastmail aliases — to protect their real address. These are different from temp mail: the address is permanent, forwards to a real inbox, and the user intends to receive ongoing emails.

A good verification API distinguishes between disposable temp mail and privacy aliases. Tickstem's disposable flag is false for forwarding aliases because they exhibit the behavior of real, permanent addresses (active MX, established domain, no expiry).

Summary

Blocking temp mail reliably requires combining multiple signals: domain blocklists, MX record analysis, domain reputation, and pattern matching. Doing this yourself means maintaining a continuously updated dataset. A verification API handles that maintenance and gives you a single field to act on.

The check takes one API call at signup time. The cost of not checking is fake accounts, abused free tiers, and degraded sender reputation — costs that compound over time.