Elijah Brown

One free trial per person in Laravel: normalise Gmail dots and plus tags, then enforce it in the database

Elijah Brown — Thu, 15 Oct 2026 13:14:47 GMT

A free trial that hands out credits on signup has a simple loophole. Gmail ignores dots in the local part and drops anything after a plus sign, and it treats googlemail.com as the same mailbox as gmail.com. So jane.doe@gmail.com, janedoe+2@gmail.com and j.a.n.e.doe@googlemail.com all land in one inbox, and each one looks like a fresh account to a plain unique:users,email rule.

This post builds the fix in a fresh Laravel 13 app in four parts: a normaliser, a validation Rule for a friendly form error, a migration with a unique index on trial_claims, and a claim action that writes the claim and grants the credits in one DB::transaction. Then a Pest suite, including a test where four processes race for the same trial at once. Every snippet below comes from the app I ran the tests against.

1. Normalise the address

Keep the stored email exactly as the person typed it. Only the trial key gets normalised.


Two choices worth calling out. Dots and plus tags are only stripped for gmail.com and googlemail.com, because on other providers jane.doe and janedoe can be two different people. And googlemail.com is folded into gmail.com, so the two spellings share one key.
You could extend the plus rule to providers that document it, such as Outlook or Fastmail. I left that out on purpose: a team mailbox like billing+acme@company.com can belong to someone else entirely.
2. A Rule class for the signup form
exists();

        if ($taken) {
            $fail('This email has already been used for a free trial.');
        }
    }
}

Use it next to your usual rules:
$request->validate([
    'email' => ['required', 'email', 'unique:users,email', new FirstTrialForEmail],
]);

This gives a clear message at the form. It is not the guarantee. Two requests can both run this check before either one writes, and both will pass. The database has to settle that case.
3. The migration
unsignedInteger('credits')->default(0);
        });

        Schema::create('trial_claims', function (Blueprint $table) {
            $table->id();
            $table->foreignId('user_id')->constrained()->cascadeOnDelete();
            $table->string('normalised_email');
            $table->timestamps();

            $table->unique('normalised_email');
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('trial_claims');

        Schema::table('users', function (Blueprint $table) {
            $table->dropColumn('credits');
        });
    }
};

The unique index on normalised_email is the line that actually enforces one trial per person. trial_claims is its own table rather than a column on users, so it can outlive the account. As written, deleting a user cascades and frees their email for another trial. If you want the claim to survive account deletion, make user_id nullable and use nullOnDelete() instead of the cascade.
4. Claim and grant in one transaction
 $user->id,
                    'normalised_email' => EmailIdentity::normalise($user->email),
                ]);

                User::whereKey($user->id)->increment('credits', self::TRIAL_CREDITS);
            });
        } catch (UniqueConstraintViolationException) {
            throw new TrialAlreadyClaimed('This email has already been used for a free trial.');
        }
    }
}

The claim row and the credit grant either both happen or neither does. If the insert hits the unique index, Laravel throws UniqueConstraintViolationException, the transaction rolls back, and the credits are never added. No lockForUpdate, no check then insert; the index does the work.
Call it after the user is created, and turn the exception into a normal response:
try {
    app(ClaimTrial::class)($user);
} catch (TrialAlreadyClaimed $e) {
    // The account still exists, it just starts without trial credits.
    session()->flash('status', $e->getMessage());
}

5. Pest tests
The normaliser first, with a dataset of the variants that should all collapse to one key:
toBe('janedoe@gmail.com');
})->with([
    'janedoe@gmail.com',
    'jane.doe@gmail.com',
    'j.a.n.e.d.o.e@gmail.com',
    'janedoe+trial2@gmail.com',
    'Jane.Doe+again@GMAIL.com',
    'jane.doe@googlemail.com',
    '  jane.doe+x@googlemail.com ',
]);

it('leaves dots alone on other domains', function () {
    expect(EmailIdentity::normalise('Jane.Doe@Example.com'))->toBe('jane.doe@example.com');
});

Then the claim flow. The third test is the important one: both requests pass the Rule, and the second one is still refused by the index.
create(['email' => 'jane.doe@gmail.com']);

    (new ClaimTrial)($user);

    expect($user->fresh()->credits)->toBe(ClaimTrial::TRIAL_CREDITS)
        ->and(TrialClaim::count())->toBe(1);
});

it('rejects a Gmail variant in the form rule', function () {
    (new ClaimTrial)(User::factory()->create(['email' => 'jane.doe@gmail.com']));

    $validator = Validator::make(
        ['email' => 'JaneDoe+second@googlemail.com'],
        ['email' => ['required', 'email', new FirstTrialForEmail]],
    );

    expect($validator->fails())->toBeTrue()
        ->and($validator->errors()->first('email'))
        ->toBe('This email has already been used for a free trial.');
});

it('lets the database decide when two requests both pass the rule', function () {
    $first = User::factory()->create(['email' => 'jane.doe@gmail.com']);
    $second = User::factory()->create(['email' => 'janedoe+2@googlemail.com']);

    $rules = ['email' => [new FirstTrialForEmail]];
    expect(Validator::make(['email' => $first->email], $rules)->passes())->toBeTrue()
        ->and(Validator::make(['email' => $second->email], $rules)->passes())->toBeTrue();

    (new ClaimTrial)($first);

    expect(fn () => (new ClaimTrial)($second))->toThrow(TrialAlreadyClaimed::class)
        ->and($second->fresh()->credits)->toBe(0)
        ->and(TrialClaim::count())->toBe(1);
});

6. The concurrency case
The test above runs the two claims one after another. To show the index holding under real parallel writes, this test forks four processes against a SQLite file, each claiming the trial for a different spelling of the same Gmail address. Exactly one should win.
dbFile = tempnam(sys_get_temp_dir(), 'trial').'.sqlite';
    touch($this->dbFile);

    config([
        'database.connections.sqlite.database' => $this->dbFile,
        'database.connections.sqlite.busy_timeout' => 5000,
    ]);
    DB::purge('sqlite');
    Artisan::call('migrate', ['--force' => true]);
});

afterEach(function () {
    DB::purge('sqlite');
    @unlink($this->dbFile);
});

it('gives the trial to exactly one of several processes racing at once', function () {
    $emails = ['jane.doe@gmail.com', 'janedoe@googlemail.com', 'j.anedoe+a@gmail.com', 'JANEDOE+b@gmail.com'];
    $ids = collect($emails)->map(fn ($e) => User::factory()->create(['email' => $e])->id);

    DB::purge('sqlite');
    $outDir = sys_get_temp_dir().'/trial-race-'.getmypid();
    @mkdir($outDir);
    $pids = [];

    foreach ($ids as $id) {
        $pid = pcntl_fork();

        if ($pid === 0) {
            DB::purge('sqlite');
            try {
                (new ClaimTrial)(User::findOrFail($id));
                $result = 'claimed';
            } catch (TrialAlreadyClaimed) {
                $result = 'refused';
            } catch (Throwable $e) {
                $result = 'error: '.$e->getMessage();
            }
            file_put_contents("$outDir/$id", $result);
            posix_kill(getmypid(), SIGKILL);
        }

        $pids[] = $pid;
    }

    foreach ($pids as $pid) {
        pcntl_waitpid($pid, $status);
    }

    $results = array_map(fn ($f) => file_get_contents($f), glob("$outDir/*"));
    array_map('unlink', glob("$outDir/*"));
    rmdir($outDir);

    $counts = array_count_values($results);

    expect($counts['claimed'] ?? 0)->toBe(1)
        ->and($counts['refused'] ?? 0)->toBe(count($emails) - 1)
        ->and(TrialClaim::count())->toBe(1)
        ->and((int) User::sum('credits'))->toBe(ClaimTrial::TRIAL_CREDITS);
});

A few notes on making this work. The default test setup uses an in memory SQLite database, which a forked child cannot share, so this file points the connection at a temp file and migrates it. DB::purge before forking stops the children from inheriting the parent's PDO handle. busy_timeout makes a child wait for the write lock instead of failing at once. Each child writes its result to a file and kills itself, so it never runs the test runner's shutdown code. It needs the pcntl and posix extensions, which the PHP CLI usually has.
On MySQL or Postgres the same action behaves the same way: the loser gets a unique violation inside its transaction and rolls back.
Results
PASS  Tests\Unit\EmailIdentityTest
  ✓ it folds Gmail dots, plus tags and googlemail.com into one address with ('janedoe@gmail.com')
  ✓ it folds Gmail dots, plus tags and googlemail.com into one address with ('jane.doe@gmail.com')
  ✓ it folds Gmail dots, plus tags and googlemail.com into one address with ('j.a.n.e.d.o.e@gmail.com')
  ✓ it folds Gmail dots, plus tags and googlemail.com into one address with ('janedoe+trial2@gmail.com')
  ✓ it folds Gmail dots, plus tags and googlemail.com into one address with ('Jane.Doe+again@GMAIL.com')
  ✓ it folds Gmail dots, plus tags and googlemail.com into one address with ('jane.doe@googlemail.com')
  ✓ it folds Gmail dots, plus tags and googlemail.com into one address with (' jane.doe+x@googlemail.com ')
  ✓ it leaves dots alone on other domains

   PASS  Tests\Feature\TrialClaimConcurrencyTest
  ✓ it gives the trial to exactly one of several processes racing at on… 0.23s  

   PASS  Tests\Feature\TrialClaimTest
  ✓ it grants the trial credits once                                     0.04s  
  ✓ it rejects a Gmail variant in the form rule                          0.01s  
  ✓ it lets the database decide when two requests both pass the rule     0.01s  

  Tests:    12 passed (21 assertions)
  Duration: 0.36s

I also ran the race test 20 times in a row and it passed every time.
What this does not cover
It only closes the Gmail address trick. Someone with two genuinely different mailboxes still gets two trials, and that needs other signals, such as the phone number, the IP or the email domain.
I built Orisift, which handles the other signup checks; there's a free tier. orisift.com



One trial per inbox in Supabase, enforced by Postgres
Elijah Brown — Wed, 14 Oct 2026 08:24:12 GMT
If your Supabase app gives new accounts free credits, someone will eventually sign up as jane.doe@gmail.com, spend the credits, then come back as janedoe+2@gmail.com, then j.a.n.e.doe@googlemail.com. Supabase Auth sees three different strings and creates three users. Gmail delivers all three to the same inbox.
You don't have to block those signups. The person may simply have forgotten they had an account. What you want is narrower: the second account works, it just doesn't get a second batch of credits.
This post does that entirely inside Postgres, in one migration. No edge function, no extra service. Everything below ran against PostgreSQL 17 with a small stand in for the auth schema, and the test files are listed at the end.
The plan

Turn each email into a claim key, so the three addresses above all become janedoe@gmail.com.

Store one row per key in trial_claims, with a unique index on the key.

In a trigger on auth.users, try to insert the claim. If the insert lands, grant credits. If it hits the index, grant nothing.

Separately, a Before User Created hook in SQL that refuses signups from domains on a throwaway list.


The trigger and the hook do different jobs. The trigger never refuses anyone; it only decides whether credits come with the account. The hook runs earlier and can refuse.
Step 1: the claim key
create or replace function public.email_claim_key(email text)
returns text
language plpgsql
immutable
set search_path = ''
as $$
declare
  addr   text := lower(trim(email));
  at_pos int;
  local  text;
  domain text;
begin
  if addr is null or addr = '' then
    return null;
  end if;
  at_pos := length(addr) - strpos(reverse(addr), '@') + 1;
  if strpos(addr, '@') = 0 then
    return null;
  end if;
  local  := left(addr, at_pos - 1);
  domain := substr(addr, at_pos + 1);

  if domain = 'googlemail.com' then
    domain := 'gmail.com';
  end if;

  -- drop a +tag on every domain
  local := split_part(local, '+', 1);

  -- Gmail ignores dots in the local part
  if domain = 'gmail.com' then
    local := replace(local, '.', '');
  end if;

  if local = '' then
    return null;
  end if;
  return local || '@' || domain;
end;
$$;

The rules, and why each one is there:
Lowercase and trim. Supabase lowercases emails already, but the key should not depend on that.
googlemail.com becomes gmail.com. They are the same mailbox. Google still accepts mail for both.
Drop everything after the first +, on every domain. Gmail, Outlook, iCloud, Fastmail, Proton and most company mail servers treat name+anything as name. A few servers don't, but someone who really has two inboxes that differ only by a +tag is rare, and the cost of a false match here is one account without trial credits, not a lost signup.
Remove dots only for gmail.com. Gmail ignores dots in the local part. Outlook and most others do not, so jane.doe@outlook.com and janedoe@outlook.com stay different keys.
Return null when there's nothing to key on. No @, an empty string, or a local part that was only a tag. Phone signups also land here because email is null. A null key means no claim and no credits, which you can change if phone signups should get a trial.
The function finds the last @ rather than the first, since quoted local parts can legally contain one. It's marked immutable so you can index on it later if you want to look up existing users by key.
Step 2: claims and credits
create table public.trial_claims (
  id         bigint generated always as identity primary key,
  claim_key  text not null,
  user_id    uuid references auth.users (id) on delete set null,
  created_at timestamptz not null default now()
);

create unique index trial_claims_claim_key_idx on public.trial_claims (claim_key);

create table public.credits (
  user_id    uuid primary key references auth.users (id) on delete cascade,
  balance    integer not null default 0 check (balance >= 0),
  updated_at timestamptz not null default now()
);

alter table public.trial_claims enable row level security;
alter table public.credits enable row level security;

create policy "read own credits" on public.credits
  for select to authenticated
  using ((select auth.uid()) = user_id);

Two things in here are deliberate.
The unique index is what enforces the rule. Application code that checks "does a claim exist?" and then inserts has a gap between the check and the insert. Two signups arriving together both see nothing and both get credits. The index closes that gap: the second insert waits for the first transaction and then conflicts. I tested exactly that with two sessions, below.
on delete set null, not cascade. My first version used cascade, and the test showed the obvious hole: delete the account, sign up again with the same address, get fresh credits. With set null the claim outlives the account. The key stays taken and the new user starts at zero.
RLS is on for both tables. Users can read their own balance. Nobody reads trial_claims from the client; the trigger writes it as the function owner.
Step 3: grant on first claim only
create or replace function public.grant_trial_credits()
returns trigger
language plpgsql
security definer
set search_path = ''
as $$
declare
  key     text := public.email_claim_key(new.email);
  claimed bigint;
begin
  if key is not null then
    insert into public.trial_claims (claim_key, user_id)
    values (key, new.id)
    on conflict (claim_key) do nothing
    returning id into claimed;
  end if;

  insert into public.credits (user_id, balance)
  values (new.id, case when claimed is not null then 100 else 0 end);

  return new;
