If you don’t want to make a change to your user data storage (e.g. add another field to your database table.), you can include the new email address in the confirmation reply link as a parameter. For security purposes, you could also send a notice to the current address, “Hey, you’re changing your email address to “whatever” so a confirmation was sent there…”.

Your application will have to treat an email address change confirmatation a little different than your new account confirmation process by updating the email address. Maybe the old one is logged?

If the user chooses not to confirm your app doesn’t have to do anything.

I don’t know how critical an email address is to the application (relies heavily on notices or is just for your marketing purposes), but you may want to consider maintaining more than one. There can always be a default/main address. Old addresses are just disabled in case of a mix up.

I think the best approach would be to create a new table called email_resets, where you will have a few fields:

id | new_email | old_email | hash | date_added

Then send the user a reset email link on the old email address. Inform the user that his email will be changed to [email protected], and then when he clicks the link, check the hash, email and the time when the request was made, then you can update your main user table, and delete the reset email entry. (you can replace old_email with user_id, and maybe remove the id field completely)

The advantages would be the following:

• no alterations to the main table (neither database structure, nor the values stored)
• you have full control over the time limit (ie reset email link will only be available for X hours), and you can make a cron job to clean up the table.
• little extra memory needed – if the email reset requests are cleaned up every few hours/days

PS: A randomly generated hash is also needed (this is the reason behind the hash field), besides the expire time to make sure these requests cannot be forged.

is the email id the login id? is it used as a reference anywhere else? does the user row have a different primary key?

If designed well then the table has a Db / separate primary key (and the email id it self is not a foreign key elsewhere). Then you could keep new email addresses in a different table till its verified along with the key to who it belongs. also as validation make sure same email id is not used by other user nor is it under validation by someone other user.

once validated, update to the main table, remove from the temp table and if you can keep the old email in an audit table