Yes. If the domain behind a user's email address expires and someone else registers it, that person can create the same mailbox and receive password reset and verification messages. Products that treat an email address as permanent proof of identity inherit that risk. Detect stale domains, re-verify on risky events and offer stronger recovery.
How the risk arises
A domain is rented, not owned. ICANN's explanation of registration status codes shows that a lapsed domain moves through grace and redemption stages and is eventually purged and made available for registration. After that, anyone may register the name, set up mail and receive messages sent to any address at that domain.
Your product's database still has alice@oldstartup.example from years ago. If Alice's account uses that address for recovery, the new registrant can request a reset link and take the account. The same applies to company domains that were sold, shut down or forgotten, and to small custom domains used by individuals.
The effect shows in other places too. We described the registry version in expired maintainer domains in package registries.
Where products are exposed
| Pattern | Why it is risky |
|---|---|
| Email as the sole recovery factor | Whoever controls the mailbox controls the account |
| Domain based auto join | Anyone with an address at a company domain joins the tenant. A new owner of the domain could qualify |
| Old invitations and verified addresses never re-checked | The verification is years old |
| SSO or allowlists keyed on an email domain | The trust outlives the domain owner |
| Support teams that reset accounts on an email match | Social engineering becomes simple |
Our post on domain verification as the root of tenancy explains why domain claims need care.
What to do in your product
- Offer more than one recovery factor. Passkeys, an authenticator app or recovery codes reduce dependence on a mailbox.
- Re-verify on risk events. Ask the user to confirm the address again after a long gap, a new device or a change of recovery details.
- Watch domain health. For business tenants, periodically check that the verified domain still resolves and still has mail records. A sudden change is a signal. A domain whose registration data changed recently deserves a prompt to re-verify.
- Time limit domain claims. Require tenants to prove control again on a schedule, using a DNS record check.
- Slow down sensitive recovery. Add a delay, notify other contact methods and require extra proof for accounts with high privileges.
- Do not auto join on domain alone for sensitive tenants. Require an admin approval.
- Log recovery events and alert on resets that follow a long period of inactivity. See password reset and recovery events to log.
- Train support to refuse a reset based on an email match alone.
What users and companies can do
- Use an email address from a provider that will not lapse, for accounts that matter.
- Add a second factor, and keep recovery codes safe.
- When closing a company, move accounts to a different address before the domain is released, and remove the domain from tenant settings.
- Companies that retire a brand should keep renewing the domain, or follow the steps in what happens when a domain expires.
Limits
You cannot know every time a domain changes hands. The design goal is to make a stale email address worth less. Layered recovery and re-verification do that.
Safeguard works on software supply chain security with policies, gates and agent identity controls, and does not run account recovery for your app. Dependency scanning is free to try at gold.safeguard.sh/scan.
Quick check
Is a verified email address verified forever?
No. It was verified at one moment. The mailbox and domain can change hands later, so re-check on risky events.
Does MFA solve this?
It helps a great deal, as a reset link alone is no longer enough. Make sure the recovery path does not bypass the second factor.
Sources
Last reviewed: 19 October 2026.