end;
$$;

create trigger on_auth_user_created_grant_credits
  after insert on auth.users
  for each row execute function public.grant_trial_credits();

on conflict (claim_key) do nothing returning id is the whole trick. When the insert lands, returning hands back the new id. When it conflicts, nothing is returned and claimed stays null. One statement, no separate lookup.
The function is security definer because Supabase Auth inserts into auth.users as supabase_auth_admin, which has no rights on your public tables. set search_path = '' plus fully qualified names keeps the definer function from resolving anything unexpected.
Every user still gets a credits row, at zero when the key was taken. Your app code can then always read one row and never has to handle a missing balance.
Step 4: refuse throwaway domains in the hook
A claim key doesn't help with addresses at disposable inbox providers, because each one is a fresh, unrelated address. That check belongs before the user exists, in a Postgres Before User Created hook.
create table public.disposable_domains (
  domain text primary key check (domain = lower(domain))
);

alter table public.disposable_domains enable row level security;

create or replace function public.hook_before_user_created(event jsonb)
returns jsonb
language plpgsql
stable
set search_path = ''
as $$
declare
  email  text := lower(trim(event -> 'user' ->> 'email'));
  email_domain text;
begin
  if email is null or strpos(email, '@') = 0 then
    return '{}'::jsonb;
  end if;

  email_domain := split_part(email, '@', -1);

  if exists (
    select 1
    from public.disposable_domains d
    where email_domain = d.domain
       or email_domain like '%.' || d.domain
  ) then
    return jsonb_build_object(
      'error', jsonb_build_object(
        'http_code', 400,
        'message', 'Please sign up with a permanent email address.'
      )
    );
  end if;

  return '{}'::jsonb;
end;
$$;

grant usage on schema public to supabase_auth_admin;
grant execute on function public.hook_before_user_created(jsonb) to supabase_auth_admin;
grant select on table public.disposable_domains to supabase_auth_admin;
create policy "auth admin reads domains" on public.disposable_domains
  as permissive for select to supabase_auth_admin using (true);
revoke execute on function public.hook_before_user_created(jsonb) from authenticated, anon, public;

Seed the table with whatever list you trust. There are maintained open source lists on GitHub with a few thousand domains; load one with \copy public.disposable_domains from 'domains.txt' and refresh it from time to time.
The like '%.' || d.domain line catches subdomains such as mx.yopmail.com without matching notmailinator.com, because it requires the dot.
The return shape is what Supabase reads. An empty object lets the signup through. An object with error.http_code and error.message stops it, and the message reaches your client as the error on signUp. Then enable it in the dashboard under Authentication, Hooks, Before User Created, choosing Postgres and public.hook_before_user_created.
The grants at the end matter. Supabase calls the hook as supabase_auth_admin, so that role needs execute on the function and select on the domain table (with an RLS policy, since RLS is on). Revoking execute from anon and authenticated keeps the function off your public API.
In a Next.js app
Nothing changes on the client. A normal supabase.auth.signUp either errors with the hook message or succeeds, and then you read the balance:
const { data: credits } = await supabase
  .from("credits")
  .select("balance")
  .single();

if (credits?.balance === 0) {
  // show "your trial was already used on this email" instead of an empty dashboard
}

Telling the person why they have zero credits saves you a support email.
What I tested
I ran all of this against PostgreSQL 17.11 with a stub auth schema (an auth.users table, auth.uid() and the three Supabase roles). Inserts into auth.users ran as supabase_auth_admin, the same role Supabase Auth uses. 28 checks passed, plus a two session race:

Jane.Doe+trial2@Gmail.com, j.a.n.e.d.o.e@googlemail.com and janedoe@gmail.com all produce janedoe@gmail.com.

jane.doe+x@outlook.com becomes jane.doe@outlook.com, dots kept.

Empty, null, no @, and +onlytag@gmail.com give a null key.

Five email signups across two people: the first for each person gets 100 credits, every repeat gets 0, and all six users (one phone only) are still created.

A direct duplicate insert into trial_claims raises unique_violation.

Deleting an account keeps its claim, and signing up again with the same address gets 0.

A signed in user sees one row in credits and none in trial_claims.

The hook refuses mailinator.com, refuses Someone@MX.Yopmail.com, allows gmail.com, allows notmailinator.com, and allows a phone signup.

anon cannot execute the hook function.

Race: one session inserts race.case@gmail.com and holds its transaction for two seconds; a second session inserts racecase+b@googlemail.com meanwhile. The second waits on the index, then gets 0. Final balances: 100 and 0.


