This post shows how to reject them at signup with one server-side call, in Node.js, Python and PHP, without breaking your signup when the check fails.

Where to check​

Check on your backend, in the signup handler, before you create the account. A check in the browser can be skipped by anyone who calls your API directly, and it would expose your API key.

The flow:

1. The user submits the form.
2. Your backend sends the typed address to POST https://api.signitize.io/v1/check.
3. If disposable is true, reject with a clear message. Otherwise continue with your normal signup.

The response also tells you whether the address can receive mail at all, and gives a canonical email for duplicate detection:

{ "email": "abc@yopmail.com", "disposable": true, "deliverable": true }

Disposable domains are deliverable: true: they do receive mail, which is what makes them useful for abuse. Check disposable, not deliverable, to catch them.

Node.js​

async function checkEmail(email) {
    try {
        const response = await fetch('https://api.signitize.io/v1/check', {
            method: 'POST',
            headers: {
                Authorization: `Bearer ${process.env.SIGNITIZE_API_KEY}`,
                'Content-Type': 'application/json',
            },
            body: JSON.stringify({ email }),
            signal: AbortSignal.timeout(5000),
        })
        if (response.ok) return await response.json()
        if (response.status === 400) return { invalid: true }
    } catch {
        // timeout or network error: fall through
    }
    return null // unknown: don't block the user
}

const result = await checkEmail(req.body.email)
if (result?.invalid) return res.status(422).json({ error: 'Enter a valid email address.' })
if (result?.disposable) return res.status(422).json({ error: 'Please use a permanent email address.' })
if (result && !result.deliverable) return res.status(422).json({ error: 'This email address cannot receive mail.' })

Python​

import os
import requests

def check_email(email):
    try:
        response = requests.post(
            "https://api.signitize.io/v1/check",
            headers={"Authorization": f"Bearer {os.environ['SIGNITIZE_API_KEY']}"},
            json={"email": email},
            timeout=5,
        )
    except requests.RequestException:
        return None  # unknown: don't block the user
    if response.ok:
        return response.json()
    if response.status_code == 400:
        return {"invalid": True}
    return None


result = check_email(typed_email)
if result and result.get("invalid"):
    raise ValueError("Enter a valid email address.")
if result and result["disposable"]:
    raise ValueError("Please use a permanent email address.")
if result and not result["deliverable"]:
    raise ValueError("This email address cannot receive mail.")

PHP​

function checkEmail(string $email): ?array
{
    $curl = curl_init('https://api.signitize.io/v1/check');
    curl_setopt_array($curl, [
        CURLOPT_POST => true,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT => 5,
        CURLOPT_HTTPHEADER => [
            'Authorization: Bearer ' . getenv('SIGNITIZE_API_KEY'),
            'Content-Type: application/json',
        ],
        CURLOPT_POSTFIELDS => json_encode(['email' => $email]),
    ]);
    $body = curl_exec($curl);
    $status = curl_getinfo($curl, CURLINFO_RESPONSE_CODE);

    if ($body === false) return null; // timeout or network error: don't block the user
    if ($status === 200) return json_decode($body, true);
    if ($status === 400) return ['invalid' => true];
    return null;
}

$result = checkEmail($_POST['email']);
if ($result && !empty($result['invalid'])) exit('Enter a valid email address.');
if ($result && $result['disposable']) exit('Please use a permanent email address.');
if ($result && !$result['deliverable']) exit('This email address cannot receive mail.');

Using Laravel or Django? The integration guides have a validation rule for each.

The rule that matters most: fail open​

Every example above returns "unknown" when the check doesn't answer, and the signup continues. That is on purpose. If an email check can stop your signup, then any outage or network problem between your server and the API takes your signup form down with it.

Failing open doesn't mean skipping the check. Create those accounts as pending, recheck them a few minutes later, and hold back the free credits until they pass. Never block a signup has the full pattern, including the recheck job.

Why not a blocklist file?​

You can download a list of disposable domains from GitHub and check against it. It works on day one and gets worse every week, because throwaway services register new domains constantly. We wrote about this in why disposable email blocklists go out of date.

Signitize combines a list with DNS signals, so a domain registered yesterday can still be caught, and every newly detected domain is remembered for the next check. The details are in Detection.

