Email scanners were confirming our users' accounts before they clicked

Yaroslav — Wed, 28 Oct 2026 11:25:52 +0000

Our sign-up emails contain a link. You click it, your account is confirmed, you land in the app. That's the whole feature, and for a while it was failing in a way that looked like three different bugs.

It was one. The email was being opened by a robot before the person got to it.

The symptom

Some people clicked the confirmation link and got an error. Not always, and not for everyone. When the error showed up it said the link had expired or was invalid, although the email was a few minutes old.

The stack is Next.js (App Router), Supabase Auth and Resend for email. The default Supabase confirmation link points straight at its /auth/v1/verify endpoint, which verifies the token on any GET request. Keep that sentence in mind.

Three fixes that fixed nothing

We went after what we could see, one thing at a time:

An error that arrived in a URL fragment, which the server never sees, so the app showed nothing useful for it.
People landing on the wrong screen after confirming.
A raw, unfriendly error message.

Each of those was a real problem and each fix was reasonable. The links still failed. All three were treating the symptom. None of them touched whatever was using up the token.

The evidence that mattered

The thing that broke the case open was a timestamp. The account's confirmed_at was filled in about two minutes after we sent the email, and nobody had clicked anything. We confirmed this against a real Outlook mailbox: send a sign-up email, do not open it, watch the row.

So something opened the link on its own. Mail systems scan links in incoming messages for security, which means they fetch the URL and follow it. If the URL verifies the token on a plain GET, the scanner has just verified the account. By the time the person clicks, the single-use token is gone and they get otp_expired.

The error message was telling the truth. It just wasn't describing what we thought it was.

The fix: wait for a real click

Any token delivered by email has to land on a page of your own, and it must be redeemed only by a real user gesture. Not on load. Not in an effect. Not by a form that submits itself.

A scanner can fetch that page and even render it. It doesn't press the button. So our confirmation link now points at our own page, which shows a button, and only the click calls the server.

A simplified sketch of the pattern (not our production code):

// The email links to /auth/confirm?token_hash=...&type=email
// This page does NOT verify anything on load.
"use client"

import { confirmToken } from "./actions"

export function ConfirmInterstitial({ tokenHash, type, email }: Props) {
  return (
    <button onClick={() => confirmToken({ tokenHash, type, email })}>
      Confirm my email
    </button>
  )
}

// actions.ts
"use server"

export async function confirmToken({ tokenHash, type, email }: Input) {
  const supabase = await createClient()
  const { error } = await supabase.auth.verifyOtp({ token_hash: tokenHash, type })
  // ...
}

The email template also must not point at /auth/v1/verify any more, since that endpoint treats any GET as a verification.

A second trap on the way

verifyOtp returns the same otp_expired for a garbage token and for a once-valid token on an account that is already confirmed. So someone who clicks twice, or whose scanner got there first, sees an error even though their account is fine. For sign-up links we added a small check that asks whether the account is already confirmed, and shows "Your email is already confirmed" instead of an error. Password reset and email change don't have that in-between state, so they handle failure as a plain error.

What I'd tell myself earlier

Diagnose from timestamps and state, not from the wording of the error screen. We spent four attempts fixing what the screen described. The row in the database already said what had happened.

What I haven't verified

I confirmed this against an Outlook mailbox. Other providers and security tools may behave the same way, and probably some do, but I haven't tested them, so I'm not going to say which. I also haven't counted how many people were affected.

Disclosure: I'm the founder of Sesly, a small CRM for solo coaches. This is how our own sign-up flow works.

DEV Community: Yaroslav