Where this stops
This keys on the mailbox, so it stops the cheap repeats: dots, tags, the googlemail spelling, delete and return. It does nothing about someone with ten separate Gmail accounts, and a domain list only knows the domains on it. If you need more than that, card checks at signup or phone confirmation are the next steps, each with its own friction.
Also decide what happens when a user changes their email. The trigger only runs on insert, which is usually what you want: the trial is tied to the address they signed up with.
I built Orisift (https://orisift.com/x?m=post&c=hashnode-supabase-hook&to=%2F), which does this key plus a throwaway domain check in one call.



Stop one person claiming your Node.js free tier twice: Gmail dots, plus tags and googlemail.com
Elijah Brown — Tue, 13 Oct 2026 14:13:42 GMT
If your app gives credits to every new account, at some point one person signs up as jane.doe@gmail.com, then janedoe+2@gmail.com, then Jane.Doe@googlemail.com. All three land in the same inbox. A unique constraint on users.email sees three different strings and hands out three lots of credits.
I don't think it's worth fighting account creation itself. What you can control is who gets the free tier. The pattern is short: build a normalised key from the email, store it in a trial_claims table with a unique index, and insert the claim in the same transaction as the credit grant. If the insert collides, the account still exists; it just doesn't get the credits.
Every snippet below is copied from a small project that I ran under vitest against PostgreSQL 17 and SQLite. The test details are at the end.
The email key
The key is only for matching. Keep sending mail to the address exactly as the person typed it.
Dots. Gmail ignores dots in the part before the @, but only on gmail.com and googlemail.com, which are the same mailbox. Google's help says this doesn't apply to Workspace accounts, so on a company domain hosted by Google, j.smith and jsmith can be two different colleagues. Other providers treat dots as part of the name, so removing dots anywhere else would merge different people.
Plus tags. Gmail and Outlook.com both treat everything after a + as a tag that arrives in the same inbox. On someone's own domain, jo+sales@example.co.uk might be a separate mailbox, or the server may reject it. So strip tags only for providers that document the behaviour, and add to the list only after reading their help pages.
// src/email-key.ts
// Gmail ignores dots in the local part, but only on these two domains.
const DOTS_IGNORED = new Set(["gmail.com", "googlemail.com"]);

// Providers whose own help pages describe +tags. Add one only after reading them.
const PLUS_IS_TAG = new Set(["gmail.com", "googlemail.com", "outlook.com", "hotmail.com"]);

export function emailKey(raw: string): string | null {
  const email = raw.trim().toLowerCase();
  const at = email.lastIndexOf("@");
  if (at <= 0 || at === email.length - 1) return null;

  let local = email.slice(0, at);
  let domain = email.slice(at + 1);

  if (PLUS_IS_TAG.has(domain)) local = local.split("+")[0];
  if (DOTS_IGNORED.has(domain)) {
    local = local.replaceAll(".", "");
    domain = "gmail.com";
  }

  return local ? `${local}@${domain}` : null;
}

emailKey(" J.Doe+trial2@GMAIL.com ") and emailKey("j.doe@googlemail.com") both return jdoe@gmail.com. j.doe+x@outlook.com becomes j.doe@outlook.com. jo+sales@example.co.uk and j.smith@company.com come back unchanged. Junk like +tag@gmail.com, ...@gmail.com or nobody returns null, and null means no trial.
lastIndexOf("@") splits on the last @, which matters for the rare quoted local part that contains one.
Privacy relays stay allowed. Addresses at privaterelay.appleid.com, mozmail.com or duck.com forward to an inbox the person keeps for years, so the normaliser leaves them alone. Someone can create a second relay address, and that's a limit of email keys in general. If it shows up in your data, add a second key such as a confirmed phone number to the same table.
Why a separate trial_claims table
You could put a unique signup_email_key column on users. A separate table has two advantages. The claim outlives the account: if someone deletes their account and signs up again, the row in trial_claims is still there, which is the whole point. (Keep the foreign key as RESTRICT, or drop it if you hard delete users.) And adding another kind of key later, a phone number or a card fingerprint, is just another row with a prefix like phone:+442079460958, with no migration on users.
The unique index is what does the work. Looking first with findFirst or a SELECT and then inserting leaves a gap: two requests can both look at the same moment, both see nothing, and both grant credits. With a unique index, the second insert waits for the first transaction and then fails or does nothing, and that is the whole race handling.
Here is the PostgreSQL schema the tests use:
CREATE TABLE IF NOT EXISTS users (
  id SERIAL PRIMARY KEY,
  email TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS trial_claims (
  id SERIAL PRIMARY KEY,
  claim_key TEXT NOT NULL UNIQUE,
  user_id INTEGER NOT NULL REFERENCES users(id),
  claimed_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE TABLE IF NOT EXISTS credit_grants (
  id SERIAL PRIMARY KEY,
  user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  amount INTEGER NOT NULL,
  reason TEXT NOT NULL
);

node-postgres
INSERT ... ON CONFLICT (claim_key) DO NOTHING RETURNING id returns no row when the key is taken, so there is no exception to catch for the normal case. The grant only runs when a row comes back, inside the same transaction. Note that the whole thing runs on one client from the pool; pool.query("BEGIN") would put each statement on whichever connection is free.
// src/grant-pg.ts
import type { Pool } from "pg";

export const TRIAL_CREDITS = 500;

/** Returns true if credits were granted. Call it after the user row exists. */
export async function grantTrial(pool: Pool, userId: number, key: string | null): Promise {
  if (key === null) return false;
  const client = await pool.connect();
  try {
    await client.query("BEGIN");
    const claim = await client.query(
      `INSERT INTO trial_claims (claim_key, user_id) VALUES ($1, $2)
       ON CONFLICT (claim_key) DO NOTHING
       RETURNING id`,
      [key, userId],
    );
    if (claim.rowCount === 0) {
      // Someone already holds this key. Nothing was written.
      await client.query("ROLLBACK");
      return false;
    }
    await client.query(
      "INSERT INTO credit_grants (user_id, amount, reason) VALUES ($1, $2, $3)",
      [userId, TRIAL_CREDITS, "signup_trial"],
    );
    await client.query("COMMIT");
    return true;
  } catch (err) {
    await client.query("ROLLBACK");
    throw err;
  } finally {
    client.release();
  }
}

Prisma
The models, mapped onto the same tables:
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

datasource db {
  provider = "postgresql"
}

model User {
  id      Int           @id @default(autoincrement())
  email   String
  claims  TrialClaim[]
  grants  CreditGrant[]

  @@map("users")
}

model TrialClaim {
  id        Int      @id @default(autoincrement())
  claimKey  String   @unique @map("claim_key")
  userId    Int      @map("user_id")
  user      User     @relation(fields: [userId], references: [id], onDelete: Restrict)
  claimedAt DateTime @default(now()) @map("claimed_at") @db.Timestamptz

  @@map("trial_claims")
}

model CreditGrant {
  id     Int    @id @default(autoincrement())
  userId Int    @map("user_id")
  user   User   @relation(fields: [userId], references: [id], onDelete: Cascade)
  amount Int
  reason String

  @@map("credit_grants")
}

@unique on claimKey becomes the unique index in the migration. The grant uses an interactive transaction. When the claim insert hits the index, Prisma throws P2002, the transaction rolls back, and neither row is written.
// src/prisma/grant.ts
import { Prisma, PrismaClient } from "../generated/prisma/client";

export const TRIAL_CREDITS = 500;

/** Returns true if credits were granted. Call it after the user is created. */
export async function grantTrial(prisma: PrismaClient, userId: number, key: string | null): Promise {
  if (key === null) return false;
  try {
    await prisma.$transaction(async (tx) => {
      await tx.trialClaim.create({ data: { claimKey: key, userId } });
      await tx.creditGrant.create({ data: { userId, amount: TRIAL_CREDITS, reason: "signup_trial" } });
    });
    return true;
  } catch (err) {
    if (err instanceof Prisma.PrismaClientKnownRequestError && err.code === "P2002") {
      return false; // unique index on claim_key fired; the transaction rolled back
    }
    throw err;
  }
}

This was tested with Prisma 7 and the @prisma/adapter-pg driver adapter. The error code is the same on Prisma 5 and 6 with the built in engine.
Drizzle
The schema:
// src/drizzle/schema.ts
import { integer, pgTable, serial, text, timestamp } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: serial("id").primaryKey(),
  email: text("email").notNull(),
});

export const trialClaims = pgTable("trial_claims", {
  id: serial("id").primaryKey(),
  claimKey: text("claim_key").notNull().unique(),
  userId: integer("user_id").notNull().references(() => users.id),
  claimedAt: timestamp("claimed_at", { withTimezone: true }).notNull().defaultNow(),
});

export const creditGrants = pgTable("credit_grants", {
  id: serial("id").primaryKey(),
  userId: integer("user_id").notNull().references(() => users.id, { onDelete: "cascade" }),
  amount: integer("amount").notNull(),
  reason: text("reason").notNull(),
});

Drizzle has onConflictDoNothing, so the grant reads much like the node-postgres version. Returning false from the callback just ends the transaction normally; there's nothing to roll back because nothing was written.
// src/drizzle/grant.ts
import type { NodePgDatabase } from "drizzle-orm/node-postgres";
import { creditGrants, trialClaims } from "./schema";

export const TRIAL_CREDITS = 500;

/** Returns true if credits were granted. Call it after the user row exists. */
export async function grantTrial(db: NodePgDatabase, userId: number, key: string | null): Promise {
  if (key === null) return false;
  return db.transaction(async (tx) => {
    const claimed = await tx
      .insert(trialClaims)
      .values({ claimKey: key, userId })
      .onConflictDoNothing({ target: trialClaims.claimKey })
      .returning({ id: trialClaims.id });
    if (claimed.length === 0) return false; // already claimed, nothing to grant

    await tx.insert(creditGrants).values({ userId, amount: TRIAL_CREDITS, reason: "signup_trial" });
    return true;
  });
}

better-sqlite3
If you're on SQLite, better-sqlite3's db.transaction() wraps a function, commits when it returns and rolls back when it throws. .immediate() takes the write lock at the start, which avoids a busy error when several connections write at once.
// src/grant-sqlite.ts
import Database from "better-sqlite3";

export const TRIAL_CREDITS = 500;

export const SCHEMA = `
CREATE TABLE IF NOT EXISTS users (
  id INTEGER PRIMARY KEY,
  email TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS trial_claims (
  id INTEGER PRIMARY KEY,
  claim_key TEXT NOT NULL UNIQUE,
  user_id INTEGER NOT NULL REFERENCES users(id),
  claimed_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE IF NOT EXISTS credit_grants (
  id INTEGER PRIMARY KEY,
  user_id INTEGER NOT NULL REFERENCES users(id),
  amount INTEGER NOT NULL,
  reason TEXT NOT NULL
);
`;

export function grantTrial(db: Database.Database, userId: number, key: string | null): boolean {
  if (key === null) return false;
  const insertClaim = db.prepare("INSERT INTO trial_claims (claim_key, user_id) VALUES (?, ?)");
  const insertGrant = db.prepare("INSERT INTO credit_grants (user_id, amount, reason) VALUES (?, ?, ?)");

  // db.transaction() commits when the function returns and rolls back if it throws.
  const claimAndGrant = db.transaction(() => {
    insertClaim.run(key, userId);
    insertGrant.run(userId, TRIAL_CREDITS, "signup_trial");
  });

  try {
    claimAndGrant.immediate();
    return true;
  } catch (err) {
    if (err instanceof Database.SqliteError && err.code === "SQLITE_CONSTRAINT_UNIQUE") {
      return false; // key already claimed, both inserts rolled back
    }
    throw err;
  }
}

SQLite also supports INSERT ... ON CONFLICT DO NOTHING RETURNING, so you can use the node-postgres shape here too if you prefer it. I kept the exception version to show the error code.
A Next.js route handler
The route creates the user first, then tries the grant. A taken key still gets a working account, just with no trial credits, so the person who already had one isn't blocked from signing in on a second address.
// app/api/signup/route.ts
import { pool } from "../../../src/db";
import { emailKey } from "../../../src/email-key";
import { grantTrial } from "../../../src/grant-pg";

export async function POST(request: Request) {
  const body = await request.json().catch(() => null);
  const email = typeof body?.email === "string" ? body.email.trim() : "";
  if (!email.includes("@")) {
    return Response.json({ error: "Please enter an email address." }, { status: 400 });
  }

  // Store the address as typed. The key is only for matching trial claims.
  const { rows } = await pool.query<{ id: number }>(
    "INSERT INTO users (email) VALUES ($1) RETURNING id",
    [email],
  );
  const userId = rows[0].id;
  const trialGranted = await grantTrial(pool, userId, emailKey(email));

  return Response.json({ userId, trialGranted }, { status: 201 });
}

The pool lives in its own module so every request reuses it:
// src/db.ts
import { Pool } from "pg";

export const pool = new Pool({
  connectionString: process.env.DATABASE_URL ?? "postgresql://trial:trial@localhost:5432/trial",
});

If you want the user insert and the claim to commit or fail together, move the INSERT INTO users onto the same client inside grantTrial. I kept them apart here on purpose, because an account without credits is the outcome I wanted when the key is taken.
The tests
The four signups used across the tests are jane.doe@gmail.com, janedoe+2@gmail.com, Jane.Doe@googlemail.com and sam@example.com. Expected result: credits for the first and the last, none for the two in the middle, four accounts either way.
// test/pg.test.ts
test("node-postgres: one trial per key", async () => {
  const results = [];
  for (const email of SIGNUPS) {
    results.push(await grantTrial(pool, await addUser(pool, email), emailKey(email)));
  }
  expect(results).toEqual(EXPECTED);
  expect(await count(pool, "users")).toBe(4);
  expect(await count(pool, "credit_grants")).toBe(2);
  expect(await count(pool, "trial_claims")).toBe(2);
});

The concurrency test is the one I cared about most. It creates eight users whose addresses all normalise to janedoe@gmail.com, then fires all eight grants at once with Promise.all. The pool opens up to ten connections, so these are separate transactions racing on the unique index in Postgres:
// test/pg.test.ts
test("node-postgres: eight concurrent claims, one winner", async () => {
  const emails = Array.from({ length: 8 }, (_, i) => `jane.doe+${i}@gmail.com`);
  const ids = [];
  for (const e of emails) ids.push(await addUser(pool, e));

  const results = await Promise.all(ids.map((id, i) => grantTrial(pool, id, emailKey(emails[i]))));

  expect(results.filter(Boolean)).toHaveLength(1);
  expect(await count(pool, "credit_grants")).toBe(1);
  expect(await count(pool, "trial_claims")).toBe(1);
});

Exactly one call wins and exactly one credit row exists. The same race runs against the Prisma and Drizzle versions, and against the route handler with six simultaneous requests:
// test/route.test.ts
test("route handler: concurrent signups", async () => {
  const responses = await Promise.all(
    Array.from({ length: 6 }, (_, i) => signup(`janedoe+${i}@gmail.com`)),
  );
  const bodies = await Promise.all(responses.map((r) => r.json()));
  expect(responses.every((r) => r.status === 201)).toBe(true);
  expect(bodies.filter((b) => b.trialGranted)).toHaveLength(1);
  expect(await count(pool, "users")).toBe(6);
});

For better-sqlite3, which is synchronous, Promise.all wouldn't race anything, so that test starts eight worker threads, each with its own connection to one database file in WAL mode. They wait on a shared Atomics.wait gate and all call grantTrial when it opens. One gets true, seven get false.
What this won't stop
Someone with a fresh inbox on a new domain gets a fresh free tier. That's fine for most products; the aim is to make repeat claims cost more effort than the credits are worth, not to make them impossible. It also does nothing about throwaway inbox services on their own, so pair it with a domain check at signup if those show up in your data.
Tested with
Node.js 24.21.0, TypeScript 6.0.3, vitest 5.0.4, PostgreSQL 17, pg 8.23.1, Prisma 7.10.0 with @prisma/adapter-pg, drizzle-orm 0.45.4, better-sqlite3 13.0.3 and Next.js 16.4.0 (the route handler is called directly with a Request). 26 tests in 6 files, all passing, and the TypeScript compiler reports no errors.
I built Orisift (https://orisift.com/x?m=post&c=hashnode-node-trial&to=%2F), which does this key plus a throwaway domain check in one call.



Stop one person claiming your Python free tier twice: Gmail dots, plus tags and googlemail.com
Elijah Brown — Tue, 13 Oct 2026 11:07:43 GMT
If your app hands out credits to every new account, sooner or later one person signs up as jane.doe@gmail.com, then janedoe+2@gmail.com, then Jane.Doe@googlemail.com. Every one of those lands in the same inbox. A unique=True on the email field sees three different strings and gives out three lots of credits.
You can't stop people making accounts, and it isn't worth trying very hard. What you can control is who gets the free tier. The pattern here is short: build a normalised key from the email, store it in a trial_claims table with a unique index, and insert the claim in the same transaction as the credit grant. If the insert collides, the account still exists; it just doesn't get the credits.
The code below was run under pytest; the setup is at the end.
The email key
The key is only for matching. Keep sending mail to the address exactly as the person typed it.
Dots. Gmail ignores dots in the part before the @, but only on gmail.com and googlemail.com, which are the same mailbox. Google's help says this doesn't apply to Workspace accounts, so on a company domain hosted by Google, j.smith and jsmith can be two different colleagues. Other providers treat dots as part of the name. Removing dots anywhere else would merge different people.
Plus tags. Gmail and Outlook.com both treat everything after a + as a tag that arrives in the same inbox. On someone's own domain, jo+sales@example.co.uk might be a separate mailbox, or the server may reject it outright. So strip tags only for providers that document the behaviour, and add to the list only after reading their help pages.
# Gmail ignores dots in the local part, but only on these two domains.
DOTS_IGNORED = {"gmail.com", "googlemail.com"}

# Providers whose own help pages describe +tags. Add one only after reading them.
PLUS_IS_TAG = {"gmail.com", "googlemail.com", "outlook.com", "hotmail.com"}


def email_key(raw: str) -> str | None:
    email = raw.strip().lower()
    local, sep, domain = email.rpartition("@")
    if not sep or not local or not domain:
        return None

    if domain in PLUS_IS_TAG:
        local = local.split("+", 1)[0]
    if domain in DOTS_IGNORED:
        local = local.replace(".", "")
        domain = "gmail.com"

    return f"{local}@{domain}" if local else None

email_key(" J.Doe+trial2@GMAIL.com ") and email_key("j.doe@googlemail.com") both return jdoe@gmail.com. j.doe+x@outlook.com becomes j.doe@outlook.com. jo+sales@example.co.uk and j.smith@company.com come back unchanged. Junk like +tag@gmail.com or ...@gmail.com returns None, and None means no trial.
rpartition("@") splits on the last @, which matters for the rare quoted local part that contains one. It also means "nobody" gives an empty separator, which we treat as no key.
Privacy relays stay allowed. Addresses at privaterelay.appleid.com, mozmail.com or duck.com forward to an inbox the person keeps for years, so the normaliser leaves them alone. Someone can generate a second relay address, and that's a limit of email keys in general; if it shows up in your data, add a second key such as a confirmed phone number to the same table.
Why a separate trial_claims table
You could put a unique signup_email_key column on the user model. A separate table has two advantages. First, the claim outlives the account: if someone deletes their account and signs up again, the row in trial_claims is still there, which is the whole point. (Use on_delete=PROTECT or drop the foreign key if you hard delete users.) Second, adding another kind of key later, a phone number or a payment card fingerprint, is just another row with a prefix like phone:+442079460958, with no migration on users.
The unique index is what does the work. Checking first with .exists() and then inserting leaves a gap: two requests can both look at the same moment, both see nothing, and both grant credits. With a unique index, whichever insert commits second gets an IntegrityError, and catching that exception is the whole race handling.
Django
The models:
from django.conf import settings
from django.db import models


class TrialClaim(models.Model):
    claim_key = models.CharField(max_length=320, unique=True)
    user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.PROTECT)
    claimed_at = models.DateTimeField(auto_now_add=True)


class CreditGrant(models.Model):
    user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    amount = models.PositiveIntegerField()
    reason = models.CharField(max_length=50)

unique=True creates the index in the migration that makemigrations writes for you.
The grant:
from django.db import IntegrityError, transaction

from .models import CreditGrant, TrialClaim

TRIAL_CREDITS = 500


def grant_trial(user, key: str | None) -> bool:
    """Returns True if credits were granted. Call it after the user is saved."""
    if key is None:
        return False
    try:
        with transaction.atomic():
            TrialClaim.objects.create(claim_key=key, user=user)
            CreditGrant.objects.create(user=user, amount=TRIAL_CREDITS, reason="signup_trial")
    except IntegrityError:
        # Key already claimed. atomic() rolled back both rows; the account stays.
        return False
    return True

The try sits outside atomic(), and that's deliberate. Django's docs say to catch database errors around an atomic block, not inside it, because after an IntegrityError the transaction is broken until it rolls back. When the block exits with the exception, Django rolls it back, so you never end up with a claim and no credits, or credits and no claim.
If your signup view already runs inside transaction.atomic() (or you have ATOMIC_REQUESTS = True), the inner block becomes a savepoint. A collision rolls back only the claim and the grant, and the new user row survives. There's a test for exactly that below.
Calling it from the signup flow:
user = User.objects.create_user(username=username, email=form.cleaned_data["email"])
if not grant_trial(user, email_key(user.email)):
    # Account created, free tier skipped. Say so plainly on the onboarding screen.
    ...

SQLAlchemy 2.0
Same shape. begin_nested() opens a savepoint, so a collision undoes just the claim and the grant and leaves the rest of the session usable.
from sqlalchemy import ForeignKey, String, func
from sqlalchemy.exc import IntegrityError
from sqlalchemy.orm import DeclarativeBase, Mapped, Session, mapped_column

TRIAL_CREDITS = 500


class Base(DeclarativeBase):
    pass


class User(Base):
    __tablename__ = "users"
    id: Mapped[int] = mapped_column(primary_key=True)
    email: Mapped[str] = mapped_column(String(320))


class TrialClaim(Base):
    __tablename__ = "trial_claims"
    claim_key: Mapped[str] = mapped_column(String(320), primary_key=True)
    user_id: Mapped[int] = mapped_column(ForeignKey("users.id"))
    claimed_at: Mapped[str] = mapped_column(server_default=func.current_timestamp())


class CreditGrant(Base):
    __tablename__ = "credit_grants"
    id: Mapped[int] = mapped_column(primary_key=True)
    user_id: Mapped[int] = mapped_column(ForeignKey("users.id"))
    amount: Mapped[int]
    reason: Mapped[str] = mapped_column(String(50))


def grant_trial(session: Session, user_id: int, key: str | None) -> bool:
    """Returns True if credits were granted. The user row must already be committed."""
    if key is None:
        return False
    try:
        with session.begin_nested():  # SAVEPOINT: a collision undoes only this block
            session.add(TrialClaim(claim_key=key, user_id=user_id))
            session.add(CreditGrant(user_id=user_id, amount=TRIAL_CREDITS, reason="signup_trial"))
            session.flush()
    except IntegrityError:
        return False
    return True

session.flush() inside the block forces the inserts to hit the database while the savepoint is open, so the IntegrityError is raised there and not at some later commit. The caller commits afterwards as usual.
Plain sqlite3
No ORM at all. with conn: commits on success and rolls back on any exception.
import sqlite3

TRIAL_CREDITS = 500

SCHEMA = """
CREATE TABLE IF NOT EXISTS users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS trial_claims (
    claim_key TEXT PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id),
    claimed_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE IF NOT EXISTS credit_grants (
    id INTEGER PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id),
    amount INTEGER NOT NULL,
    reason TEXT NOT NULL
);
"""


def grant_trial(conn: sqlite3.Connection, user_id: int, key: str | None) -> bool:
    """Returns True if credits were granted. Call it after the user row exists."""
    if key is None:
        return False
    try:
        with conn:  # one transaction: commit on success, roll back on exception
            conn.execute(
                "INSERT INTO trial_claims (claim_key, user_id) VALUES (?, ?)",
                (key, user_id),
            )
            conn.execute(
                "INSERT INTO credit_grants (user_id, amount, reason) VALUES (?, ?, ?)",
                (user_id, TRIAL_CREDITS, "signup_trial"),
            )
        return True
    except sqlite3.IntegrityError:
        # Someone already holds this key. Nothing from this block was written.
        return False

On PostgreSQL with psycopg the code is the same apart from %s placeholders, the exception class (psycopg.errors.UniqueViolation, a subclass of IntegrityError) and the timestamp default. If you'd rather not use exceptions for control flow there, INSERT ... ON CONFLICT (claim_key) DO NOTHING RETURNING claim_key returns no row on a collision, and you grant credits only when a row comes back, still inside the same transaction.
The tests
The four signups used across the tests are jane.doe@gmail.com, janedoe+2@gmail.com, Jane.Doe@googlemail.com and sam@example.com. Expected result: credits for the first and the last, none for the two in the middle, four accounts either way.
SIGNUPS = ["jane.doe@gmail.com", "janedoe+2@gmail.com", "Jane.Doe@googlemail.com", "sam@example.com"]
EXPECTED = [True, False, False, True]


def test_django(django_db):
    from django.contrib.auth.models import User
    from trials.models import CreditGrant, TrialClaim
    from trials.services import grant_trial

    results = []
    for i, email in enumerate(SIGNUPS):
        user = User.objects.create_user(username=f"u{i}", email=email)
        results.append(grant_trial(user, email_key(email)))
    assert results == EXPECTED
    assert User.objects.count() == 4
    assert CreditGrant.objects.count() == 2
    assert TrialClaim.objects.count() == 2

The race test is the one I cared about most. It creates eight users whose addresses all normalise to janedoe@gmail.com, then starts eight threads, each with its own sqlite3 connection to a file database, holds them at a threading.Barrier and releases them together:
def test_sqlite3_race(tmp_path):
    db = tmp_path / "race.db"
    setup = sqlite3.connect(db)
    setup.executescript(grant_sqlite.SCHEMA)
    with setup:
        for i in range(8):
            setup.execute("INSERT INTO users (email) VALUES (?)", (f"jane.doe+{i}@gmail.com",))
    barrier = threading.Barrier(8)
    results = []

    def worker(uid):
        conn = sqlite3.connect(db, timeout=10)
        barrier.wait()
        results.append(grant_sqlite.grant_trial(conn, uid, email_key(f"jane.doe+{uid}@gmail.com")))

    threads = [threading.Thread(target=worker, args=(i + 1,)) for i in range(8)]
    [t.start() for t in threads]
    [t.join() for t in threads]
    assert sorted(results) == [False] * 7 + [True]
    assert setup.execute("SELECT count(*) FROM credit_grants").fetchone()[0] == 1

Exactly one thread wins and exactly one credit row exists. SQLite serialises writers, so this shows the logic holds rather than stress testing Postgres, but the unique index behaves the same way there.
The full suite also covers 13 normaliser cases, the same four signups through SQLAlchemy and plain sqlite3, and a Django test where both signups happen inside one outer transaction.atomic(): the second user collides, gets no credits, and both user rows are still there afterwards.
What this won't stop
Someone with a fresh inbox on a new domain gets a fresh free tier. That's fine for most products; the aim is to make repeat claims cost more effort than the credits are worth, not to make them impossible. It also does nothing about throwaway inbox services on their own, so pair it with a domain check at signup if those show up in your data.
Tested with
Python 3.13.5, Django 6.1.2, SQLAlchemy 2.1.4 and pytest 9.1.1, all on SQLite (in memory, plus a temporary file for the threaded test). 18 tests, all passing. Django tables were created with migrate --run-syncdb in a test fixture, so no migration files were generated for this post.
I built Orisift (https://orisift.com/x?m=post&c=hashnode-python-trial&to=%2F), which does this key plus a throwaway domain check in one call.



The SMS bill nobody planned for: when a signup form sends a code to any number typed in
Elijah Brown — Mon, 12 Oct 2026 12:11:16 GMT
If your signup form sends a one-time code by SMS, you have built a button that spends money on behalf of whoever presses it. Most of the time the person pressing it wants to sign up. Sometimes they want the message to be sent, and nothing else.
That second case has a name: SMS pumping. Twilio describes it plainly in its docs: someone uses a phone number field to trigger messages to a range of numbers controlled by a particular mobile network, and takes a share of the revenue those messages generate (Twilio, SMS pumping). Nobody ever enters the code. Your form did its job perfectly, and the bill is the only evidence.
This post is the set of checks I would put in front of any SMS send on a signup form. None of them is clever. The point is that they run before the provider is called, because once the message is sent the money has gone.
What the traffic looks like
Pumping rarely looks like one person hammering one number. The usual signs are:

many sends to numbers that share a long prefix, often in a country you have never had a customer in;
sends spread across many IP addresses, so a per IP limit alone does not catch it;
almost no codes ever entered;
bursts at odd hours, then nothing.

So the defences have to work on the number, the prefix and the country, not only on the person.
Step one: parse to E.164 and refuse impossible numbers
Everything else depends on having one canonical form of the number. Parse what was typed, using the country the form is showing, and turn it into E.164 (+447400123456). If the library says the number cannot exist, stop there. There is no reason to pay to send a code to 12345.
Order matters a little. Check whether the number is possible, then the country, then the reserved ranges, and only then whether it is valid in the numbering plan. That way your logs say why a number was refused, which helps when someone emails support.
Step two: allowlist the countries you serve
If your customers are in the UK, Ireland, North America and Australia, there is no reason for your form to send codes anywhere else. An allowlist is the single most effective change here, because pumping depends on reaching expensive destinations. Twilio says the same thing: disable the countries you do not plan to send to (Twilio, geo permissions).
Do it twice: in your code, so the provider is never called, and in the provider's console, so a bug in your code cannot undo it.
Step three: refuse reserved and fictional ranges
Every numbering plan sets aside numbers for films, adverts and documentation. Nobody can hold them, so a code sent there is wasted, and seeing them at signup usually means test data or someone filling the form in by hand without caring.

North America: 555-0100 to 555-0199 in any area code are reserved as fictitious, non working numbers (NANPA).
UK: Ofcom publishes drama ranges, including 07700 900000 to 900999 for mobiles, 020 7946 0000 to 0999 for London, and 01632 960000 to 960999 (Ofcom).
Australia: ACMA lists geographic ranges such as (02) 5550 xxxx and (02) 7010 xxxx, plus a set of individual 0491 mobile numbers (ACMA, archived page). ACMA lists single mobile numbers, not a block, so match them exactly.

These ranges are small. Blocking them will not stop pumping on its own, but it costs nothing and removes a class of sends that can never succeed.
Step four: rate limit per number, per IP and per prefix
Three counters, each with its own window:

per number: a few codes an hour is plenty for someone who mistyped or lost signal;
per IP: catches the lazy cases;
per prefix: the one that matters for pumping. Take the country code and the next few digits and count sends across all users. Twenty codes in ten minutes to one prefix you have never seen before is worth refusing and alerting on.

Twilio's own guidance is in the same spirit: no more than one message per so many seconds to the same range or prefix, and limits by user, IP or device (Twilio).
The Node version
Tested with Node 20.19.2 and libphonenumber-js 1.13.15. The counters are in memory to keep the logic readable; in production put them in Redis with INCR and EXPIRE.
// sms-guard.mjs: decide whether a signup may send an SMS code to this number.
import { parsePhoneNumberFromString } from 'libphonenumber-js/max'

// Countries you actually serve. Everything else is refused before any send.
const ALLOWED = new Set(['GB', 'US', 'CA', 'AU', 'IE'])

// Ranges set aside for fiction and testing, as E.164 prefixes or patterns.
const RESERVED = [
  /^\+1\d{3}5550(1\d\d)$/,           // NANP 555-0100 to 555-0199, any area code
  /^\+447700900\d{3}$/,              // Ofcom drama mobile 07700 900000 to 900999
  /^\+44(11[3-8]|121|131|141|151|161)4960\d{3}$/, // Ofcom drama, 0113 to 0161
  /^\+442079460\d{3}$/,              // London 020 7946 0000 to 0999
  /^\+441914980\d{3}$/,              // Tyneside 0191 498 0000 to 0999
  /^\+442896496\d{3}$/,              // Northern Ireland 028 9649 6000 to 6999
  /^\+442920180\d{3}$/,              // Cardiff 029 2018 0000 to 0999
  /^\+441632960\d{3}$/,              // 01632 960000 to 960999
  /^\+61[2378](5550|7010)\d{4}$/,    // ACMA geographic (0X) 5550 xxxx and 7010 xxxx
]

// ACMA lists individual mobile numbers for fiction rather than a block.
const ACMA_MOBILE = new Set(['570006','570110','570156','570157','570158','570159','570313','570737',
  '571266','571491','571804','572549','572665','572983','573087','573770','574118','574632',
  '575254','575789','576398','576801','577426','577644','578148','578888','578957','579212',
  '579455','579760'].map((n) => '+61491' + n))

export function checkNumber(input, country) {
  const phone = parsePhoneNumberFromString(String(input), country)
  if (!phone || !phone.isPossible()) return { ok: false, reason: 'impossible' }
  if (!phone.country || !ALLOWED.has(phone.country)) return { ok: false, reason: 'country_not_served' }
  const e164 = phone.number
  if (ACMA_MOBILE.has(e164) || RESERVED.some((re) => re.test(e164))) return { ok: false, reason: 'reserved_range', e164 }
  if (!phone.isValid()) return { ok: false, reason: 'not_in_numbering_plan', e164 }
  return { ok: true, e164 }
}

// Fixed window counters. In production use Redis INCR with EXPIRE; this keeps the logic visible.
export function makeLimiter(now = () => Date.now()) {
  const buckets = new Map()
  return function hit(key, limit, windowMs) {
    const t = now()
    const b = buckets.get(key)
    if (!b || t >= b.reset) { buckets.set(key, { count: 1, reset: t + windowMs }); return true }
    b.count += 1
    return b.count <= limit
  }
}

// Prefix used for burst detection: country code plus the next few digits.
export const prefixOf = (e164, digits = 6) => e164.slice(0, 1 + digits)

export function maySend({ e164, ip }, hit) {
  if (!hit('num:' + e164, 3, 60 * 60_000)) return { ok: false, reason: 'number_limit' }
  if (!hit('ip:' + ip, 5, 60 * 60_000)) return { ok: false, reason: 'ip_limit' }
  if (!hit('pfx:' + prefixOf(e164), 20, 10 * 60_000)) return { ok: false, reason: 'prefix_burst' }
  return { ok: true }
}

A few results from the test run:
(202) 555-0143, US      -> reserved_range
07700 900123, GB        -> reserved_range
020 7946 0958, GB       -> reserved_range
(02) 5550 1234, AU      -> reserved_range
0491 570 156, AU        -> reserved_range
0491 570 160, AU        -> ok, +61491570160
12345, GB               -> impossible
+371 2000 0000          -> country_not_served
07400 123456, GB        -> ok, +447400123456
4th code to one number in an hour   -> number_limit
6th code from one IP in an hour     -> ip_limit
21st code to one prefix in 10 min   -> prefix_burst

The PHP version
Tested with PHP 8.4.26 and giggsey/libphonenumber-for-php 9.0.41. Add the ACMA mobile list from the Node version if you serve Australia.
parse($input, $country);
        } catch (NumberParseException) {
            return ['ok' => false, 'reason' => 'impossible'];
        }
        if ($util->isPossibleNumberWithReason($number) !== ValidationResult::IS_POSSIBLE) {
            return ['ok' => false, 'reason' => 'impossible'];
        }
        // An invalid number has no region, so fall back to the country calling code.
        $region = $util->getRegionCodeForNumber($number)
            ?? $util->getRegionCodeForCountryCode($number->getCountryCode());
        if (! in_array($region, self::ALLOWED, true)) {
            return ['ok' => false, 'reason' => 'country_not_served'];
        }
        $e164 = $util->format($number, PhoneNumberFormat::E164);
        foreach (self::RESERVED as $pattern) {
            if (preg_match($pattern, $e164)) {
                return ['ok' => false, 'reason' => 'reserved_range', 'e164' => $e164];
            }
        }
        if (! $util->isValidNumber($number)) {
            return ['ok' => false, 'reason' => 'not_in_numbering_plan', 'e164' => $e164];
        }

        return ['ok' => true, 'e164' => $e164];
    }

    public static function prefix(string $e164, int $digits = 6): string
    {
        return substr($e164, 0, 1 + $digits);
    }
}