Write a helpful error message​

The person behind a disposable address may be a real user who just wants privacy. Tell them what to do:

Disposable email addresses are not allowed. Please use a permanent email address.

If you want to keep privacy-minded users, note that relay services such as Firefox Relay, DuckDuckGo Email Protection and Apple's Hide My Email forward to a real inbox. Signitize returns disposable: false for them. Whether to block disposable emails at all is a real trade-off; we cover it in Should you block disposable emails?

Get a free API key: 2,500 checks a month, no credit card.

This post explains why lists fall behind, and what a domain's DNS records reveal about it even when nobody has listed it yet.

Why lists fall behind​

Domains are cheap. Many top-level domains cost a dollar or two for the first year. A temp-mail service can register dozens at once and switch to new ones whenever the old ones get blocked.

Services rotate on purpose. Popular temp-mail sites offer a domain picker or change their default domain regularly, precisely because their users want addresses that sites still accept.

Lists are updated by people. Open-source lists depend on someone noticing a new domain and opening a pull request, then on you updating your copy. Each step adds days or weeks.

Lists can't see private services. Someone running a throwaway setup on their own domains never appears on a public list.

The result: a list stops the domains everyone already knows, and lets through exactly the new ones that people are actively using.

What DNS reveals about a new domain​

A domain built only to receive throwaway mail is set up differently from a real company's domain. Its public DNS records show it:

No single signal proves anything. Plenty of small legitimate domains have no DMARC record. But a domain with no website, no real SPF and a mail server without reverse DNS is very unlikely to belong to someone's real inbox. Scoring several signals together gives a useful answer for domains no list has seen.

The strongest signal: shared mail servers​

Throwaway services rotate domains, but running mail servers is more work, so many domains point at the same few servers. Once one domain is identified as disposable, its mail server becomes a clue for the next one.

That is how Signitize learns:

1. abc@new-burner.xyz is detected by its DNS signals. The domain and its mail server are remembered.
2. The next address at new-burner.xyz is caught immediately, without a DNS lookup.
3. A sibling domain on the same mail server starts with a head start in its score, so it needs fewer other signals to be caught.

Two safety rules matter here. A learned server alone is never enough to flag a domain, so one wrong guess can't block a legitimate business. And mail servers of shared providers (Google, Microsoft, Zoho and others) are never learned, so one bad domain hosted there can't affect anyone else.

What still gets through​

Being honest about limits:

• A temp-mail service with a real website, proper SPF and reverse DNS looks legitimate to DNS checks until it is listed or one of its domains trips the signals.
• Catch-all custom domains (any address @someones-domain.com arrives in one inbox) are real domains owned by real people. They can't be detected from the address.
• When DNS lookups fail, a careful checker answers "not disposable" rather than guessing, so real users aren't blocked by a network hiccup.

That is why the email check should be one layer: combine it with duplicate detection by canonical email and hold back free perks until the email is verified.

Try it​

Detection documents every step, signal and score Signitize uses. The Free plan includes 2,500 checks a month: get a free API key and send it the newest throwaway domain you've seen.

Typos are the most common bad address at signup, and unlike fake addresses, the person behind them actually wants your product. Catching them is pure gain.

The three kinds of typo​

Each needs a different tool, so the answer is three layers.

Layer 1: "Did you mean" in the browser​

The fastest fix is a suggestion while the user is still on the form: Did you mean maria@gmail.com? A small list of popular domains covers most typos:

const DOMAINS = ['gmail.com', 'yahoo.com', 'outlook.com', 'hotmail.com', 'icloud.com', 'aol.com', 'proton.me']

function distance(a, b) {
    const row = Array.from({ length: b.length + 1 }, (_, i) => i)
    for (let i = 1; i <= a.length; i++) {
        let previous = row[0]
        row[0] = i
        for (let j = 1; j <= b.length; j++) {
            const current = row[j]
            row[j] = Math.min(row[j] + 1, row[j - 1] + 1, previous + (a[i - 1] === b[j - 1] ? 0 : 1))
            previous = current
        }
    }
    return row[b.length]
}

