Changing the text in an email field may only begin an account change. A service can still be waiting for confirmation, keep a different recovery address, or use another account to sign you in. The useful finish line is being able to return to the account and receive the messages you will need later.
Use this checklist when replacing an old personal mailbox, an expiring school address, or a temporary address used for an account you now want to keep. Follow the service's own instructions when its process differs. The Orchard Notes example below is fictional and illustrates checkpoints, not a promise about a particular website.
Find out what the old address actually controls
Open the account from a bookmark or by entering its known website address. Look at its sign-in, profile, security, and billing settings. The same address can appear in several places with different purposes. Make a private list before changing anything.
| Role | What to check |
|---|---|
| Sign-in identifier | Does the service expect an email address, a username, or a linked identity provider? |
| Login-link destination | Where will the next emailed sign-in link or code arrive? |
| Recovery address | Which mailbox receives help when ordinary sign-in fails? |
| Contact or billing address | Where do notices and receipts go, and is that field changed separately? |
If you use a button such as “Sign in with Google,” check the service's account-linking instructions before creating another login. Changing a contact address does not, by itself, demonstrate that the linked sign-in method changed. Avoid creating a second account as a test when the aim is to keep the existing one.
Prepare the destination while the old access still works
Sign in to the replacement mailbox and confirm that you can receive mail there. Choose an address you expect to retain. If it forwards through an alias, also check access to the forwarding account and its destination. Write down which service controls each part so a future forwarding problem is easier to trace.
For a recovery destination, choose one you can actually revisit. As a provider-specific example, Google's recovery setup guidance recommends a regularly used email address different from the one used to sign in to that Google Account. Other services have their own rules; check the guidance for the account you are changing.
If the old address is a TempGenerator inbox, inspect its countdown before starting. Its lifetime is temporary and depends on the domain configuration. Refreshing does not extend it, and saving the address text does not preserve access. Avoid beginning a multi-step change just before expiry. If the available time is insufficient, consult the account provider's support process while your current session still works.
Complete the requested change, then check its status
- Read the service's instructions for changing email. Note whether it requires the old inbox, the new inbox, your password, or another verification method.
- Enter the new address carefully. Compare both sides of the @ sign before submitting.
- Open the confirmation messages you requested. Distinguish a notification about a change from a message asking you to approve it.
- Complete each required confirmation through the expected service, then return to account settings.
- Check that the new address is active and that no pending-change notice remains. Record the completion date privately.
The distinction between pending and complete is deliberate. OWASP's guidance for developers implementing email changes describes reauthentication, a pending address, and confirmation or notification messages to the relevant inboxes. It explains why more than one step can be necessary; it does not establish which steps every provider uses.
Worked example: a change that looks finished too early
Imagine that Maya's fictional Orchard Notes account shows a new address immediately after she submits the form, alongside “Awaiting confirmation.” The old inbox receives an alert. The new inbox receives a confirmation link. Opening only the alert has not satisfied the task.
Maya opens the requested confirmation in the new mailbox, follows it to Orchard Notes, and returns to settings. The pending label disappears. She then checks the separate recovery field and finds that it still lists the old address. She updates that field using its own process before treating the migration as complete. Each checkpoint answers a different question: proposed address, accepted change, and future recovery.
Verify the next visit before retiring the old mailbox
Keep the current session available while you check the provider's instructions for testing the updated sign-in method. Where supported, use a separate browser session to sign in normally. Check that you reach the same account and that any requested login message arrives at the intended destination. Do not deliberately lock yourself out or start an unnecessary password reset just to prove a point.
Review any saved password-manager entry and the account's documented recovery options. Store recovery codes privately if the provider supplies them; never put them in a temporary inbox or support ticket. An authentication app or security key may help with sign-in, but do not assume it replaces the provider's email requirements.
If the old inbox is already unavailable
Use the service's official account-recovery or support route. Describe that the old address is inaccessible and identify the step you cannot complete. Supply only the information requested through that official channel. A newly generated temporary address cannot receive messages addressed to the previous inbox, and an email-change guide cannot guarantee recovery.
For future accounts, choose the receiving address around the account's expected lifetime. Our temporary inbox and email alias comparison explains the tradeoffs. Keep the old mailbox available for as long as the provider's instructions require, and finish the sign-in, recovery, and contact checks before considering the move complete.