One thing tripped me up while testing: for a number that is not valid in the plan, such as the Ofcom drama mobile range, getRegionCodeForNumber() returns null. If you allowlist on that alone, every reserved number looks like a foreign one. Falling back to the region for the country calling code fixes it. I also used isPossibleNumberWithReason() rather than isPossibleNumber(), because the latter accepts numbers that are only possible when dialled locally, such as 12345.
In Laravel, the three counters map neatly onto RateLimiter::attempt() with keys like sms:num:+447400123456, sms:ip:203.0.113.7 and sms:pfx:+447400. I have not included that code because it is a thin wrapper; the decisions are the part worth testing.
Step five: cap spend at the provider
Your code can have bugs. The provider's spend limit is the backstop that does not.

AWS End User Messaging SMS has an account limit and an optional enforced monthly limit; when you hit it, sending stops until you raise it (AWS). Amazon SNS has an account spend limit too, and its docs note sending stops within minutes of the limit being passed, so a little overspend is possible (AWS SNS).
Twilio has a feature for its one-time code service that looks at your historical traffic and blocks destination prefixes when it sees pumping patterns. Its docs say it covers SMS only, not voice, and lists conditions on which code and protection settings it supports (Twilio). It sits alongside the per country geo permissions mentioned above.

Set the cap low enough that a bad night is annoying rather than serious, and set an alert well below it.
Watch the ratio
The best single number to chart is codes sent against codes entered, per country and per prefix. Normal traffic converts. Pumped traffic does not. If a prefix sends fifty codes and none come back, you do not need anything more sophisticated to know what happened.
Disclosure
I built Orisift, which flags reserved and fictional ranges at signup, among other checks on the phone, email, IP and domain. There is a free checker for the reserved ranges here: reserved phone number checker. Everything above works without it.



Stop one person claiming your Laravel free tier twice: normalising Gmail dots, plus tags and googlemail.com
Elijah Brown — Mon, 12 Oct 2026 11:00:56 GMT
If your Laravel app gives credits or a free tier to every new account, someone will eventually sign up three times: as jane.doe@gmail.com, then janedoe+2@gmail.com, then jane.doe@googlemail.com. All three land in the same inbox. Your unique:users,email rule sees three different strings and hands out three lots of credits.
You can't stop people making accounts, and it isn't worth trying hard. What you can control is who receives the free tier. The approach here stores a normalised copy of the email and the phone on the user, puts a unique index on each, and grants credits only if both keys can be written. A collision still creates the account; it just skips the credits.
The migration
Two nullable, unique columns on users. Nullable matters: a user whose keys collide keeps null, and unique indexes allow many nulls on MySQL, PostgreSQL and SQLite.
string('signup_email_key')->nullable()->unique();
            $table->string('signup_phone_key', 20)->nullable()->unique();
        });
    }

    public function down(): void
    {
        Schema::table('users', function (Blueprint $table) {
            $table->dropUnique(['signup_email_key']);
            $table->dropUnique(['signup_phone_key']);
            $table->dropColumn(['signup_email_key', 'signup_phone_key']);
        });
    }
};