function suggestEmail(email) {
    const [local, domain] = email.trim().toLowerCase().split('@')
    if (!local || !domain || DOMAINS.includes(domain)) return null
    const match = DOMAINS.find((known) => distance(domain, known) <= 2)
    return match ? `${local}@${match}` : null
}

suggestEmail('maria@gmial.com') // 'maria@gmail.com'
suggestEmail('maria@takla.com') // null

Show the suggestion as a link the user can click; never change the address silently. Someone whose address really is at a similar-looking domain must be able to keep it. Use your own signup data to extend the list with the providers your users actually have.

Layer 2: reject addresses that can never receive mail​

On the server, reject what can't possibly work:

• the domain doesn't exist (gmaill.con);
• the domain publishes a "null MX", meaning it accepts no mail;
• no mail server resolves for the domain;
• the username breaks the provider's rules, such as _maria@gmail.com (Gmail only allows letters, numbers and periods) or a three-letter Gmail username.

Signitize returns deliverable: false in all these cases, in the same call that checks for disposable domains and duplicate aliases:

{ "email": "maria@gmaill.con", "disposable": false, "deliverable": false }

Reject with a message that points at the fix:

This email address cannot receive mail. Please check it for typos.

What this layer does not catch: typo domains that exist and accept mail. Some common misspellings of big providers are registered by third parties and have mail servers, so they look deliverable. That is why layer 1 matters, and why layer 3 is still required.

Layer 3: the verification email​

Only a verification email proves that the mailbox exists and belongs to the person. It also catches username typos (mraia@gmail.com), which no check can recognize: the address is valid, it just belongs to someone else.

Make it easy to recover from a typo here too:

• show the address on the "check your inbox" page, with a Change email link;
• let users resend the email, with a short cooldown;
• don't unlock free credits or trial perks until the link is clicked.

Why not ask mail servers if the mailbox exists?​

Some validators connect to the mail server and ask whether maria@ exists without sending a message. It looks attractive and works poorly at signup: Gmail, Outlook and Yahoo accept every address at that stage, many servers deliberately answer "yes" to everything, and servers that do this repeatedly get blocked. Signitize does not probe mailboxes; the verification email is the reliable test.

Summary​

1. Suggest corrections in the browser for common provider typos.
2. Reject addresses that can never receive mail on the server.
3. Verify by email, and make changing the address easy.

Layer 2 takes one API call. Get a free API key (2,500 checks a month) and see the Quickstart.

Here are the seven tricks we see most, what each one costs to stop, and which ones an email check can and can't solve.

1. Email aliases​

The trick: one Gmail inbox, many addresses: john+1@gmail.com, j.o.h.n@gmail.com, john@googlemail.com. Each one looks new to your database.

The fix: store a canonical version of every email in a unique column, so all aliases of one inbox collide. The rules differ per provider (dots matter at Outlook, not at Gmail), so this needs care: see How to stop users creating multiple accounts with Gmail aliases.

Cost to you: one column and one lookup. This is the cheapest win on the list.

2. Disposable inboxes​

The trick: a temporary inbox from yopmail, mailinator or one of hundreds of similar services. No account, no phone, a new address every time.

The fix: check the domain at signup and reject throwaway domains. A static list goes stale quickly, so use a check that also detects new domains. See How to block disposable email addresses at signup.

3. Made-up addresses​

The trick: signing up with asdf@asdf.com or an address on a domain that doesn't exist, because your product works before the email is verified.

The fix: two layers. Reject addresses that can never receive mail (domain doesn't exist, publishes "no mail", or the username breaks the provider's rules). Then make the verification email the gate: don't hand out the free credits until the link is clicked.

4. Many real accounts at free providers​

The trick: creating several genuine Gmail or Outlook accounts. Each one is a real, separate inbox.

The honest answer: no email check can tell that alice.w@gmail.com and wonderland.alice@gmail.com belong to the same person, and anyone who claims otherwise is guessing. Making new Google accounts takes effort and, increasingly, a phone number, which limits how far this scales. Beyond that, you need signals other than email:

• a payment method on file for the higher tiers, even if you don't charge it;
• phone verification for the most valuable perks;
• rate limits per IP address range and per device on account creation.

5. Scripts and bots​

The trick: automating the signup form to create accounts in bulk.

