How to detect and block Mailinator emails (and 4,000+ disposable domains)

Mailinator gives anyone a working inbox at any @mailinator.com address with no signup, no password, no verification. For your application, that means free-tier abuse, fake signups, and a contact database full of addresses nobody owns. Here is what Mailinator actually is, why a blacklist alone is not enough, and how to block it reliably.

What is Mailinator?

Mailinator is a free, public disposable email service. Anyone can send mail to [e-mail] and read it at mailinator.com without registering, logging in, or proving ownership. Inboxes are public — if you know the address, you can read the mail. Messages auto-delete after a few hours.

The service exists for a real reason. Developers use it to test signup flows, password resets, and transactional email without polluting personal inboxes. QA engineers use it to verify that delivery actually works. The problem is that the same property that makes it useful for testing — anyone can claim any address instantly — makes it the path of least resistance for anyone who wants to avoid giving you a real email.

Mailinator email lookup: how it works in practice

A user types [e-mail] into your signup form. They open https://www.mailinator.com/v4/public/inboxes.jsp?to=j8djk2 in another tab. Your welcome email arrives there. They click the verification link, claim the free trial, and walk away. The address you stored in your database is shared with anyone on the internet who guesses or learns it.

Mailinator also operates several alternative domains for users trying to get past simple blocklists: @maildrop.cc, @guerrillamail.com, @throwawaymail.com, @10minutemail.com, and dozens more. Mailinator itself sells a paid tier for legitimate enterprise testing with private inboxes — most of the public abuse comes from the free public side.

Mailinator disposable email risks for your application

The risks depend on what your application does, but they fall into three buckets:

1. Free trial and credit abuse
Every SaaS with a free trial faces this. A single person creates dozens of accounts using [e-mail], [e-mail], and so on. Each account claims the trial credits, free API calls, or starter quota. For a tool with a generous free tier and meaningful unit costs (AI inference, video processing, SMS), this drains real money. Stripe will not chargeback you because nobody charged anything — the damage is on the cost side.

2. Compromised email-verification security
If your "email verification" step just confirms that someone can receive a message at the address, Mailinator passes it trivially. Anyone who can guess the address can read the verification link. Any account using a Mailinator address has no real owner — there is no second factor, no recovery channel that only one person controls. Treating these accounts as "verified" gives a false sense of security.

3. Marketing list and deliverability damage
Mailinator inboxes auto-delete. Messages are read once or not at all. If your sender reputation depends on engagement metrics (Gmail, Outlook, Yahoo all weight this heavily), having a meaningful chunk of your list at @mailinator.com drags your domain reputation down. You can ship the best email campaign of your life and it will land in spam because your list has too many addresses nobody opens.

Why a regex check is not enough

The standard email regex like /^[^@]+@[^@]+\.[^@]+$/ happily accepts [e-mail], [e-mail], and [e-mail]. The address is syntactically valid. The domain exists. Messages actually deliver. There is nothing the regex can catch — disposable email isn't a malformed address, it's a perfectly valid address you don't want.

You need a different category of check entirely: looking up whether the domain itself belongs to a known disposable service.

Approach 1: Static blocklist

The simplest defence is a list of disposable domains. Maintained lists exist on GitHub:

• disposable-email-domains/disposable-email-domains — about 4,000 domains, MIT licensed, updated monthly
• martenson/disposable-email-domains — similar coverage, also community-maintained Drop the list into your signup handler and reject any domain in it:

// JavaScript example — works the same in any language
import disposableDomains from "./disposable-domains.json"

const isDisposable = (email) => {
  const domain = email.split("@")[1]?.toLowerCase()
  return disposableDomains.has(domain)
}

if (isDisposable(formData.email)) {
  return res.status(400).json({ error: "Please use a non-disposable email address" })
}

This blocks maybe 80 percent of the disposable traffic you will see. The reason it isn't 100 percent: disposable services launch new domains weekly. By the time your blocklist updates, the latest @catchmail.io or @spamgone.org has already been used to register hundreds of trial accounts. You are always slightly behind.

Approach 2: MX record lookup

Mailinator and most disposable services share a small set of MX records. A DNS query for the domain's mail exchangers reveals not just whether the domain receives mail (it does) but who runs that infrastructure.

$ dig +short MX mailinator.com
10 mail2.mailinator.com.
20 mail.mailinator.com.

$ dig +short MX guerrillamail.com
20 mx-guerrillamail.com.

Combine MX-resolution with a pattern check on the MX hostname. A domain whose MX points at mail.mailinator.com is clearly Mailinator regardless of what the apex domain is called. This catches white-label disposable services that share the same backend.