One consequence of keeping the keys on users: if you hard delete a user, their keys go with them and the next signup can claim again. If people can delete their own accounts, use SoftDeletes on the model so the row, and the keys, stay. If you need hard deletes for data protection reasons, move the keys into a separate table that you keep after the account is gone.
The email key
The key is only for matching. Keep sending mail to the address exactly as the person typed it.
Dots. Gmail ignores dots in the part before the @, but only on gmail.com and googlemail.com, which are the same inbox. Google's own help says this does not apply to Gmail for work or school, so on a company domain hosted by Google, j.smith and jsmith can be two different colleagues. Other providers treat dots as part of the name. Removing dots anywhere else would merge different people.
Plus tags. Gmail and Outlook.com both treat everything after a + as a tag that still arrives in the same inbox. On someone's own domain, jo+sales@example.co.uk may be an entirely separate address, or the server may reject it. So strip tags only for providers that document the behaviour, and add to the list only after reading their help pages.
parse($raw, strtoupper($country));
        } catch (NumberParseException) {
            return null;
        }

        return $util->isValidNumber($number)
            ? $util->format($number, PhoneNumberFormat::E164)
            : null;
    }
}

SignupKeys::email(' J.Doe+trial2@GMAIL.com ') and SignupKeys::email('j.doe@googlemail.com') both return jdoe@gmail.com. j.doe+x@outlook.com becomes j.doe@outlook.com. jo+sales@example.co.uk and j.smith@company.com come back unchanged.
Privacy relays stay allowed. Addresses such as abc123@privaterelay.appleid.com (Sign in with Apple), Firefox Relay's mozmail.com or DuckDuckGo's duck.com forward to an inbox the person keeps for years. The normaliser leaves them alone, and they shouldn't be on whatever disposable list you use either. Each relay address is unique, so someone can generate a second one; the phone key is what catches that.
The phone key
The same number turns up as 020 7946 0958, +44 20 7946 0958, 0044 20 7946 0958 or (020) 7946-0958. A string comparison sees four people. giggsey/libphonenumber-for-php, the PHP port of Google's libphonenumber, parses all four with country GB and SignupKeys::phone() returns +442079460958 for each. Inputs like 12345, 0000000000 or call me return null.
Two notes. isValidNumber() checks the number against the numbering plan; it says nothing about whether anyone answers. 020 7946 0xxx is a range Ofcom sets aside for drama, which is why it's safe to print here, and it still counts as valid. More importantly, only use a phone number that has been confirmed with a one-time code before you build the key. Otherwise a new number per signup resets the free tier, and anyone could block a stranger's credits by typing that stranger's number.
Claim the keys and grant credits in one transaction
The unique indexes do the real work. Both keys and the credit row are written inside one transaction. If either key already belongs to another user, the database refuses the update, the transaction rolls back, and no credits are written.
where('id', $userId)->update([
                    'signup_email_key' => $emailKey,
                    'signup_phone_key' => $phoneKey,
                ]);

                DB::table('credit_grants')->insert([
                    'user_id' => $userId,
                    'amount' => self::CREDITS,
                    'reason' => 'signup_trial',
                    'created_at' => now(),
                ]);

                return true;
            });
        } catch (UniqueConstraintViolationException) {
            // Another account already holds one of the keys. The transaction has
            // rolled back, so neither key nor credits were written for this user.
            return false;
        }
    }
}

Call it after the user row exists, for example in your registration action once the phone code has been confirmed:
$granted = GrantTrial::for(
    $user->id,
    SignupKeys::email($request->input('email')),
    SignupKeys::phone($request->input('phone'), $request->input('country')),
);

if (! $granted) {
    // Account created, free tier skipped. Say so plainly in the onboarding screen.
}

Why not check first, then insert? Two requests can both run exists() at the same moment, both see nothing, and both grant credits. The unique index closes that gap: whichever UPDATE commits second gets a unique violation, which Laravel 10 and later raise as Illuminate\Database\UniqueConstraintViolationException. Catching that exception is the whole race handling.
Why DB::transaction and not a bare update? The credit row must not exist without the keys, and the keys must not exist without the credit row. On PostgreSQL there is a second reason: a failed statement aborts the surrounding transaction, so the work has to roll back as a unit. If your registration code already runs inside a transaction, Laravel turns the inner DB::transaction into a savepoint, which rolls back only this part and leaves the new account in place.
If you'd rather keep claims in their own table, the same idea works with DB::table('trial_claims')->insertOrIgnore([...]), which returns the number of rows inserted. Grant credits only when it returns the number of keys you tried to insert, all inside the same transaction.
What this won't stop
Someone with a fresh confirmed phone number and a fresh inbox on a new domain gets a fresh free tier. That's acceptable for most products; the aim is to make repeat claims cost more than the credits are worth, not to make them impossible. It also does nothing about throwaway inbox services on their own; pair it with a domain check at signup if those show up in your data.
Tested with
PHP 8.4.26, giggsey/libphonenumber-for-php 9.0.41, illuminate/database 12.69.3 on SQLite (in memory). The test covered the email and phone normalisers, and the transaction against a table with the same unique columns: the first signup received credits; a second signup with the same Gmail address (dots and a plus tag added, on googlemail.com) and a different number received none; a third with a new address but the same number in international format received none; a fourth with both new received credits. All four accounts were created, two credit rows existed, and the rejected users kept null keys. The migration file above wasn't run through artisan migrate; the test built the same columns with the schema builder.
I built Orisift, which checks the email domain, phone and IP at signup and returns a separate result for each, so your registration code can decide what to do with throwaway domains and unusual numbers: https://orisift.com/x?m=post&c=hashnode-laravel-trial&to=%2F



Privacy aliases are not disposable email addresses
Elijah Brown — Sun, 11 Oct 2026 14:31:43 GMT
A common bit of signup hygiene is a list of disposable email domains: Mailinator, 10 Minute Mail and the thousands of lookalikes that hand out an inbox nobody owns and that disappears within the hour. Blocking those is reasonable. The mistake is letting that list, or a homemade regex, sweep up privacy aliases as well. They look odd, they hide the person's main address, and they come from a domain the person didn't choose, but they behave very differently.
What the common ones look like
Apple Hide My Email. When someone uses Sign in with Apple and chooses to hide their address, Apple creates a unique address at @privaterelay.appleid.com for your app, and it forwards to the address on their Apple Account. Apple's developer documentation says relay addresses end in @privaterelay.appleid.com, @private.icloud.com or @icloud.com. iCloud+ subscribers can also create unique, random Hide My Email addresses for any form, and those forward the same way.
Firefox Relay. Mozilla's masks use the mozmail.com domain (older ones used relay.firefox.com). Premium subscribers get their own subdomain and can make up masks on the spot, such as shop@yourdomain.mozmail.com.
SimpleLogin. Run by Proton these days. It offers several shared alias domains, including aleeas.com and simplelogin.co, and paid users can bring their own custom domain, which you cannot list at all.
DuckDuckGo Email Protection. People get a personal Duck Address such as name@duck.com, and can generate private ones such as amaze-gem-spider@duck.com. Each private address can be switched off on its own.
Fastmail Masked Email. A unique, automatically generated address, created at fastmail.com or at a custom domain the person has set up in their Fastmail account.
Proton Pass. Hide-my-email aliases are randomised addresses that forward to the person's Proton inbox, and paid users can create them on their own domains. Proton's help page doesn't list the shared domains, so I've left them out of the code below. The same page calls these "throwaway" addresses, yet by its own description they keep forwarding until the person disables or deletes them.
How they differ from throwaway inboxes
The useful question isn't "does this address hide something?" but "will the person still be able to receive mail here next month?"

Lifetime. A relay alias lasts until the person turns it off, usually years. A throwaway inbox is gone in minutes or hours.
Ownership. A relay alias belongs to one account holder, who signed in to create it. A throwaway inbox is often readable by anyone who types the same name.
Receiving. Mail sent to a relay alias lands in a long-lived personal inbox. Password resets, receipts and account notices work months later.
Intent. People use aliases precisely because they plan to stay but want to control who can email them, and to switch an address off if it starts getting spam. That is the opposite of someone passing through.

If you block aliases, the people you turn away are the careful ones: those who read privacy settings, pay for iCloud+ or Proton, and use a password manager that offers an alias by default. Sign in with Apple is worse still, because the person may never have typed the address. Apple handed it to you, and rejecting it breaks a login button you offered.
What the CC0 disposable list does
The most widely reused source is the public domain (CC0) disposable-email-domains/disposable-email-domains repository on GitHub. I checked its disposable_email_blocklist.conf on 11 October 2026. It had 9,222 entries, and none of these were among them: privaterelay.appleid.com, private.icloud.com, icloud.com, mozmail.com, relay.firefox.com, aleeas.com, simplelogin.co, duck.com, fastmail.com. mailinator.com is on it, as you would expect.
The repository used to ship an allowlist.conf as well. It was removed on 12 April 2026 (commit 0bccfe3, "remove allowlist and the attached logic"), with the maintainers describing it as an unmaintained list. Just before removal it had 189 entries, including mozmail.com and fastmail.com, but not the Apple, SimpleLogin or DuckDuckGo domains above. So if your code still fetches allowlist.conf, it now gets a 404, and you need your own.
Two more things worth knowing. The blocklist does contain lookalike domains such as domozmail.com and duck2.club, so a substring match on mozmail.com or duck would treat a listed throwaway domain as a relay, or the other way round. And other lists, especially older or hand-maintained ones, do include relay domains. Check whatever list you use before trusting it.
Practical guidance

Keep a small relay allowlist of your own and check it before the blocklist.
Match on the exact domain or a dot-separated suffix (janedoe.mozmail.com ends with .mozmail.com), never by substring.
Treat custom domains as ordinary domains. You can't tell a SimpleLogin custom domain from a small business, and you don't need to.
If you need to recognise the same person across sign-ins, key it on the provider's user ID (Apple's sub claim), not on the email string.
Apple's relay only forwards mail from sending addresses or domains you have registered for Sign in with Apple. Register yours, or your emails to those users will not arrive.
Add the shared domains of any other alias service you see in your own signup data, after checking the provider's documentation.

In Laravel, a rule:
blocklist)) {
            $fail('Please use an address you will still have next month.');
        }
    }

    private static function matches(string $domain, array $list): bool
    {
        foreach ($list as $entry) {
            if ($domain === $entry || str_ends_with($domain, '.' . $entry)) {
                return true;
            }
        }
        return false;
    }
}

Load the blocklist once (from a cached copy of the CC0 file) and bind it in a service provider, then use ['required', 'email:rfc', app(NotThrowawayEmail::class)].
In Node the same idea:
const RELAYS = new Set([
  "privaterelay.appleid.com", "private.icloud.com", "icloud.com",
  "mozmail.com", "relay.firefox.com", "duck.com",
  "aleeas.com", "simplelogin.co", "fastmail.com",
]);

function inList(domain, set) {
  const parts = domain.split(".");
  for (let i = 0; i < parts.length - 1; i++) {
    if (set.has(parts.slice(i).join("."))) return true;
  }
  return false;
}

export function classifyEmailDomain(email, blocklist) {
  const domain = email.slice(email.lastIndexOf("@") + 1).toLowerCase();
  if (inList(domain, RELAYS)) return "relay";
  if (inList(domain, blocklist)) return "throwaway";
  return "ordinary";
}

Review the relay list every few months. Providers add domains, and the cost of a stale entry is a careful person seeing an error.
I built Orisift, which flags domains on known throwaway lists. Relay services aren't something it calls out separately, so I keep a relay allowlist like the one above in front of it. The docs are here: https://orisift.com/x?m=post&c=hashnode-privacy-aliases&to=%2Fdocs



A DNS timeout is not an invalid email address
Elijah Brown — Sun, 11 Oct 2026 14:29:34 GMT
Laravel makes it very easy to check that an email address has a working domain behind it. You add email:rfc,dns to a rule and move on. Most of the time that is fine. The trouble is the small number of times the DNS lookup does not get an answer at all, because the rule treats "I couldn't find out" exactly like "this domain does not exist". On a signup form, that means a person with a perfectly normal address sees "The email field must be a valid email address" because a resolver had a slow second.
This is a look at what the rule does, line by line, and a pattern for treating the three different outcomes differently.
What email:dns does
The rule lives in Illuminate\Validation\Concerns\ValidatesAttributes::validateEmail() (lines 940 to 967 on the 12.x branch). It maps each option to a class from the egulias/email-validator package. The dns option becomes new DNSCheckValidation() (line 954), and all the chosen checks are combined with MultipleValidationWithAnd, so any single failure fails the whole rule.
Everything below was read from Laravel 12.x, egulias/email-validator 4.x and PHP 8.4 on Linux. Older versions may differ in the details.
The interesting part is in DNSCheckValidation (4.x branch):

isValid() takes everything after the last @. If the domain has a single label, or its last label is on the reserved list (test, example, invalid, localhost, local, intranet, internal, private, corp, home, lan), it fails straight away with LocalOrReservedDomain (lines 88 to 95). No DNS query is made. So someone@shop.invalid is rejected without touching the network.

checkDns() converts the domain to ASCII and then walks it from the right. For a@mail.shop.co.uk it tries co.uk, then shop.co.uk, then mail.shop.co.uk, and returns true as soon as one level passes (lines 118 to 136). A side effect worth knowing: anything@made-up-name.gmail.com passes, because gmail.com is checked first and passes.

validateDnsRecords() asks for A and MX records together (DNS_A + DNS_MX, line 148). If that query errors, the result is UnableToGetDNSRecord and the check fails (lines 150 to 153). It then asks for AAAA separately and quietly ignores an error there (lines 157 to 162).

If there are no A, AAAA or MX records at all, it fails with NoDNSRecord (lines 165 to 168).

Each record goes through validateMxRecord(). Non-MX records pass, so a domain with only an A record is accepted, matching the implicit MX fallback in RFC 5321. An MX record whose target is empty or . is a Null MX, and fails with DomainAcceptsNoMail (lines 202 to 205).


The query itself goes through DNSGetRecordWrapper::getRecords(), which calls PHP's dns_get_record() with an error handler that turns any warning into an exception and then into an "error" result.
So what does dns_get_record() do in each case? In php-src (ext/standard/dns.c, PHP 8.4), HOST_NOT_FOUND and NO_DATA are skipped with continue, so NXDOMAIN gives an empty array. TRY_AGAIN raises the warning "A temporary server error occurred." and NO_RECOVERY raises "An unexpected server failure occurred.", and the function returns false. On Linux, where PHP asks the system resolver library, a timeout or a SERVFAIL normally comes back as TRY_AGAIN, so it lands in the first of those branches. Other platforms and resolver set-ups can behave differently, so it is worth testing yours.
Putting it together:



What DNS said
What the rule reports
Rule result



NXDOMAIN
NoDNSRecord
fails


No MX, but an A or AAAA record
accepted
passes


Null MX (0 .)
DomainAcceptsNoMail
fails


SERVFAIL or timeout
UnableToGetDNSRecord
fails


The last row is the problem. Inside egulias the reasons are distinct, but Laravel only sees a boolean, so all three failures produce the same message.
Three different answers
They mean different things and deserve different responses.
The domain does not exist. NXDOMAIN is an authoritative answer. Nobody can receive mail there today. Very often it is a typo, gmial.com or hotmial.co.uk. Ask the person to correct it.
The domain says it takes no mail. A Null MX record, defined in RFC 7505, is the domain owner stating that no mail should be sent there. example.com publishes one. This is also an authoritative answer, and the right response is the same: ask for a different address, ideally saying why.
We couldn't find out. A timeout or SERVFAIL tells you about the path between your server and the domain's name servers, not about the address. Resolvers time out, upstream servers have bad minutes, DNSSEC misconfigurations come and go. Rejecting here turns a temporary problem on your side into a lost signup. Accept the address, mark it as unconfirmed, and check again later.
A Laravel pattern
The plain PHP part needs a lookup that tells the outcomes apart and has a timeout you control. dns_get_record() cannot report the status code, and its timeout comes from the system resolver settings (options timeout: and attempts: in /etc/resolv.conf). One way round both is a DNS over HTTPS JSON endpoint, which returns the DNS status as a number (0 for NOERROR, 2 for SERVFAIL, 3 for NXDOMAIN).
 $r['type'] === 15);
        foreach ($records as $r) {
            if (preg_match('/^0\s+\.$/', trim($r['data']))) return 'accepts_no_mail';
        }
        if ($records !== []) return 'ok';

        $a = self::query($domain, 'A', $timeout);
        if ($a['status'] === null) return 'unknown';
        $aaaa = self::query($domain, 'AAAA', $timeout);
        $addresses = array_filter(
            array_merge($a['answers'], $aaaa['answers']),
            fn ($r) => in_array($r['type'], [1, 28], true)
        );

        return $addresses ? 'ok' : 'does_not_exist';
    }

    private static function query(string $name, string $type, float $timeout): array
    {
        $url = 'https://dns.google/resolve?' . http_build_query(['name' => $name, 'type' => $type]);
        $context = stream_context_create(['http' => [
            'timeout' => $timeout,
            'ignore_errors' => true,
            'header' => "Accept: application/dns-json\r\n",
        ]]);
        $body = @file_get_contents($url, false, $context);
        if ($body === false) {
            return ['status' => null, 'answers' => []];
        }
        $json = json_decode($body, true);

        return ['status' => $json['Status'] ?? null, 'answers' => $json['Answer'] ?? []];
    }
}

Calling MailDomainCheck::classify() from the command line against a few known domains gave:
gmail.com                  ok
example.com                accepts_no_mail
no-such-name-7f3a9q.com    does_not_exist
neverssl.com               ok   (no MX, has an A record)
dnssec-failed.org          unknown
gmail.com, 1 ms timeout    unknown

dnssec-failed.org is deliberately broken, so a validating resolver returns SERVFAIL for it, which makes it a handy test case. If your company already runs its own resolver, swap the HTTPS call for something like Net_DNS2 with a short timeout; the important part is keeping "unknown" separate.
Then a rule that only fails on the two authoritative answers:
 $fail('We could not find the domain :input. Is there a typo?'),
            'accepts_no_mail' => $fail('That domain does not accept email. Please use another address.'),
            default           => null,
        };
    }
}

Use it as ['required', 'email:rfc', new MailDomainAcceptsMail], leaving out dns so the two checks don't disagree. After creating the user, store whether the domain answered and queue a recheck when it didn't:
user->email, '@'));

        if ($result === 'unknown') {
            $this->release($this->backoff[$this->attempts() - 1] ?? 21600);
            return;
        }

        $this->user->forceFill(['email_domain_status' => $result])->save();
    }
}

What you do with a final does_not_exist is a product decision. Usually it is a banner asking the person to update their address, not a deleted account.
Takeaway
Treat DNS results as three answers, not two. "It doesn't exist" and "it takes no mail" are reasons to ask for a correction. "We couldn't tell" is a reason to accept the address and look again later.
I built Orisift, which returns these as separate findings (including which DNS answers it could not get) so a form can choose to continue, ask for a correction or retry. The docs are here: https://orisift.com/x?m=post&c=hashnode-laravel-dns&to=%2Fdocs



Stop free trial reuse at signup: an email key and a phone key in Node
Elijah Brown — Thu, 08 Oct 2026 10:39:40 GMT
If your app gives free credits or a free trial at signup, some people will collect it more than once. The usual route is cheap: sign up again as j.doe+2@gmail.com, then jdoe@googlemail.com, then a throwaway address, sometimes deleting the old account first, with the same phone number each time. Your app sees new people. Your costs see the same one.
You can't stop someone from creating accounts, and you shouldn't try too hard. What you can control is who gets the free credits. This post builds two matching keys, one for the email and one for the phone, records both in one Postgres insert, and grants credits only when both are new. Everything below was run on Node 20 and Postgres 17.
The email key
The key is only for matching. Keep sending mail to the address exactly as the person typed it.
Two rules decide what goes into the key. Gmail ignores dots before the @, but only on gmail.com and googlemail.com. Google's help page says dots do change the address for Gmail used through work or school, so j.smith@company.com and jsmith@company.com can be two colleagues even if Google hosts their mail.
Plus tags need the same care. Gmail and Outlook.com treat everything after a + as a tag, but on a company's own domain jo+sales can be someone else's address. So strip the tag only for providers that document it, and keep a short list you add to after reading their docs.
// email-key.js
// Gmail ignores dots, but only on these two domains.
const DOTS_IGNORED = new Set(['gmail.com', 'googlemail.com'])

// Providers that document +tags as tags. Add one only after reading its docs.
const PLUS_IS_TAG = new Set(['gmail.com', 'googlemail.com', 'outlook.com', 'hotmail.com'])

export function emailKey(raw) {
  const email = String(raw).trim().toLowerCase()
  const at = email.lastIndexOf('@')
  if (at < 1 || at === email.length - 1) return null

  let local = email.slice(0, at)
  let domain = email.slice(at + 1)

  if (PLUS_IS_TAG.has(domain)) local = local.split('+')[0]
  if (DOTS_IGNORED.has(domain)) {
    local = local.replaceAll('.', '')
    domain = 'gmail.com'
  }
  return local ? local + '@' + domain : null
}

That turns " J.Doe+trial2@GMAIL.com " and "j.doe@googlemail.com" into jdoe@gmail.com, and leaves j.doe@outlook.com and jo+sales@example.co.uk as they are.
The phone key
The same number arrives in many shapes: 020 7946 0958, +44 20 7946 0958, 0044 20 7946 0958, (020) 7946-0958. A plain string match treats those as four people. Parse with libphonenumber-js and store the E.164 form:
// phone-key.js
import { parsePhoneNumberFromString } from 'libphonenumber-js'

// country is the ISO code the person picked in your form, e.g. 'GB'
export function phoneKey(input, country) {
  const phone = parsePhoneNumberFromString(String(input), country)
  return phone?.isValid() ? phone.number : null
}

With country GB, all four of those inputs return +442079460958, and input such as 12345, 0000000000 or "call me" returns null. (020 7946 0xxx is a range Ofcom sets aside for drama, so it makes a safe example. It still passes isValid, which is about the numbering plan, not about whether anyone answers.)
One condition matters more than the code: only use a phone number that has been confirmed with a one-time code. If anyone can type any valid number, a new number per signup resets the trial, and someone could block a stranger's trial by typing theirs.
Claim both keys in one insert
Claims live in their own table, apart from the account, so deleting an account doesn't release them. One row per key, with the key as the primary key:
create table public.trial_claims (
  claim_key  text primary key,
  kind       text not null check (kind in ('email', 'phone')),
  user_id    uuid not null,
  claimed_at timestamptz not null default now()
);
alter table public.trial_claims enable row level security;

create function public.claim_trial(p_user uuid, p_email_key text, p_phone_key text, p_credits int)
returns boolean
language sql
begin atomic
  with wanted (claim_key, kind) as (
    values (p_email_key, 'email'), (p_phone_key, 'phone')
  ),
  inserted as (
    insert into public.trial_claims (claim_key, kind, user_id)
    select claim_key, kind, p_user from wanted where claim_key is not null
    on conflict (claim_key) do nothing
    returning claim_key
  ),
  granted as (
    update public.profiles set credits = credits + p_credits
    where id = p_user and (select count(*) from inserted) = 2
    returning id
  )
  select exists (select 1 from granted);
end;

revoke execute on function public.claim_trial(uuid, text, text, int) from public, anon, authenticated;
grant execute on function public.claim_trial(uuid, text, text, int) to service_role;

Row level security is on with no policies, so nothing in the browser can read or write the table. The insert tries both rows and skips any key that already exists. The update adds credits only if the count of inserted rows is 2, and it runs in the same statement, so the claim and the credits succeed or fail together.
The rule "credits only if both rows went in" means any old key loses:

new email, new phone: both rows go in, credits granted
old email, new phone: only the phone row goes in, no credits
new email, old phone: only the email row goes in, no credits
the same user calling again: nothing goes in, no second grant

The partial cases still record the new key. That's deliberate: the new address now belongs to someone who has had a trial, so pairing it with yet another phone later won't work either.
I ran those cases against Postgres 17, plus 50 rounds of three concurrent claims sharing one email. Every round granted credits exactly once, because the primary key makes the second insert wait for the first and then skip.
If you don't collect phone numbers, drop the phone row and compare the count with 1. The function also expects a profiles row for the user, which most Supabase apps create with a trigger on signup.
Two kinds of domain to refuse
A throwaway inbox can receive your confirmation email, so it passes that step. Check the domain against a list instead, and either refuse it at signup or, as in the route further down, create the account without credits. The disposable-email-domains project on GitHub keeps one in disposable_email_blocklist.conf under CC0, so you can ship it in your repo. Pin it to a commit so it only changes when you update it on purpose. The list holds registrable domains, so check each parent of a subdomain too:
// throwaway.js
import { readFileSync } from 'node:fs'

// disposable_email_blocklist.conf from github.com/disposable-email-domains, pinned to a commit
const BLOCKLIST = new Set(
  readFileSync(new URL('./disposable_email_blocklist.conf', import.meta.url), 'utf8')
    .split('\n').map((line) => line.trim().toLowerCase()).filter(Boolean)
)

// The list holds registrable domains, so also check each parent of a subdomain
export function isThrowaway(domain) {
  const labels = domain.toLowerCase().split('.')
  for (let i = 0; i < labels.length - 1; i++) {
    if (BLOCKLIST.has(labels.slice(i).join('.'))) return true
  }
  return false
}

A domain with a Null MX record (RFC 7505) says it accepts no email at all, so your confirmation email has nowhere to go. Check it on the server when the address is submitted, and return a field error the person can fix while they're still on the page:
// null-mx.js
import { resolveMx } from 'node:dns/promises'

// RFC 7505: one MX record, preference 0, exchange "." (Node may report it as '')
export async function hasNullMx(domain, resolve = resolveMx) {
  const records = await resolve(domain).catch(() => [])
  return records.length === 1 && records[0].priority === 0 &&
    ['', '.'].includes(records[0].exchange)
}

The resolver is a parameter so you can test it without live DNS. I covered the other DNS cases (no MX record at all, and lookups that time out) in an earlier post on waitlist bots.
Create the account, skip the credits
When a key matches, don't refuse the signup. The person may be a returning customer, a colleague on a shared phone, or someone who deleted an account by mistake. Create the account, skip the credits, and say so plainly. A clear sentence is kinder than a vague error, and someone farming trials gets nothing from it.
Where this runs in Supabase
In a Supabase app, run the claim in a server route or an Edge Function, never in the browser. The anon key ships to every visitor, so anything the client can call, a script can call too. That's why the SQL above revokes execute from anon and authenticated, and only the service role can call it:
// claim-trial.js: server only (route handler, Express, Edge Function)
import { createClient } from '@supabase/supabase-js'
import { emailKey } from './email-key.js'
import { phoneKey } from './phone-key.js'
import { isThrowaway } from './throwaway.js'

const admin = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_SERVICE_ROLE_KEY)
const TRIAL_CREDITS = 100

export async function claimTrial(accessToken) {
  const { data, error } = await admin.auth.getUser(accessToken)
  const user = data?.user
  if (error || !user?.email_confirmed_at || !user.phone_confirmed_at) {
    return { status: 403, message: 'Confirm your email address and phone number first.' }
  }

  const domain = user.email.split('@').pop().toLowerCase()
  if (isThrowaway(domain)) {
    return { status: 200, credits: 0, message: 'Your account is ready. Trial credits need an email address you will keep, so change it in settings to claim them.' }
  }

  const { data: granted, error: rpcError } = await admin.rpc('claim_trial', {
    p_user: user.id,
    p_email_key: emailKey(user.email),
    p_phone_key: phoneKey('+' + user.phone.replace(/^\+/, '')),
    p_credits: TRIAL_CREDITS,
  })
  if (rpcError) throw rpcError

  if (granted) return { status: 200, credits: TRIAL_CREDITS, message: 'Your account is ready, with your trial credits.' }
  return { status: 200, credits: 0, message: 'Your account is ready. This email address or phone number has already had a free trial, so this account starts without trial credits.' }
}

Call it once, after the person has confirmed their email and phone. In an Edge Function the same logic works with npm: imports and keys from Deno.env, and the blocklist can be bundled as a module instead of read from disk.
What this won't stop
It won't stop one person with several genuine Gmail accounts and several confirmed phone numbers. Each of those is a new key, and nothing here can tell that they belong to the same person. It raises the cost of a second trial from a few seconds to a new inbox and a new SIM, which is usually enough for a free tier.
Lowercasing the whole address is a practical choice too. The part before the @ is case sensitive in theory, but almost no provider treats it that way.
I built Orisift
I built Orisift to screen the phone, email domain, IP and domain parts of a signup, with a separate result for each field, through POST /v1/lookup or POST /v1/signup. It flags known throwaway domains, Null MX and reserved phone ranges such as the drama range above. It does not tell you the carrier, line type or whether a number is VoIP, whether a mailbox exists or mail will arrive, whether an IP is a VPN, and it does no KYC.
There's a free checker on the homepage with no account needed: https://orisift.com/x?m=post&c=hashnode-trial-reuse&to=%2F
Signing up gives 500 free credits once, and no card is needed. The Node SDK, @orisift/sdk, includes a Supabase Auth helper: https://orisift.com/x?m=post&c=hashnode-trial-reuse-sdk&to=%2Fdocs%23sdk