The fix: a challenge on the signup form (Cloudflare Turnstile, hCaptcha, reCAPTCHA) and per-IP rate limits on the signup endpoint. Email checks help here too: bots need many addresses, and the cheap sources of addresses are aliases and disposable inboxes.

6. Referral and coupon loops​

The trick: referring yourself. Sign up a second account with an alias, claim the referral bonus on both sides, repeat.

The fix: pay referral rewards only when the referred account is verified and has done something real (made a purchase, used the product for a week). Compare canonical emails of referrer and referred: john@gmail.com referring john+2@gmail.com is the same person.

7. Restarting a trial after it ends​

The trick: when the trial ends, sign up again with a variation of the same address. Or come back after being banned.

The fix: never delete expired or banned accounts outright; keep at least their canonical email. A returning alias then matches the old account, and you can show "Your trial has ended" instead of starting a new one.

Put the perks behind the checks, not the user​

The pattern that ties these together:

1. Check the email at signup. Reject disposable, undeliverable and duplicate addresses with a clear message.
2. If the check can't run (timeout, outage), don't block the signup. Create the account as pending.
3. Hand out free credits, trial time and referral rewards only when the account is checked and verified.

Real users barely notice step 3. Abusers lose the reason to sign up. Never block a signup has the code for this, including the job that rechecks pending accounts.

Where Signitize fits​

Signitize covers tricks 1, 2 and 3 with one call: a canonical email for duplicates, disposable for throwaway domains and deliverable for addresses that can never receive mail. It does not solve 4 to 7 on its own; those need the product rules above.

The Free plan includes 2,500 checks a month, enough for most early products. Get a free API key, or read the Quickstart.

The fix is not to block these addresses: real people use them. The fix is to know they belong to the same inbox.

Why one Gmail inbox has endless addresses​

Gmail delivers mail to the same inbox no matter how the address is written:

Combine them and a nine-letter username has thousands of spellings. Scripts that farm free tiers generate them automatically: johnsmith+1, johnsmith+2, and so on.

+tags (called subaddressing) are a legitimate feature. People use them to filter mail or to see who leaked their address. Rejecting every address with a + blocks honest users and does nothing against dots or googlemail.com.

The fix: a canonical email in a unique column​

Store two values for every user:

• the address the user typed, for sending mail;
• a canonical version, where every alias of one inbox gives the same value, with a unique constraint.

ALTER TABLE users ADD COLUMN email_canonical text UNIQUE;

At signup, compute the canonical email and look it up. If it exists, the person already has an account. Keep banned accounts (or at least their canonical email) instead of deleting them, and every alias of a banned inbox stays banned too.

Always send your verification email to the typed address. The canonical one is a duplicate-check key; for some providers it is not a deliverable mailbox.

Doing it yourself: the Gmail rule​

For Gmail alone the rule is short:

function canonicalGmail(email) {
    const [local, domain] = email.trim().toLowerCase().split('@')
    if (domain !== 'gmail.com' && domain !== 'googlemail.com') return email.trim().toLowerCase()
    return `${local.split('+')[0].replaceAll('.', '')}@gmail.com`
}

canonicalGmail('J.O.H.N.Smith+promo@GoogleMail.com') // 'johnsmith@gmail.com'

It gets harder from here, because every provider has different rules:

• Outlook and Hotmail support +tags, but dots do matter: john.smith@outlook.com and johnsmith@outlook.com are different people. Applying the Gmail rule to them merges strangers.
• Yahoo uses -keyword instead of +tag for its "disposable addresses" (nick-shopping@yahoo.com), and the base name is not the login.
• iCloud has three domains (icloud.com, me.com, mac.com) for the same inbox.
• Proton ignores dots, hyphens and underscores, and has four domains.
• Google Workspace custom domains (sales+crm@company.com) follow Gmail's +tag rule, but you only know a domain is on Google Workspace by looking up its MX records.
• Every other domain decides for itself. On wikipedia.org, jo.hn+x may be a different mailbox, so the only safe change is lowercasing.

Get one of these wrong and you either let duplicates through or, worse, tell a real new user that they already have an account.

Doing it with one API call​

Signitize applies all of these rules and returns the canonical email, together with two other checks you want at signup anyway:

curl https://api.signitize.io/v1/check \
  -H "Authorization: Bearer $SIGNITIZE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"J.O.H.N.Smith+promo@googlemail.com"}'

{ "email": "johnsmith@gmail.com", "disposable": false, "deliverable": true }

In Node.js:

const response = await fetch('https://api.signitize.io/v1/check', {
    method: 'POST',
    headers: {
        Authorization: `Bearer ${process.env.SIGNITIZE_API_KEY}`,
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({ email: typedEmail }),
    signal: AbortSignal.timeout(5000),
})
const { email } = await response.json()

if (await db.users.findOne({ emailCanonical: email })) {
    throw new Error('You already have an account.')
}

The full rule table per provider is in Normalization.

Two mistakes to avoid​

Blocking the signup when the check fails. If the API (yours or ours) is slow, create the account as pending and check it later. Hold back the free credits until then. Never block a signup has the complete code.

Telling attackers which emails have accounts. "This email is already registered" lets anyone test addresses. For a consumer product, consider a neutral message ("Check your inbox to continue") and handle the duplicate by email instead.

Summary​

• Don't block +tags or dots: real users rely on them.
• Store a canonical email in a unique column and check it at signup.
• Send mail to the typed address, never to the canonical one.
• Keep banned users' canonical emails so aliases can't come back.

You can get a free API key (2,500 checks a month, no card) and test your own aliases in the Quickstart.

Who signs up with a disposable address​

Not only abusers. The people behind a temp-mail address are usually one of three groups:

1. Free tier farmers. They want another trial, more credits, another referral bonus. They are the reason the check exists.
2. Privacy-minded users. They want to try your product without joining your mailing list. Some become paying customers once they trust you.
3. Testers. Developers and QA, often your own, trying the signup flow.

Blocking hits all three. Whether that is a good trade depends on what a new account costs you.

When blocking is clearly right​

• Each account has real cost: free AI credits, compute, SMS, storage, or anything you pay for per user.
• Free trials or credits are the main draw. Farmers create accounts because the perk is valuable.
• You need to reach the user later: billing notices, security alerts, account recovery. A temp inbox disappears within hours.
• Referral or coupon programs where each new account earns something.
• Communities and marketplaces where throwaway accounts are used for spam, fake reviews or ban evasion.

When to be careful​

• Content sites and newsletters where an account costs you nothing and a signup is the start of a relationship. Blocking turns privacy-minded readers away for no gain.
• Products for privacy-focused audiences. Your users may have good reasons to hide their main address.
• Early products that need every signup for feedback, and have no free perk worth farming yet.

The cost of blocking​

The conversion loss is real but usually small: in most products, disposable addresses are a small share of signups. The real risk is blocking the wrong addresses:

• Privacy relays such as Firefox Relay, DuckDuckGo Email Protection and Apple's Hide My Email forward to a long-lived real inbox. Treating them as disposable blocks careful people, not abusers. Signitize returns disposable: false for them.
• +tags (maria+shop@gmail.com) are a normal feature, not a disposable address. Rejecting them blocks honest users; handle them with duplicate detection instead.
• Yahoo "disposable addresses" (nick-shopping@yahoo.com) despite the name deliver to a real inbox. They should collapse to one account, not be blocked.
• Outages. If your signup fails whenever the email check fails, an outage blocks everyone. Always fail open.

A middle path: let them in, hold back the perks​

If you are unsure, you don't have to choose between "block" and "allow":

1. Let disposable addresses sign up, but mark the account.
2. Give marked accounts the product, not the perks: no free credits, no trial extension, no referral rewards.
3. Show a friendly note: "Add a permanent email address to unlock your free credits."

Privacy-minded users can still try the product. Farmers get nothing worth farming. You can also track how many marked accounts upgrade their address, which tells you whether blocking outright would cost anything.

How to decide​

Ask one question: what does a fake account cost me?

• If the answer is "money" (credits, compute, rewards), block disposable addresses at signup, with a clear message.
• If the answer is "a row in a table", allow them, or use the middle path, and focus on duplicates and verification instead.

Either way, the check itself is the same single call; only what you do with disposable: true changes. Get a free API key and try it on your own signup data, or start with the Quickstart.