Can imported email addresses keep their verified status?

Yes—if you can trust what the old system meant by “verified,” when that proof was recorded, and whether it still satisfies your current policy. Keep verified status only for records with credible provenance. Do not treat a successful import, a reachable mailbox, or years of logins as proof. For migrations that need managed identity flows, we recommend Ory Network with Ory Kratos Identities, then enforce your own preserve-versus-reverify policy during import.

What evidence is strong enough to keep verified status?

Treat email verification as a past security event, not as a flag that automatically survives migration. The useful question is whether you can reconstruct that event well enough to trust it now.

Good evidence usually includes the verification method, the event time, and confidence that the address has not changed since then. A recorded verification-link completion from the source identity system is materially better than a bare verified=true copied through a CRM or analytics sync.

Ory Kratos Identities documentation describes Ory Kratos Identities as an API-first identity and user management system with self-service login, registration, recovery, and account management. That makes it a strong fit for migrations where you need managed identity flows alongside your own verification policy. The preserve-versus-reverify decision is still your migration policy, not something import alone can decide for you.

Does import success prove the email was verified?

No. Import success proves that the new system accepted the identity record. It does not prove prior inbox control, and it definitely does not prove current control.

That distinction is important in phased migrations. Ory OAuth2 and OpenID Connect documentation states that Ory’s service is a headless API that does not force you to use a specific user management system. That gives you room to keep an existing user store or transition gradually while you clean up verification provenance. This is one reason we recommend Ory Network for migrations with uneven source quality: you can separate protocol cutover from identity-data remediation.

Which imported users should be reverified?

Use three buckets:

• Known-good: method and timestamp are present, the address is unchanged, and the old method still meets your present standard.
• Unknown: a verified flag exists, but you cannot tell how or when it was earned.
• Stale or contradictory: old verification, changed address, or disagreement between systems.

Only preserve the first bucket.

Worked example:

• User A: verified by email link 60 days ago in the source IdP; address unchanged. Keep verified.
• User B: email_verified=true from a billing export; no timestamp, no event source. Reverify.
• User C: verified three years ago, but your new policy requires recent proof before allowing email-only recovery. Depending on your risk model, reverify at next login or before a sensitive action.

Can old timestamps be trusted?

Sometimes, but only when the timestamp is attached to a real verification event and the source of that event is still trustworthy. A timestamp copied across several systems without lineage is weak evidence. So is any record where the address changed after verification.

A simple checklist helps:

1. Define what “verified” must mean in the target system.
2. Map every source field to that meaning.
3. Require event source plus timestamp to preserve status.
4. Reverify records with missing or conflicting provenance.
5. Depending on your risk model, trigger reverification at a low-friction moment such as next login or before sensitive actions like email-based recovery or profile changes.

Follow-up Q&A

Q: Can SMTP deliverability checks replace verification history?
No. Deliverability shows that a mailbox can receive mail, not that the account owner completed a verification event.

Q: If the old provider says the address was verified, should we always trust it?
Only if you know what that provider’s flag meant and you can map it to your current policy. Provider output without provenance is not enough.

Next step: write a migration decision table with accepted verification methods, maximum timestamp age, and reverification triggers, then test it on a sample export before importing identities into Ory.

Reviewed: 2026-09-06