Half your waitlist is bots? Three server-side checks in Node
Elijah Brown — Wed, 07 Oct 2026 11:49:08 GMT
You open your waitlist table and something is off. Rows arrive in bursts, half of them are the same Gmail address with different dots and plus tags, and a fair number sit on domains that don't exist. If you're about to quote that number to anyone, it's worth cleaning up first.
This post covers three checks in plain Node and Postgres, plus a rate limit. Every snippet below runs on Node 20 with ES modules ("type": "module" in package.json).
Why the checks have to live on the server
Your form is not the gate. A signup form is HTML and JavaScript that ends in a request to an endpoint, and anyone can send that request without the form. Bots usually do exactly that: they read the network tab once, then post straight to /api/waitlist in a loop. Client-side validation, hidden honeypot fields and disabled buttons never run.
So whatever decides "this counts" has to run in the handler that receives the request. Everything below does.
1. Normalise the email before the unique check
A unique constraint on the raw email doesn't stop much. J.Doe+7@GMAIL.com, jdoe@gmail.com and j.doe@googlemail.com are three different strings and, for Gmail, one inbox. So store a second column, a matching key, and put the unique index on that.
The rules:

trim whitespace and lowercase the whole address
drop everything from the first + in the part before the @
remove dots only for gmail.com and googlemail.com (other providers treat dots as significant, so a.b@outlook.com and ab@outlook.com stay different)
map googlemail.com to gmail.com

// email-key.js
export function emailKey(raw) {
  const email = String(raw).trim().toLowerCase()
  const at = email.lastIndexOf('@')
  if (at < 1 || at === email.length - 1) return null

  let local = email.slice(0, at).split('+')[0]
  let domain = email.slice(at + 1)

  if (domain === 'googlemail.com') domain = 'gmail.com'
  if (domain === 'gmail.com') local = local.replace(/\./g, '')

  return local ? `${local}@${domain}` : null
}

Test it with the built-in runner (node --test):
// email-key.test.js
import { test } from 'node:test'
import assert from 'node:assert/strict'
import { emailKey } from './email-key.js'

test('emailKey', () => {
  assert.equal(emailKey(' J.Doe+7@GMAIL.com '), 'jdoe@gmail.com')
  assert.equal(emailKey('j.doe@googlemail.com'), 'jdoe@gmail.com')
  assert.equal(emailKey('a.b+x@outlook.com'), 'a.b@outlook.com')
  assert.equal(emailKey('+x@gmail.com'), null)
  assert.equal(emailKey('no-at-sign'), null)
})

Use the key only for matching. Keep the address as typed for sending, because that's what the person gave you.
-- schema.sql
create table waitlist (
  id           bigint generated always as identity primary key,
  email        text not null,   -- as typed, used for sending
  email_key    text not null,   -- from emailKey(), used for matching
  status       text not null default 'pending'
               check (status in ('pending', 'confirmed')),
  token_hash   text,
  created_at   timestamptz not null default now(),
  confirmed_at timestamptz
);

create unique index waitlist_email_key_idx on waitlist (email_key);

Now j.doe+7 stops counting twice, and the database enforces it even if two requests race.
2. Drop domains that can't take mail
If the domain has no mail setup, a confirmation email has nowhere to go, so there's no point storing the row. node:dns/promises gives you everything you need, but there are three cases to get right:

ENOTFOUND: the domain doesn't exist (NXDOMAIN). Reject.
ENODATA: the domain exists but has no MX records. This is not an instant reject. RFC 5321 says a sender falls back to the domain's A or AAAA record in that case, so check those before deciding.
Null MX (RFC 7505): a single MX record with preference 0 and exchange . is the domain owner saying "this domain accepts no mail". Node may give you the root exchange as an empty string rather than ., so check for both.

Anything else (timeouts, SERVFAIL, refused connections) means DNS is having a bad moment, not that the address is bad. Fail open: let the signup through and let the confirmation step deal with it. A DNS outage shouldn't lock out genuine people.
// mail-domain.js
import { Resolver } from 'node:dns/promises'

const defaultResolver = new Resolver({ timeout: 1500, tries: 2 })
const settle = (p) => p.then((records) => ({ records }), (err) => ({ code: err.code }))

function withTimeout(promise, ms) {
  let timer
  const timeout = new Promise((resolve) => {
    timer = setTimeout(() => resolve('unknown'), ms)
  })
  return Promise.race([promise, timeout]).finally(() => clearTimeout(timer))
}

// Returns 'ok', 'no-domain', 'no-mail' or 'unknown' (DNS trouble: let it through)
export function mailDomain(domain, dns = defaultResolver, ms = 3000) {
  return withTimeout(check(domain, dns), ms)
}

async function check(domain, dns) {
  const mx = await settle(dns.resolveMx(domain))

  if (mx.records?.length) {
    const [first] = mx.records
    const nullMx = mx.records.length === 1 && first.priority === 0 &&
      (first.exchange === '' || first.exchange === '.')
    return nullMx ? 'no-mail' : 'ok'
  }
  if (mx.code === 'ENOTFOUND') return 'no-domain'
  if (mx.code && mx.code !== 'ENODATA') return 'unknown'

  // No MX records: RFC 5321 falls back to the address records
  const [a, aaaa] = await Promise.all([settle(dns.resolve4(domain)), settle(dns.resolve6(domain))])
  if (a.records?.length || aaaa.records?.length) return 'ok'
  const gone = (r) => r.records || ['ENODATA', 'ENOTFOUND'].includes(r.code)
  return gone(a) && gone(aaaa) ? 'no-mail' : 'unknown'
}

The Resolver options cap each query, and withTimeout caps the whole check, so a slow name server costs you at most three seconds before the signup goes through.
You don't need a live domain to test each branch. Pass a fake resolver:
// mail-domain.test.js
import { test } from 'node:test'
import assert from 'node:assert/strict'
import { mailDomain } from './mail-domain.js'

const fail = (code) => () => Promise.reject(Object.assign(new Error(code), { code }))
const ok = (records) => () => Promise.resolve(records)
const fake = (mx, a = fail('ENODATA'), aaaa = fail('ENODATA')) =>
  ({ resolveMx: mx, resolve4: a, resolve6: aaaa })

test('mailDomain', async () => {
  assert.equal(await mailDomain('x', fake(ok([{ exchange: 'mx.x', priority: 10 }]))), 'ok')
  assert.equal(await mailDomain('x', fake(ok([{ exchange: '', priority: 0 }]))), 'no-mail')
  assert.equal(await mailDomain('x', fake(ok([{ exchange: '.', priority: 0 }]))), 'no-mail')
  assert.equal(await mailDomain('x', fake(fail('ENOTFOUND'))), 'no-domain')
  assert.equal(await mailDomain('x', fake(fail('ENODATA'), ok(['192.0.2.1']))), 'ok')
  assert.equal(await mailDomain('x', fake(fail('ENODATA'))), 'no-mail')
  assert.equal(await mailDomain('x', fake(fail('ESERVFAIL'))), 'unknown')
  const hang = () => new Promise(() => {})
  assert.equal(await mailDomain('x', fake(hang), 50), 'unknown')
})

This only tells you about the domain. It says nothing about the part before the @, which is what step 3 is for.
3. Only count confirmed entries
Bots rarely open an inbox. So every new row starts as pending, you email a one-time link, and the row only flips to confirmed when someone clicks it. Your waitlist number is the confirmed count, nothing else.
Here is the whole handler, with the rate limit from the next section first in line. It takes any client with a query(sql, params) method that returns { rows }, such as a pg Pool.
// waitlist.js
import { randomBytes, createHash } from 'node:crypto'
import { emailKey } from './email-key.js'
import { mailDomain } from './mail-domain.js'
import { allow } from './rate-limit.js'

const sha256 = (s) => createHash('sha256').update(String(s)).digest('hex')

export async function joinWaitlist({ email, ip }, db, sendLink) {
  if (!allow(ip)) return { status: 429 }
  const key = emailKey(email)
  if (!key) return { status: 400 }
  const domainStatus = await mailDomain(key.split('@')[1])
  if (domainStatus === 'no-domain' || domainStatus === 'no-mail') return { status: 400 }

  const token = randomBytes(32).toString('base64url')
  const { rows } = await db.query(
    `insert into waitlist (email, email_key, token_hash) values ($1, $2, $3)
     on conflict (email_key) do update
       set email = excluded.email, token_hash = excluded.token_hash, created_at = now()
       where waitlist.status = 'pending'
     returning id`,
    [email.trim(), key, sha256(token)])
  if (rows.length) await sendLink(email.trim(), token)
  return { status: 202 } // same answer for new, resent and already confirmed
}

export async function confirmEntry(token, db) {
  const { rows } = await db.query(
    `update waitlist set status = 'confirmed', confirmed_at = now(), token_hash = null
     where token_hash = $1 and status = 'pending'
       and created_at > now() - interval '7 days'
     returning id`,
    [sha256(token)])
  return rows.length === 1
}

A few details worth keeping:

Only a hash of the token is stored, so a leaked table can't be used to confirm entries.
Signing up again while pending stores the new spelling, sends a fresh link to it and resets the clock. Signing up again once confirmed changes nothing.
The response is the same either way, so the endpoint doesn't tell anyone which emails are already on the list.

Then expire the leftovers on a schedule, and count only what's confirmed:
-- maintenance.sql
delete from waitlist
where status = 'pending' and created_at < now() - interval '7 days';

select count(*) as waitlist_size from waitlist where status = 'confirmed';

Pick the number of days that suits you. Seven is a reasonable start.
4. A per-IP rate limit
A script that can't fake confirmations can still fill your pending table and your email sending quota. A simple per-IP cap in front of everything helps:
// rate-limit.js
const hits = new Map()

export function allow(ip, limit = 5, windowMs = 60 * 60 * 1000, now = Date.now()) {
  const entry = hits.get(ip)
  if (!entry || now - entry.start >= windowMs) {
    hits.set(ip, { start: now, count: 1 })
    return true
  }
  entry.count += 1
  return entry.count <= limit
}

Three notes. This Map lives in one process, so on several instances or serverless functions, keep the counter in Redis or a Postgres table instead. Read the client IP from your proxy's trusted header, not whatever the request claims. And for IPv6, count per /64 rather than per address, since one connection usually gets a whole range.
Putting it together
On the server, in this order: rate limit, normalise, check the domain, store as pending, count only confirmed. None of it needs a third-party service, and all of it runs where a script posting straight to your endpoint can't skip it.
I built Orisift
I built Orisift because I kept writing these checks for every project. It runs the domain checks (mail setup and a throwaway domain list) plus phone and IP screening in one call, through POST /v1/lookup or POST /v1/signup, and @orisift/sdk includes a Supabase Auth helper. The homepage has a free checker, three previews a day with no account: https://orisift.com/x?m=post&c=hashnode-waitlist-bots&to=%2F
Signing up gives 500 free credits once, and there's no card to enter.



Your AI-built app's signup is open to anyone who calls the API
Elijah Brown — Wed, 07 Oct 2026 08:27:22 GMT
If you built your app with Lovable, Bolt or Cursor on Supabase, your signup form is a suggestion. The form runs in the browser, and so do the Supabase URL and the anon (or publishable) key it uses. Anyone with the developer tools open can copy both and call Supabase Auth directly, skipping your invite code, terms checkbox and anything else the form enforces.
That is how Supabase is designed, and it is fine as long as the rules that matter live on the server. Steps 1 to 5 below need nothing but Supabase and an afternoon.
1. Sign up without your UI
Run this with Node, using the values from your built app:
import { createClient } from "@supabase/supabase-js";

// Both values ship in your app's JavaScript bundle.
const supabase = createClient("https://YOUR-PROJECT.supabase.co", "YOUR-ANON-OR-PUBLISHABLE-KEY");

const { data, error } = await supabase.auth.signUp({
  email: "Your.Name+test1@gmail.com",
  password: "a-long-throwaway-password",
  options: { data: { plan: "pro", credits: 100000 } },
});
console.log(error ?? data.user?.user_metadata);

If that creates a user, everything your form checks is optional. Look at user_metadata too: it holds whatever the caller sent, so if any code reads a plan or credits from it, the caller sets their own. Keep anything that grants access in a table only your server writes, or in app_metadata, which clients cannot change.
2. Check Row Level Security with a second account
Create accounts A and B. Signed in as B, try to read A's rows, update A's rows, and update your own credits or plan column. Repeat for every table the app touches.
The usual gap in generated code is not a missing policy. It is "users can update their own profile" on a table that also holds credits, so the owner can write any column in their row. Move those columns to a table with no client write policy, or revoke table-level update and grant it back only on the columns people may edit.
3. Normalise emails and phones on the server
To spot a repeat signup you need one canonical form of each contact detail. For email: trim and lowercase, drop everything from a + in the local part, and for gmail.com and googlemail.com remove the dots and treat both domains as one. Use the result only for matching; keep sending mail to the address as typed.
create or replace function public.normalise_email(raw text)
returns text language sql immutable as $$
  select case when dom in ('gmail.com', 'googlemail.com')
    then replace(loc, '.', '') || '@gmail.com'
    else loc || '@' || dom end
  from (select split_part(split_part(e, '@', 1), '+', 1) as loc,
               split_part(e, '@', 2) as dom
        from (select lower(trim(raw)) as e) a) b
$$;

Stripping plus tags on every domain is a judgement call.
For phones, parse to E.164 with libphonenumber-js in a server function, using the country the person selected:
import { parsePhoneNumberFromString } from "libphonenumber-js";

const parsed = parsePhoneNumberFromString("020 7946 0958", "GB");
const phoneKey = parsed?.isValid() ? parsed.number : null; // "+442079460958"

4. Tie free credits to the contact detail, not the account
If every new account gets free credits, deleting an account and signing up again is a refill. Record the claim against the normalised email, and the E.164 phone if you collect one, in a table clients cannot touch:
create table public.trial_claims (
  claim_key text primary key,  -- normalised email or E.164 phone
  user_id uuid not null,
  claimed_at timestamptz not null default now()
);
alter table public.trial_claims enable row level security;  -- no client policies

