[GH-ISSUE #3742] Configurable Email-Address Change Verification Flow #18338

New Issue

GiteaMirror · 2026-04-15T16:46:13-05:00

GiteaMirror commented

2026-04-15 16:46:13 -05:00

Originally created by @steinitz on GitHub (Aug 1, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3742

Originally assigned to: @ping-maxwell on GitHub.

Is this suited for github?

Yes, this is suited for github

Currently, when users change their email address in Better Auth, the system automatically sends two verification emails:

A verification email to the OLD email address (via sendVerificationEmail)
A verification email to the NEW email address (via changeEmail.sendChangeEmailVerification)

This dual-verification approach creates significant real-world problems:

User Impact

Blocked email changes: Users who no longer have access to their old email address cannot complete the verification process and must contact support for manual email changes
Support burden: Organizations must handle support tickets for what should be a self-service user action
Confusing experience: Users receive two verification emails and may not understand why both are necessary
Security concerns: Users may ignore legitimate verification emails thinking they're duplicates

Developer Impact

Fragile workarounds required: Developers must implement URL-based detection (request?.url.includes('/profile')) to prevent unwanted verification emails
Undocumented coupling: The relationship between signup and email change verification flows is not clearly documented
Limited customization: No built-in way to control when old email verification is sent
Testing difficulties: Email verification flows are hard to test, making these issues harder to discover

Describe the solution you'd like

Primary Feature: `sendOldEmailVerification` Option

Add a new configuration option sendOldEmailVerification (default: true for backward compatibility) that allows developers to control whether verification emails are sent to the old email address during email changes:

export const auth = betterAuth({
  emailAndPassword: {
    enabled: true,
    requireEmailVerification: true
  },
  emailVerification: {
    sendOldEmailVerification: false, // NEW OPTION - prevents old email verification
    sendVerificationEmail: async ({ user, url }, request) => {
      // Would only be called for actual signups when sendOldEmailVerification: false
      console.log("Sending signup verification email");
      await sendCustomEmail(user.email, url);
    },
    sendChangeEmailVerification: async ({ user, newEmail, url }, request) => {
      // Always called for email changes - this is the primary customization point
      console.log("Sending email change verification");
      await sendCustomEmail(newEmail, url);
    }
  }
});

Current Workaround (Fragile)

Developers currently must implement URL-based detection to achieve similar behavior:

sendVerificationEmail: async ({ user, url }, request) => {
  // Workaround: Check URL to detect email change flow
  const isEmailChange = request?.url.includes('/profile')
  if (!isEmailChange) {
    // Only send verification email for actual signups, not email changes
    await sendCustomEmail(user.email, url);
  }
}

Secondary Improvements

Context Detection: Provide a built-in way to detect email change vs signup contexts without URL inspection
Clear Documentation: Document the email change flow, including when each email is sent and how to customize the behavior
Better Debugging: Add context information to email handlers to make flow identification easier
Migration Path: Provide clear guidance for existing applications that may rely on the current dual-email behavior

Describe alternatives you've considered

Alternative 1: Always Single Email

Pros: Simpler user experience
Cons: Breaking change for applications that rely on old email verification

Alternative 2: Configuration at Call Time

Pros: Maximum flexibility per email change
Cons: More complex API, harder to configure consistently

Alternative 3: Role-Based Configuration

Pros: Different behavior for different user types
Cons: Adds complexity without addressing the core use case

Additional context

Real-World Use Cases for Configurable Verification

Consumer applications: Users frequently lose access to old email addresses (work changes, expired accounts, etc.)
Internal tools: Old email verification adds unnecessary friction for authenticated users
Migration scenarios: Importing users from other systems where old emails may be invalid
Self-service portals: Authenticated users should be trusted to change their email without dual verification
Support reduction: Eliminate support tickets for users who can't access old email addresses

Current Behavior Analysis

Both sendVerificationEmail and sendChangeEmailVerification are called during email changes
The sendOnSignUp: false setting does NOT prevent email change verification (contrary to expectations)
sendChangeEmailVerification works correctly and is the primary customization point for new email verification
The coupling between signup and email change flows is undocumented and counterintuitive

Backward Compatibility Strategy

Default sendOldEmailVerification: true maintains current dual-email behavior
Existing applications continue working without changes
Migration is opt-in and controlled by developers
No breaking changes to existing APIs

Implementation Considerations

Should work seamlessly with existing changeEmail.sendChangeEmailVerification
Must eliminate the need for URL-based workarounds: request?.url.includes('/profile')
Should provide clear context to email handlers about the verification type
Consider adding a context parameter to email handlers: { context: 'signup' | 'email-change' }

Expected Benefits

Reduced support burden: Users can change emails without manual intervention
Better UX: Clear, single-purpose verification emails
Cleaner code: No need for fragile URL-based workarounds
Flexible security: Organizations can choose appropriate verification levels
Easier testing: More predictable email verification behavior

This feature would significantly improve both developer experience and user experience for email address changes while maintaining full backward compatibility for existing applications.

Originally created by @steinitz on GitHub (Aug 1, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3742 Originally assigned to: @ping-maxwell on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Currently, when users change their email address in Better Auth, the system automatically sends two verification emails: 1. A verification email to the OLD email address (via `sendVerificationEmail`) 2. A verification email to the NEW email address (via `changeEmail.sendChangeEmailVerification`) This dual-verification approach creates significant real-world problems: ### User Impact - **Blocked email changes**: Users who no longer have access to their old email address cannot complete the verification process and must contact support for manual email changes - **Support burden**: Organizations must handle support tickets for what should be a self-service user action - **Confusing experience**: Users receive two verification emails and may not understand why both are necessary - **Security concerns**: Users may ignore legitimate verification emails thinking they're duplicates ### Developer Impact - **Fragile workarounds required**: Developers must implement URL-based detection (`request?.url.includes('/profile')`) to prevent unwanted verification emails - **Undocumented coupling**: The relationship between signup and email change verification flows is not clearly documented - **Limited customization**: No built-in way to control when old email verification is sent - **Testing difficulties**: Email verification flows are hard to test, making these issues harder to discover ### Describe the solution you'd like ### Primary Feature: `sendOldEmailVerification` Option Add a new configuration option `sendOldEmailVerification` (default: `true` for backward compatibility) that allows developers to control whether verification emails are sent to the old email address during email changes: ```javascript export const auth = betterAuth({ emailAndPassword: { enabled: true, requireEmailVerification: true }, emailVerification: { sendOldEmailVerification: false, // NEW OPTION - prevents old email verification sendVerificationEmail: async ({ user, url }, request) => { // Would only be called for actual signups when sendOldEmailVerification: false console.log("Sending signup verification email"); await sendCustomEmail(user.email, url); }, sendChangeEmailVerification: async ({ user, newEmail, url }, request) => { // Always called for email changes - this is the primary customization point console.log("Sending email change verification"); await sendCustomEmail(newEmail, url); } } }); ``` ### Current Workaround (Fragile) Developers currently must implement URL-based detection to achieve similar behavior: ```javascript sendVerificationEmail: async ({ user, url }, request) => { // Workaround: Check URL to detect email change flow const isEmailChange = request?.url.includes('/profile') if (!isEmailChange) { // Only send verification email for actual signups, not email changes await sendCustomEmail(user.email, url); } } ``` ### Secondary Improvements 1. **Context Detection**: Provide a built-in way to detect email change vs signup contexts without URL inspection 2. **Clear Documentation**: Document the email change flow, including when each email is sent and how to customize the behavior 3. **Better Debugging**: Add context information to email handlers to make flow identification easier 4. **Migration Path**: Provide clear guidance for existing applications that may rely on the current dual-email behavior ### Describe alternatives you've considered ### Alternative 1: Always Single Email - **Pros**: Simpler user experience - **Cons**: Breaking change for applications that rely on old email verification ### Alternative 2: Configuration at Call Time - **Pros**: Maximum flexibility per email change - **Cons**: More complex API, harder to configure consistently ### Alternative 3: Role-Based Configuration - **Pros**: Different behavior for different user types - **Cons**: Adds complexity without addressing the core use case ### Additional context ### Real-World Use Cases for Configurable Verification - **Consumer applications**: Users frequently lose access to old email addresses (work changes, expired accounts, etc.) - **Internal tools**: Old email verification adds unnecessary friction for authenticated users - **Migration scenarios**: Importing users from other systems where old emails may be invalid - **Self-service portals**: Authenticated users should be trusted to change their email without dual verification - **Support reduction**: Eliminate support tickets for users who can't access old email addresses ### Current Behavior Analysis - Both `sendVerificationEmail` and `sendChangeEmailVerification` are called during email changes - The `sendOnSignUp: false` setting does NOT prevent email change verification (contrary to expectations) - `sendChangeEmailVerification` works correctly and is the primary customization point for new email verification - The coupling between signup and email change flows is undocumented and counterintuitive ### Backward Compatibility Strategy - Default `sendOldEmailVerification: true` maintains current dual-email behavior - Existing applications continue working without changes - Migration is opt-in and controlled by developers - No breaking changes to existing APIs ### Implementation Considerations - Should work seamlessly with existing `changeEmail.sendChangeEmailVerification` - Must eliminate the need for URL-based workarounds: `request?.url.includes('/profile')` - Should provide clear context to email handlers about the verification type - Consider adding a `context` parameter to email handlers: `{ context: 'signup' | 'email-change' }` ### Expected Benefits - **Reduced support burden**: Users can change emails without manual intervention - **Better UX**: Clear, single-purpose verification emails - **Cleaner code**: No need for fragile URL-based workarounds - **Flexible security**: Organizations can choose appropriate verification levels - **Easier testing**: More predictable email verification behavior This feature would significantly improve both developer experience and user experience for email address changes while maintaining full backward compatibility for existing applications.

GiteaMirror added the awaiting external contributor help wanted credentials labels 2026-04-15 16:46:13 -05:00

GiteaMirror commented

2026-04-15 16:46:14 -05:00

@dosubot[bot] commented on GitHub (Aug 1, 2025):

Hi @steinitz! I'm Dosu and I’m helping the better-auth team.

Your feature request is not currently supported in Better Auth. There is no built-in sendOldEmailVerification option or similar configuration to control whether verification emails are sent to the old email address during email changes. The email verification and change email handlers (sendVerificationEmail and sendChangeEmailVerification) do not receive an explicit context parameter to distinguish between signup and email change flows, so developers often rely on workarounds like inspecting the request URL or token payload to infer context, which is fragile and undocumented [code reference].

Recent code and documentation clarify how these handlers are invoked, but there is no migration guide or official documentation for customizing or suppressing dual-verification emails during email changes. The current flow is determined by which handler is called, and there is no granular configuration for suppressing old email verification [code reference].

Until a feature like sendOldEmailVerification is implemented, the only workaround is to add custom logic in your sendVerificationEmail handler to detect and suppress unwanted emails, typically by inspecting the request or token. This is a known pain point and your proposal for explicit configuration and context would address a real gap in the current API.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub (Aug 1, 2025):  Hi @steinitz! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team.  Your feature request is not currently supported in Better Auth. There is no built-in sendOldEmailVerification option or similar configuration to control whether verification emails are sent to the old email address during email changes. The email verification and change email handlers (sendVerificationEmail and sendChangeEmailVerification) do not receive an explicit context parameter to distinguish between signup and email change flows, so developers often rely on workarounds like inspecting the request URL or token payload to infer context, which is fragile and undocumented [[code reference](https://github.com/better-auth/better-auth/blob/7fa90f8d4da552ce343f2a5edd84de03d53540d1/packages/better-auth/src/types/options.ts)]. Recent code and documentation clarify how these handlers are invoked, but there is no migration guide or official documentation for customizing or suppressing dual-verification emails during email changes. The current flow is determined by which handler is called, and there is no granular configuration for suppressing old email verification [[code reference](https://github.com/better-auth/better-auth/blob/7fa90f8d4da552ce343f2a5edd84de03d53540d1/packages/better-auth/src/api/routes/update-user.ts)]. Until a feature like sendOldEmailVerification is implemented, the only workaround is to add custom logic in your sendVerificationEmail handler to detect and suppress unwanted emails, typically by inspecting the request or token. This is a known pain point and your proposal for explicit configuration and context would address a real gap in the current API.  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/8b9127be-eb9b-4600-8dcd-1c0a333b9e9f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/8b9127be-eb9b-4600-8dcd-1c0a333b9e9f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/8b9127be-eb9b-4600-8dcd-1c0a333b9e9f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/8b9127be-eb9b-4600-8dcd-1c0a333b9e9f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/8b9127be-eb9b-4600-8dcd-1c0a333b9e9f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/8b9127be-eb9b-4600-8dcd-1c0a333b9e9f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/8b9127be-eb9b-4600-8dcd-1c0a333b9e9f?feedback_type=other)</sup>  [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3742)

GiteaMirror commented

2026-04-15 16:46:15 -05:00

@himself65 commented on GitHub (Aug 1, 2025):

for a real world practice, the reason of sendVerificationEmail is the account get hacked and avoid you lost the account by just switching the email address from hacker. So IMO, verify from old email is important in general.

I think we shouldn't provide an explicit field to skip this. But you defenitely can call verifyEmail inside sendVerificationEmail to flip the emailVerified value on database

export const auth = betterAuth({
  emailAndPassword: {
    enabled: true,
    requireEmailVerification: true,
  },
  emailVerification: {
    async sendVerificationEmail({ user, url, token }) {
      // auto verification, this could be dangerous
      await auth.api.verifyEmail({
        query: {
          token,
        },
      });
    },
  },
});

nit: I think we could let user customize own verify method, not just only email, maybe phone number in the future?

@himself65 commented on GitHub (Aug 1, 2025): for a real world practice, the reason of `sendVerificationEmail` is the account get hacked and avoid you lost the account by just switching the email address from hacker. So IMO, verify from old email is important in general. I think we shouldn't provide an explicit field to skip this. But you defenitely can call `verifyEmail` inside `sendVerificationEmail` to flip the `emailVerified` value on database ```ts export const auth = betterAuth({ emailAndPassword: { enabled: true, requireEmailVerification: true, }, emailVerification: { async sendVerificationEmail({ user, url, token }) { // auto verification, this could be dangerous await auth.api.verifyEmail({ query: { token, }, }); }, }, }); ``` nit: I think we could let user customize own verify method, not just only email, maybe phone number in the future?

GiteaMirror commented

2026-04-15 16:46:16 -05:00

@frectonz commented on GitHub (Sep 2, 2025):

@steinitz I looked into the changeEmail implementation but it seems like there is no case in which two emails get sent to change an email. You can look at the implementation here.

There are basically two cases

If the user’s current email is unverified, the email is updated immediately and (optionally) a verification email is sent to the new address.
If the user’s current email is verified, the system does not update immediately but sends a change-verification email instead.

@frectonz commented on GitHub (Sep 2, 2025): @steinitz I looked into the `changeEmail` implementation but it seems like there is no case in which two emails get sent to change an email. You can look at the implementation [here](https://github.com/better-auth/better-auth/blob/74e94c72f01d3345eed36b5b4a1e2071e3c8761d/packages/better-auth/src/api/routes/update-user.ts#L649). There are basically two cases - If the user’s current email is unverified, the email is updated immediately and (optionally) a verification email is sent to the new address. - If the user’s current email is verified, the system does not update immediately but sends a change-verification email instead.

GiteaMirror commented

2026-04-15 16:46:17 -05:00

@steinitz commented on GitHub (Sep 2, 2025):

@frectonz Thanks for looking into this, I think...

I can confirm that I've seen two emails during my early development of the app. Unless the code has changed recently you will easily reproduce this. As indicated above and elsewhere it's a well-known feature, added intentionally.

I've managed to hack a workaround but it's fragile.

Honestly, I'd prefer not to think about this further. I've spent enough time working around it, thinking about it, burning AI tokens, asking questions, complicating my E2E testing and raising this detailed issue.

@steinitz commented on GitHub (Sep 2, 2025): @frectonz Thanks for looking into this, I think... I can confirm that I've seen two emails during my early development of the app. Unless the code has changed recently you will easily reproduce this. As indicated above and elsewhere it's a well-known feature, added intentionally. I've managed to hack a workaround but it's fragile. Honestly, I'd prefer not to think about this further. I've spent enough time working around it, thinking about it, burning AI tokens, asking questions, complicating my E2E testing and raising this detailed issue.

GiteaMirror commented

2026-04-15 16:46:19 -05:00

@Cali93 commented on GitHub (Sep 18, 2025):

I can confirm that when an existing user with a verified email changes their email, they will receive 2 emails:

One triggered by sendChangeEmailVerification
One triggered by sendVerificationEmail after the user successfully changed their email

@Cali93 commented on GitHub (Sep 18, 2025): I can confirm that when an existing user with a verified email changes their email, they will receive 2 emails: - One triggered by `sendChangeEmailVerification` - One triggered by `sendVerificationEmail` after the user successfully changed their email

GiteaMirror commented

2026-04-15 16:46:20 -05:00

@ixartz commented on GitHub (Oct 13, 2025):

@himself65

"is the account get hacked and avoid you lost the account by just switching the email address from hacker. So IMO, verify from old email is important in general."

It would be great to verify with password instead of verify from old email. Like for changing password, the users need to enter his old password. So to change his email, he needs to verify the password.

If the password is not enough, we can add MFA.

One problem with verifying with the old email is that the user can lose access to his old email, so he won't be able to change it.

@ixartz commented on GitHub (Oct 13, 2025): @himself65 "is the account get hacked and avoid you lost the account by just switching the email address from hacker. So IMO, verify from old email is important in general." It would be great to verify with password instead of verify from old email. Like for changing password, the users need to enter his old password. So to change his email, he needs to verify the password. If the password is not enough, we can add MFA. One problem with verifying with the old email is that the user can lose access to his old email, so he won't be able to change it.

GiteaMirror commented

2026-04-15 16:46:20 -05:00

@dosubot[bot] commented on GitHub (Jan 12, 2026):

Hi, @steinitz. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

You requested a configurable option sendOldEmailVerification to disable sending verification emails to the old email during email changes.
Currently, no built-in option exists; workarounds rely on fragile custom logic in sendVerificationEmail handlers.
Discussion highlighted the security rationale for verifying the old email to prevent hijacking, with alternatives like password verification or MFA suggested.
You acknowledged the pain point and have implemented a fragile workaround but prefer an official configurable solution.

Next Steps:

Please let me know if this issue is still relevant to the latest version of better-auth by commenting here to keep the discussion open.
Otherwise, this issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 12, 2026): Hi, @steinitz. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You requested a configurable option `sendOldEmailVerification` to disable sending verification emails to the old email during email changes. - Currently, no built-in option exists; workarounds rely on fragile custom logic in `sendVerificationEmail` handlers. - Discussion highlighted the security rationale for verifying the old email to prevent hijacking, with alternatives like password verification or MFA suggested. - You acknowledged the pain point and have implemented a fragile workaround but prefer an official configurable solution. **Next Steps:** - Please let me know if this issue is still relevant to the latest version of better-auth by commenting here to keep the discussion open. - Otherwise, this issue will be automatically closed in 7 days. Thank you for your understanding and contribution!

GiteaMirror commented

2026-04-15 16:46:20 -05:00

@steinitz commented on GitHub (Jan 14, 2026):

Issue is still relevant and should be addressed with reasonable priorityOn 13 Jan 2026, at 3:14 am, dosubot[bot] @.***> wrote:dosubot[bot] left a comment (better-auth/better-auth#3742)
Hi, @steinitz. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.
Issue Summary:

You requested a configurable option sendOldEmailVerification to disable sending verification emails to the old email during email changes.
Currently, no built-in option exists; workarounds rely on fragile custom logic in sendVerificationEmail handlers.
Discussion highlighted the security rationale for verifying the old email to prevent hijacking, with alternatives like password verification or MFA suggested.
You acknowledged the pain point and have implemented a fragile workaround but prefer an official configurable solution.

Next Steps:

Please let me know if this issue is still relevant to the latest version of better-auth by commenting here to keep the discussion open.
Otherwise, this issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@steinitz commented on GitHub (Jan 14, 2026): Issue is still relevant and should be addressed with reasonable priorityOn 13 Jan 2026, at 3:14 am, dosubot[bot] ***@***.***> wrote:dosubot[bot] left a comment (better-auth/better-auth#3742) Hi, @steinitz. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale. Issue Summary: You requested a configurable option sendOldEmailVerification to disable sending verification emails to the old email during email changes. Currently, no built-in option exists; workarounds rely on fragile custom logic in sendVerificationEmail handlers. Discussion highlighted the security rationale for verifying the old email to prevent hijacking, with alternatives like password verification or MFA suggested. You acknowledged the pain point and have implemented a fragile workaround but prefer an official configurable solution. Next Steps: Please let me know if this issue is still relevant to the latest version of better-auth by commenting here to keep the discussion open. Otherwise, this issue will be automatically closed in 7 days. Thank you for your understanding and contribution! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

GiteaMirror commented

2026-04-15 16:46:21 -05:00

@qodesmith commented on GitHub (Feb 27, 2026):

@steinitz I can confirm this is still an issue. I'm using the latest version of Better Auth - 1.4.19.

For more context, I was debugging with Claude and this is what it gave me. Maybe pass this on to the Better Auth team:

Better Auth treats sendChangeEmailVerification as a fallback for sendChangeEmailConfirmation, triggering a 2-step process:

Step 1 (what you're seeing): Since user.emailVerified === true and sendChangeEmailVerification is configured, Better Auth creates a token with requestType: "change-email-confirmation" (line 461 of update-user.mjs) and sends the email via your sendChangeEmailVerification function.

When you click that link: The /verify-email endpoint sees requestType: "change-email-confirmation" (line 180 of email-verification.mjs) and instead of updating the email, it:

Creates a second token with requestType: "change-email-verification"
Sends a second email via emailVerification.sendVerificationEmail (your SignUpVerificationEmail template)
Redirects you to /account

Step 2 (what you're missing): Only when the second email link is clicked does Better Auth actually update the email in the DB (line 206).

So you're clicking link 1 of 2. The second email is being sent using your SignUpVerificationEmail template (subject: "Verify your email address"),which probably looks unrelated to the email change.

Fix options:

Remove sendChangeEmailVerification from user.changeEmail — this skips the 2-step flow and goes directly to a single-step verification via
emailVerification.sendVerificationEmail. Downside: uses the sign-up email template.
Keep the 2-step flow but check for that second email arriving after you click the first link.

@qodesmith commented on GitHub (Feb 27, 2026): @steinitz I can confirm this is still an issue. I'm using the latest version of Better Auth - `1.4.19`. For more context, I was debugging with Claude and this is what it gave me. Maybe pass this on to the Better Auth team: --- Better Auth treats `sendChangeEmailVerification` as a fallback for `sendChangeEmailConfirmation`, triggering a 2-step process: **Step 1** (what you're seeing): Since `user.emailVerified === true` and `sendChangeEmailVerification` is configured, Better Auth creates a token with `requestType: "change-email-confirmation"` (line 461 of update-user.mjs) and sends the email via your `sendChangeEmailVerification` function. **When you click that link:** The `/verify-email` endpoint sees `requestType: "change-email-confirmation"` (line 180 of email-verification.mjs) and instead of updating the email, it: 1. Creates a second token with `requestType: "change-email-verification"` 2. Sends a second email via `emailVerification.sendVerificationEmail` (your `SignUpVerificationEmail` template) 3. Redirects you to `/account` **Step 2** (what you're missing): Only when the second email link is clicked does Better Auth actually update the email in the DB (line 206). So you're clicking link 1 of 2. The second email is being sent using your `SignUpVerificationEmail` template (subject: "Verify your email address"),which probably looks unrelated to the email change. Fix options: 1. Remove `sendChangeEmailVerification` from `user.changeEmail` — this skips the 2-step flow and goes directly to a single-step verification via `emailVerification.sendVerificationEmail`. Downside: uses the sign-up email template. 2. Keep the 2-step flow but check for that second email arriving after you click the first link.

GiteaMirror commented

2026-04-15 16:46:22 -05:00

@steinitz commented on GitHub (Feb 27, 2026):

@qodesmith
From your report, Claude seemed to overlook that the user may no longer have access to the old email. I consider that the core defect. The inconvenience, spam, gratuitousness and possible confusion seem annoying but not fatal.

@steinitz commented on GitHub (Feb 27, 2026): @qodesmith From your report, Claude seemed to overlook that the user may no longer have access to the old email. I consider that the core defect. The inconvenience, spam, gratuitousness and possible confusion seem annoying but not fatal.

GiteaMirror commented

2026-04-15 16:46:22 -05:00

@qodesmith commented on GitHub (Feb 27, 2026):

@steinitz Interesting, I hadn't considered that. So it seems there are 2 scenarios here:

User has access to old and new emails and would like to change their email on file
User no longer has access to old email and would like to change their email on file

Is Better Auth trying to address both or just one of these scenarios?

@qodesmith commented on GitHub (Feb 27, 2026): @steinitz Interesting, I hadn't considered that. So it seems there are 2 scenarios here: 1. User has access to old and new emails and would like to change their email on file 2. User no longer has access to old email and would like to change their email on file Is Better Auth trying to address both or just one of these scenarios?

GiteaMirror commented

2026-04-15 16:46:23 -05:00

@qodesmith commented on GitHub (Feb 27, 2026):

For the record, I was able to mitigate against this issue by:

Not using user.changeEmail.sendChangeEmailVerification
Implementing conditional login inside emailVerification.sendVerificationEmail

Example sendVerificationEmail implementation:

const authOptions = {
  emailVerification: {
    sendVerificationEmail: async ({user, url, token: _token}, request) => {
      const {pathname} = new URL(request.url)

      if (pathname.endsWith('/sign-up/email')) {
        return void sendSignUpEmail({email: user.email, url})
      }

      if (pathname.endsWith('/change-email')) {
        // Better Auth only gives us access to the new email here.
        // But it also gives us the user id, so we can use that to get the existing email.
        const newEmail = user.email
        const userId = user.id
        const existingUser = getUser(userId)

        return void sendChangeEmailEmail({
          oldEmail: existingUser.email
          newEmail,
        })
      }
    }
  }
}

@qodesmith commented on GitHub (Feb 27, 2026): For the record, I was able to mitigate against this issue by: 1. Not using `user.changeEmail.sendChangeEmailVerification` 2. Implementing conditional login inside `emailVerification.sendVerificationEmail` Example `sendVerificationEmail` implementation: ```typescript const authOptions = { emailVerification: { sendVerificationEmail: async ({user, url, token: _token}, request) => { const {pathname} = new URL(request.url) if (pathname.endsWith('/sign-up/email')) { return void sendSignUpEmail({email: user.email, url}) } if (pathname.endsWith('/change-email')) { // Better Auth only gives us access to the new email here. // But it also gives us the user id, so we can use that to get the existing email. const newEmail = user.email const userId = user.id const existingUser = getUser(userId) return void sendChangeEmailEmail({ oldEmail: existingUser.email newEmail, }) } } } } ```

GiteaMirror commented

2026-04-15 16:46:23 -05:00

@steinitz commented on GitHub (Feb 28, 2026):

@qodesmith

Re your scenario question, Better Auth seems not to acknowledge your second scenario. That's the issue.

I hope that mitigation works for you. I found it was tricky to mitigate without causing other email verification issues. Moving target kind of thing.

Honestly, I've spent so much time, effort and head scratching on this I just don't have the heart to contribute much further. Even reading related code triggers some PTSD.

@steinitz commented on GitHub (Feb 28, 2026): @qodesmith Re your scenario question, Better Auth seems not to acknowledge your second scenario. That's the issue. I hope that mitigation works for you. I found it was tricky to mitigate without causing other email verification issues. Moving target kind of thing. Honestly, I've spent so much time, effort and head scratching on this I just don't have the heart to contribute much further. Even reading related code triggers some PTSD.

GiteaMirror commented

2026-04-15 16:46:24 -05:00

@ping-maxwell commented on GitHub (Mar 25, 2026):

Hey I believe this makes sense.

TLDR (kind of a self-note for future me to track):
Support for:

emailVerification: {
  sendOldEmailVerification: false
}

Meaning:

Only verify the new email
Skip verifying the old email

EDIT: Just realized there is a PR already open, will review it.

@ping-maxwell commented on GitHub (Mar 25, 2026): Hey I believe this makes sense. TLDR (kind of a self-note for future me to track): Support for: ```ts emailVerification: { sendOldEmailVerification: false } ``` Meaning: - Only verify the new email - Skip verifying the old email --- EDIT: Just realized there is a PR already open, will review it.

GiteaMirror commented

2026-04-15 16:46:25 -05:00

@ruban-s commented on GitHub (Mar 31, 2026):

Hi @ping-maxwell can i take this issue.

@ruban-s commented on GitHub (Mar 31, 2026): Hi @ping-maxwell can i take this issue.

GiteaMirror commented

2026-04-15 16:46:25 -05:00

@ping-maxwell commented on GitHub (Mar 31, 2026):

Hey that would be great thanks! @ruban-s

@ping-maxwell commented on GitHub (Mar 31, 2026): Hey that would be great thanks! @ruban-s

GiteaMirror commented

2026-04-15 16:46:26 -05:00

@ruban-s commented on GitHub (Apr 2, 2026):

I've submitted a PR that addresses this issue: #8877. Would appreciate a review when you get a chance! @ping-maxwell.

@ruban-s commented on GitHub (Apr 2, 2026): I've submitted a PR that addresses this issue: #8877. Would appreciate a review when you get a chance! @ping-maxwell.

GiteaMirror commented

2026-04-15 16:46:27 -05:00

@gustavovalverde commented on GitHub (Apr 14, 2026):

Related in the same area (not duplicates): #8043, #7002.

@gustavovalverde commented on GitHub (Apr 14, 2026): Related in the same area (not duplicates): #8043, #7002.

Sign in to join this conversation.

Branches Tags

2026-05-22/chore/adopt-agents-md

2026-05-22/refactor/string-case-utils

dependabot/npm_and_yarn/uuid-14.0.0

dependabot/npm_and_yarn/turbo-2.9.14

changeset-release/main

main

2026-05-14/fix/passkey-verify-error-and-claim

dependabot/npm_and_yarn/samlify-2.13.0

dependabot/npm_and_yarn/ws-8.20.1

changeset-release/next

dependabot/npm_and_yarn/demo/electron/demo-minor-patch-519ef7475f

dependabot/github_actions/github-actions-98f3470200

client-assertions-main

2026-05-15/ci/fix-sqlite-abi-mismatch

2026-05-15/fix/organization-team-add-cascade

2026-05-15/fix/parse-set-cookie-value-validation

2026-05-13/feat/captcha-wildcard-endpoints

2026-05-13/ci/stabilize-docker-startup

fix/i18n-before-hook-translation

fix/disable-migration-generate

2026-05-07/fix/admin-set-password-upsert

2026-05-10/fix/cookie-drain-order

2026-05-10/feat/hooks-finally

2026-05-09/fix/cookie-drain-order

2026-05-09/feat/hooks-finally

2026-05-08/feat/register-before-send

fix/stripe/subscription-data-merge

2026-05-01/chore/pnpm-v11-harden

chore/pnpm-v11

2026-04-29/feat/google-include-granted-scopes

2026-04-29/fix/oauth-account-scope-semantics

2026-04-27/fix/nextcookies-idempotent-writes

2026-04-26/fix/harden-proxy-host-validation

2026-04-26/refactor/stripe-callback-signature-cleanup

2026-04-26/fix/stripe-subscription-callback-timing

2026-04-11/fix/sveltekit-app-modules

feat/open-api-zod-contract

feat/oauth-provider-backchannel-logout-next

feat/oauth-idp-initiated-bounce

refactor/sign-in-challenges

2026-04-21/fix/oauth-rfc-input-validation

fix/release-notes-new-packages

fix/two-factor-identity-guard

fix/resource

feat/emailpassword-authorize

2026-04-12/security/dynamic-baseurl-proxy-trust-default

feat/oauth-provider-at-hash-v2

fix/release-grep-fallback

claude/address-review-comments-JhFLr

claude/slack-update-stripe-docs-consistency-8Sc0w

feat/async-auth

fix/two-factor-totp-verified-enrollment

feat/plugin-ui

codex/blog-1-6-release-post

2026-04-06/fix/type-any-guards

2026-04-05/chore/downgrade-better-call

2026-04-04/ci/skip-vercel-fork-prs

2026-03-28/ci/add-autofix-ci

chore/release-preview-script

himself65/2026/02/19/role

2026-03-24/fix/update-user-info-on-link

2026-03-20/docs/improve-website

2026-03-20/fix/anonymous-onlinkaccount-expo

2026-02-17/fix/anonymous-link-state

fix/8607-saml-inresponseto

fix/8549-scim-patch-noop

v1.4.x

refactor/migration-snapshot-tests

worktree-magic-link-additional-data

chore/migrate-build-to-rollup

worktree-fix-dynamic-baseurl-8447

2026-03-06/chore/public-api-check

fix/close-8156-regression-test

fix/secondary-storage-json-error-handling

himself65/verification-namespace

cursor/issue-8307-validation-79a3

himself65/2026/01/30/error-mdx

v1.4.x-staging

fix/email-otp-user

fix/restrict-full-organization-access-roles

himself65/2026/02/12/count

himself65/2026/02/04/define-plugin

2026-02-04/feat/add-pluralize

cursor/better-auth-js-integration-ec21

cursor/expo-state-mismatch-394c

2026-02-01/fix/org-update-role-sync-members

cursor/issue-7607-investigation-e146

cursor/email-generation-helper-0ff6

himself65/2026/01/21/avoid-spread-operator

himself65/2026/01/14/cli

claude/slack-add-docs-pr-NMvgO

claude/slack-add-advanced-useplural-WHKYL

feat/hooks-pos

feat/2fa-phone

feat/2fa

fix/rotation

fix/username-check

v1.3.x

refactor/organization

feat/multiple-client-ids-social-providers

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/better-auth#18338

[GH-ISSUE #3742] Configurable Email-Address Change Verification Flow #18338

Is this suited for github?

Is your feature request related to a problem? Please describe.

User Impact

Developer Impact

Describe the solution you'd like

Primary Feature: sendOldEmailVerification Option

Current Workaround (Fragile)

Secondary Improvements

Describe alternatives you've considered

Alternative 1: Always Single Email

Alternative 2: Configuration at Call Time

Alternative 3: Role-Based Configuration

Additional context

Real-World Use Cases for Configurable Verification

Current Behavior Analysis

Backward Compatibility Strategy

Implementation Considerations

Expected Benefits

Primary Feature: `sendOldEmailVerification` Option