This is also where you catch the second-biggest signup problem: domains with no MX records at all. A typo like [e-mail] passes regex but fails MX lookup. Rejecting these saves you from bounces and the sender-reputation hit they cause.

Approach 3: Full verification — MX, disposable, role-based, syntax

The robust signup check combines all four signals:

1. RFC-5322 syntax parse (not just a regex — catches subtle malformation)
2. MX record lookup (rejects typo domains and abandoned domains)
3. Disposable domain match (rejects Mailinator and ~4,000 others)
4. Role-based prefix detection (admin@, info@, noreply@ — flag but don't always block)

The Tickstem verify API does all four with a single call. Here is the Go SDK example:

import "github.com/tickstem/verify"

client := verify.New(os.Getenv("TICKSTEM_API_KEY"))

result, err := client.Verify(ctx, "[e-mail]")
if err != nil {
    log.Printf("verify failed: %v", err)
    return // fall back to accept-and-warn, never block on outage
}

if result.Disposable {
    return errors.New("please use a non-disposable email address")
}
if !result.MXFound {
    return errors.New("email domain does not appear to accept mail")
}
if result.RoleBased {
    log.Printf("signup with role-based address: %s", email)
    // proceed but flag for review
}

Same check in Python:

from tickstem import VerifyClient

client = VerifyClient(api_key=os.environ["TICKSTEM_API_KEY"])
result = client.verify("[e-mail]")

if result.disposable:
    raise ValueError("please use a non-disposable email address")
if not result.mx_found:
    raise ValueError("email domain does not appear to accept mail")

Same in Node.js:

import { VerifyClient } from "@tickstem/verify"

const client = new VerifyClient({ apiKey: process.env.TICKSTEM_API_KEY })
const result = await client.verify("[e-mail]")

if (result.disposable) {
  throw new Error("please use a non-disposable email address")
}
if (!result.mxFound) {
  throw new Error("email domain does not appear to accept mail")
}

What about catch-all and unverifiable domains?

A small caveat: mailbox-level verification (does this exact inbox exist?) is unreliable in 2026. Most mail servers run in catch-all mode at the gateway, accepting any address for the domain and bouncing later. SMTP probing — actually connecting to port 25 and asking the server — gets blocked by every major cloud provider as part of anti-spam policy.

For practical purposes, "the inbox accepts mail at the gateway" is the strongest signal you can get without sending the message. MX + disposable + role-based covers the cases that actually matter for signup flows. Catch-all aside, you do not need port 25 probing.

Comparison: blocklist vs MX vs full verification

Approach	Catches Mailinator	Catches new disposable domains	Catches typos	Latency
Regex only	No	No	No	0ms
Static blocklist	Yes	No	No	1ms
MX lookup only	No	No	Yes	50–150ms
Full verification API	Yes	Yes	Yes	80–200ms

One important caveat: never make signup completely dependent on a third-party API. If the verification service has an outage, your signup should fail open with a logged warning, not block legitimate users. Treat the result as a strong signal, not a hard gate when the network call itself fails.

What to put in the rejection message

The exact wording of the rejection message matters. "We do not accept Mailinator addresses" tells a knowledgeable attacker exactly which check you are running, and they will try the next service. Better:

• Generic and polite: "Please use a non-disposable email address" — works, but obvious
• Specific and informative: "This appears to be a disposable inbox. Please use a work or personal email address" — most useful for honest users who typoed
• Best for security-sensitive flows: Accept the signup, mark the account as restricted, require additional verification (phone, SSO, credit card pre-auth) before unlocking the full feature set The third option is the safest pattern for high-value services. You never tell the attacker exactly what tripped the check, and you do not lose legitimate users who happen to use a service you do not recognise.

Mailinator alternatives users will try

For completeness, the most common disposable services users switch to when Mailinator is blocked:

• Guerrilla Mail — @guerrillamail.com, @sharklasers.com
• 10 Minute Mail — @10minutemail.com, several rotating domains
• Temp Mail — @temp-mail.org and similar
• Yopmail — @yopmail.com
• Maildrop — @maildrop.cc
• EmailOnDeck — multiple rotating domains

All of these are covered by the maintained blocklists linked above. A blocklist-plus-MX-check stack catches them all.

Try it

The Tickstem verify API does the full check (syntax, MX, disposable, role-based) in a single call and returns a structured result. The Free tier includes 500 verifications per month — enough for most early-stage applications. Larger volumes are covered by Starter, Pro and Business plans.

Install the SDK in your language of choice:

• Go: go get github.com/tickstem/verify
• Node.js: npm install @tickstem/verify
• Python: pip install tickstem

You can also try the verification with a single curl call against our public endpoint — see the verification documentation for details.