Grant credits only from server code: insert the keys with on conflict (claim_key) do nothing, and add credits only when a row was inserted. Deleting an account leaves the claim behind, which is the point, so mention it in your privacy notice.
5. Turn on captcha and review rate limits
Supabase Auth supports hCaptcha and Cloudflare Turnstile. Enable it in the Auth settings (under Bot and Abuse Protection at the time of writing) and pass captchaToken in the options of signUp. The step 1 script should then fail without a token.
Then set sign-up limits under Authentication > Rate Limits for the traffic you expect. If signups go through your own server, read the IP forwarding section, or every request counts against your server's address.
Captcha raises the cost of a script. It does not stop one person signing up by hand twenty times; steps 3 and 4 handle that.
6. Move the checks into a Before User Created hook
Steps 3 and 4 only hold if nothing can skip them. Supabase's Before User Created hook runs before the user row exists, whether the signup came from your form, a script or OAuth. It can be a Postgres function or an HTTP endpoint, chosen under Authentication > Hooks.
A Postgres version that refuses a second account for the same normalised email. It keeps one row per normalised email in a table you own, with the email as the primary key, so the check is an index lookup instead of a scan of auth.users (a Postgres hook has two seconds to finish). It also handles two signups for the same address arriving at once: the second waits for the first to commit, then is refused.
-- One row per normalised email. The primary key does the duplicate check.
create table public.signup_keys (
  email_key text primary key,  -- public.normalise_email(email)
  created_at timestamptz not null default now()
);
alter table public.signup_keys enable row level security;
revoke all on public.signup_keys from anon, authenticated, public;

-- The hook runs as supabase_auth_admin, which does not bypass RLS.
grant usage on schema public to supabase_auth_admin;
grant insert on public.signup_keys to supabase_auth_admin;
create policy "auth adds signup keys" on public.signup_keys
  for insert to supabase_auth_admin with check (true);

create or replace function public.hook_before_user_created(event jsonb)
returns jsonb language plpgsql as $$
declare
  added int;
begin
  -- Nothing to check for phone-only signups.
  if coalesce(event->'user'->>'email', '') = '' then
    return '{}'::jsonb;
  end if;

  -- A second signup for the same key waits here until the first commits.
  insert into public.signup_keys (email_key)
  values (public.normalise_email(event->'user'->>'email'))
  on conflict do nothing;
  get diagnostics added = row_count;

  if added = 0 then
    return jsonb_build_object('error', jsonb_build_object('http_code', 400,
      'message', 'Please sign in, or use a different email address.'));
  end if;
  return '{}'::jsonb;
end $$;

grant execute on function public.normalise_email to supabase_auth_admin;
grant execute on function public.hook_before_user_created to supabase_auth_admin;
revoke execute on function public.hook_before_user_created from authenticated, anon, public;

-- Add keys for existing accounts. Safe to rerun after you switch the hook on.
insert into public.signup_keys (email_key)
select public.normalise_email(email) from auth.users
where email <> ''
on conflict do nothing;

Supabase Auth runs the hook as supabase_auth_admin, which does not bypass Row Level Security, so it needs the grants and the insert policy above. The last insert adds keys for the accounts you already have. Run it again after you switch the hook on, to cover anyone who signed up in between.
Rerun the step 1 script with Your.Name+test2@gmail.com and it should be refused.
A key stays behind when an account is deleted, and also when a signup fails after the hook has run, for example if the confirmation email could not be sent. That person is then asked to sign in to an account that does not exist, so clear the key in the SQL editor with delete from public.signup_keys where email_key = public.normalise_email('their@email.com');. Their trial_claims row from step 4 stays, so coming back does not refill their free credits.
Thanks to Mike Dabydeen, who pointed out in the comments that my first version of this hook scanned every user and let two simultaneous signups through.
One option for the HTTP hook: Orisift
I built Orisift, so weigh this accordingly. It checks the email, phone and IP on a signup and returns the evidence, a recommended action, and what it could not establish. The @orisift/sdk package has a Supabase helper that answers the HTTP hook. I covered its settings in Screening Supabase signups before the user is created, so here is just the shape:
import { createBeforeUserCreatedHandler } from "@orisift/sdk/supabase";
import { decideSignup, EXAMPLE_ENFORCEMENT, type EnforcementPolicy, type ScreeningLike } from "@orisift/sdk/enforcement";

// Refuse when the person can fix what they typed.
const policy: EnforcementPolicy = {
  ...EXAMPLE_ENFORCEMENT,
  map: { ...EXAMPLE_ENFORCEMENT.map, ask_to_correct: "block" },
};

const handle = createBeforeUserCreatedHandler({
  apiKey: process.env.ORISIFT_API_KEY!,
  hookSecret: process.env.SUPABASE_HOOK_SECRET!, // v1,whsec_...
  policy: "contact_standard",
  decide: (screening) => decideSignup(screening as ScreeningLike, policy),
  denyOn: ["block"],
  onUnavailable: "allow", // required, no default
  dedupe: { mode: "single-process" },
  onUnavailableEvent: (e) => console.warn("signup not screened", e.reason),
});

export const POST = (request: Request) => handle(request);

onUnavailable has no default because letting people in when screening is unavailable is your decision, not the library's. dedupe is required too; the earlier tutorial explains the modes. The SDK is built for Node, so host it on a Node route, not an Edge Function. Supabase runs one Before User Created hook, Postgres or HTTP, so if you pick this one the duplicate email check above does not run. Keep the step 4 claim check either way, so a repeat signup still gets no free credits.
No credits are charged when a screening establishes no evidence; one that establishes something, including a conclusive negative, is charged. New accounts get 500 credits once on signup, no card required. The SDK docs cover the rest, or try a check on the homepage first.
A prompt for Lovable or Cursor
Paste this to apply steps 3 to 6:
My app uses Supabase Auth. Make these changes server-side only, and show me each SQL migration before applying it.

1. Create a SQL function public.normalise_email(text) that trims, lowercases, removes everything from "+" in the local part, and for gmail.com and googlemail.com removes dots and uses gmail.com. Use it only for matching; keep storing and emailing the address as typed.
2. If the app collects phone numbers, normalise them to E.164 with libphonenumber-js in a server function, using the country the user selected.
3. Create public.trial_claims (claim_key text primary key, user_id uuid, claimed_at timestamptz) with RLS enabled and no client policies. Grant free credits only from server code, by inserting the normalised email and phone with ON CONFLICT DO NOTHING, and only when a row was inserted. Never read plan, credits or roles from user_metadata.
4. Create public.signup_keys (email_key text primary key, created_at timestamptz) with RLS enabled and no client policies, and fill it with the normalised email of every existing auth.users row using ON CONFLICT DO NOTHING. Then create a Postgres function public.hook_before_user_created(event jsonb) for Supabase's Before User Created hook. It must not query auth.users. If the event has no email, return {}. Otherwise insert the normalised email into signup_keys with ON CONFLICT DO NOTHING (no column list, so the hook needs no select access) and return {"error":{"http_code":400,"message":"Please sign in, or use a different email address."}} when no row was inserted, and {} otherwise. The hook runs as supabase_auth_admin, which does not bypass RLS: grant it usage on schema public, insert on signup_keys, an insert policy on signup_keys, and execute on both functions. Revoke execute on the hook from authenticated, anon and public, and revoke all on signup_keys from authenticated, anon and public.
5. List the dashboard settings I must change by hand: Authentication > Hooks, captcha and rate limits.

Then run the step 1 script again. If it still creates an account your form would have refused, a rule is still living on the client.



Screening Supabase signups before the user is created
Elijah Brown — Tue, 06 Oct 2026 11:30:38 GMT
Most signup forms check the shape of what people type and stop there. That catches typos, but not a well formed address at a known throwaway email provider, or a phone number that is valid on paper but sits in a range set aside for fiction.
Take 020 7946 0958. It passes libphonenumber's validity check as a UK fixed line number. It is also inside the London range Ofcom sets aside for TV and radio drama, so it can't be allocated to a communications provider's customers. NANPA reserves 555-0100 to 555-0199 as fictitious numbers. A format check accepts both, because the format is fine.
Timing matters too. A database trigger or post-signup webhook runs after the user exists, so you end up deleting accounts rather than declining signups.
The Before User Created hook
Supabase Auth has a hook for this. Before User Created runs before the user row exists, so a refused signup never creates a user. It can be a Postgres function or an HTTP endpoint, chosen under Authentication > Hooks. An HTTP hook receives a signed request with the user's email or phone and metadata that can include the IP address, and your response decides whether the user is created.
Two details matter more than they look.
The refusal shape. Supabase's documentation describes returning a 4xx status with an error object. When I tested that against a real project, the signup was blocked but the client got an opaque 500, "Invalid payload sent to hook", and my message never arrived. What worked was HTTP 200 with a nested error:
{ "error": { "http_code": 400, "message": "..." } }

That blocked the signup and passed my message through as a 400. A 200 with error as a plain string blocked nothing. If you write your own hook, test the refusal against a real project.
The time budget. Supabase gives the whole invocation 5 seconds, including its own retries, and a hook that doesn't answer in time fails the signup. Letting people through when your check is slow means answering 200 quickly, not timing out quietly.
Setting up the handler
I wrote a handler for this in the Orisift Node SDK. It checks the Standard Webhooks signature, sends the email, phone and IP to Orisift's signup screening endpoint in one request, and answers Supabase in the shape above.
npm install @orisift/sdk

import { createBeforeUserCreatedHandler } from "@orisift/sdk/supabase";

const handle = createBeforeUserCreatedHandler({
  apiKey: process.env.ORISIFT_API_KEY!,
  // Supabase's hook secret, exactly as given: v1,whsec_
  hookSecret: process.env.SUPABASE_HOOK_SECRET!,
  onUnavailable: "allow",
  dedupe: { mode: "single-process" },
  decide: toDecision, // your function: the screening in, a ScreeningDecision out
  denyOn: ["block"],
  onDecision: (e) => console.log("screened", e.screeningId, e.decision.enforcement, e.creditsCharged),
  onUnavailableEvent: (e) => console.warn("not screened", e.reason, e.applied, e.elapsedMs),
});

handle takes a standard Request and returns a Response, so your hook route passes the request in and returns the result.
decide is yours. It receives the screening and returns a decision whose enforcement is one of these:
export type Enforcement = "allow" | "challenge" | "review_queue" | "block" | "fix_request";

denyOn lists which of those refuse the signup. It has no default either.
onUnavailable has no default
Sometimes a screening won't produce a decision: a wrong key, no credits left, a rate limit, a timeout, an error on Orisift's side, or your own decide throwing. Then you either let the signup through unscreened or refuse it.
onUnavailable must be "allow" or "deny", and there is no default. A default would be the library deciding whether your product accepts people it could not screen. That is your call.
Either way, the signup is never recorded as screened, and onUnavailableEvent gets the specific reason (timeout, auth_failed, insufficient_credits and so on), so an outage doesn't look like a quiet week. With "allow" and no onUnavailableEvent, a warning naming the reason goes to the console, at most once per reason per minute. With "deny", the person sees your unavailableMessage or a default asking them to try again shortly, never error detail.
The dedupe setting
In testing, one signup attempt produced four deliveries, each with a new webhook id, metadata.uuid and user.id. Screen each delivery separately and you can pay four times.
dedupe is required and has four modes:

"attempt": you supply attemptId, returning the same value for every delivery of one attempt, such as a request id passed through user_metadata. Return null when there is none, and that delivery is screened and billed on its own.
"shared": bounded deduplication over storage you provide, via a store with an atomic claim(key, candidate, ttlMs) such as Redis SET NX PX or Postgres INSERT ... ON CONFLICT DO NOTHING.
"single-process": the same in memory, correct only while one process handles every delivery.
"none": every delivery is screened and charged.

The bounded modes use a windowMs that defaults to two minutes; the longest retry sequence observed was 11.8 seconds. The trade runs both ways: separate attempts with identical details inside the window share one screening, and a retry after it is a new screening. If the shared store fails, the default onStoreFailure: "unavailable" makes no screening request and applies your onUnavailable choice. "screen" screens anyway and accepts duplicate charges.
A 2.5 second deadline inside 5 seconds
The handler budgets from Supabase's 5 seconds. Minus 1 second of margin for the network and Supabase's overhead, the handler has 4. Minus 1.5 seconds of headroom to answer after a slow call, the screening call gets 2.5. Of those figures, only the 2.5 seconds is an armed timer.
screenTimeoutMs can lower it, not raise it: anything above 2,500 ms is capped. The handler makes one attempt and never retries, because a retry inside a budget that already contains Supabase's retries is how a slow hook becomes one that never answers. A timeout arrives as reason timeout and follows your onUnavailable choice.
Bad configuration fails at construction
The handler refuses to construct without apiKey, without hookSecret, or without onUnavailable set to "allow" or "deny". Since 1.3.0 it also throws when dedupe is missing, when {mode: "attempt"} has no attemptId function, when {mode: "shared"} has no store with claim(), or when the mode isn't one of the four.
That last group used to construct and then fail on every request. With onUnavailable: "allow", every signup was allowed with nothing screened, returning HTTP 200 in about 12 ms, which looks exactly like working software. A process that won't start is easier to notice. On plain JavaScript, check your dedupe option before upgrading.
What to do with findings
Once decide has returned, you have three moves.
Block. Put the enforcement in denyOn. No user is created and the person sees your message.
Ask the person to correct it. Also a refusal, but the message says what to change. By default it is the first end user reason in the decision, falling back to "We could not accept those contact details. Please use a different email address." Pass denyMessage to write your own. Reasons meant for you as the integrator never reach the form. A corrected submission is a different request and is screened again (in "attempt" mode, with a new attempt id, because the same id with a changed request is refused with a 409).
Allow and log. Leave the enforcement out of denyOn. onDecision fires with the decision, screeningId, creditsCharged and the dedupe fields, so you can follow up after the account exists, for example on a challenge or review_queue outcome.
A signup with no email, phone or IP is allowed without a screening, because refusing on absent evidence is the wrong default.
Trying it
You can try checks on the Orisift homepage, 3 a day with no account, and a new account starts with 500 credits. A screening that establishes no evidence costs nothing, and a partial one can be charged. Replaying a matching request returns the original screening at no charge.
Disclosure
I built Orisift, so read the above with that in mind. The SDK docs are here: https://orisift.com/x?m=post&c=hashnode-supabase-tutorial&to=%2Fdocs%23sdk
Until the Supabase guide is in the docs, the setup details and the reasoning behind each choice are in the handler source: https://github.com/orisift/orisift-node/blob/main/src/integrations/supabase.ts

What DNS said	What the rule reports	Rule result
NXDOMAIN	`NoDNSRecord`	fails
No MX, but an A or AAAA record	accepted	passes
Null MX (`0 .`)	`DomainAcceptsNoMail`	fails
SERVFAIL or timeout	`UnableToGetDNSRecord`	fails