Why imported email verification disappears after an Ory identity update

If an email address imports into Ory as verified and then loses that state after an identity update, inspect the identity schema and traits before repeating the import. Ory’s import documentation warns that imported verification values are deleted on the next identity update when the address is not represented as a verifiable trait. It also requires address verification to be enabled. Ory identity import documentation

The practical question is whether three things agree: the verification feature configuration, the schema associated with the imported identity, and the address carried in that identity’s traits. A successful creation response alone does not establish that agreement.

This guide turns the documented behavior into an inspection and acceptance procedure. It is based on Ory’s current documentation; the examples are illustrative and have not been executed against a deployment.

Separate the migration decision from the schema diagnosis

First decide whether the source system’s verified flag deserves to be preserved. That is a migration-policy question: what evidence established ownership, and which address did that evidence concern? The companion guide on imported verification provenance covers that decision.

The problem here starts after you have made that decision. You intended to preserve a trusted verification state, supplied it during import, and need to determine why an ordinary account update does not retain it. Repeatedly setting a flag cannot substitute for checking the schema that gives the underlying address its meaning.

Keep these two investigations separate in the migration report. One asks whether verification should transfer; the other asks whether the destination configuration represents that intended state correctly. Neither is resolved merely by demonstrating that the user can sign in.

Inspect the identity’s actual schema and address

Ory imports a verified address through verifiable_addresses. Its documented example pairs a value in that array with the same email value in traits. The example sets verified to true, via to email, and status to completed. Verified-address import

For an affected test identity, record the schema identifier and inspect the schema actually associated with that identity. Do not assume it uses the newest schema simply because a newer file exists in your repository.

Then compare the intended email trait with the verification record. Trace the exact mapping in your importer rather than assuming that a field called email, contactEmail, or primaryEmail has the right semantics. Check for missing values, a wrong source column, and a mapping that places the address somewhere other than the schema’s verifiable field.

A compact inspection worksheet is useful:

Inspection	Question to answer	Evidence to retain
Deployment configuration	Is address verification enabled in the destination?	Sanitized relevant settings
Identity schema	Which schema does this imported identity use?	Schema identifier and saved schema
Trait annotation	Is the intended email trait marked for verification?	Relevant schema fragment
Imported values	Does the verification entry refer to the intended trait value?	Sanitized import mapping
Update path	What changed between the two reads?	Operation type and before/after difference

This worksheet is a suggested diagnostic method, not an additional Ory configuration format.

Mark verification separately from the email’s data type

Ory documents the verification extension under the trait’s ory.sh/kratos object. The relevant fragment is:

"verification": {
  "via": "email"
}

It belongs in the schema annotation for the address trait, alongside any other supported extensions that your design needs. This is a fragment, not a complete identity schema. Ory’s verification documentation contains the surrounding schema example. Address verification configuration

Review data validation, sign-in identification, and address verification as separate responsibilities. Ory’s example shows the password identifier configuration and verification configuration as separate entries. An email-shaped string and a password sign-in identifier should therefore not be treated as substitutes for inspecting the verification annotation. Verification schema example

Apply the supported configuration process for your deployment. Managed project configuration and a self-hosted deployment are different operational contexts; do not paste a project-management command into a self-hosted runbook without establishing its applicability.

Make the first subsequent update an acceptance gate

The warning in Ory’s import guide makes the update boundary particularly important. Include it explicitly in migration acceptance rather than stopping after the import request returns successfully.

Use a disposable account and a non-sensitive address you control. Save a sanitized before/after record around this sequence:

1. Confirm the intended schema and enabled verification configuration.
2. Import the test account using the approved source mapping.
3. Read the identity and inspect the verification entry.
4. Perform the ordinary, supported profile update your application will use, keeping the email unchanged.
5. Read the identity again and compare its traits, schema association, and verification state.

That is a proposed test, not a claim of an observed result. Run it against the precise deployment and update path you plan to use. If your application has multiple writers, repeat the relevant case for each writer instead of assuming an administrative update and a self-service update exercise identical integration code.

Add a separate changed-address case. The acceptance criterion should follow your verification policy for the replacement address; it should not simply demand that a historical verified flag remain true regardless of what changed. Record this separately from the unchanged-address case so intentional policy behavior is not confused with the schema problem.

Repair the configuration before retrying the import

If the worksheet exposes a missing annotation, wrong schema association, disabled feature, or mismatched trait, resolve that specific discrepancy and rerun the disposable-account check. Inspect already imported accounts separately; a corrected configuration is not evidence that previously removed values have been restored.

Preserve the original migration evidence when deciding how to handle affected accounts. If you can no longer substantiate verification for a particular address, do not manufacture that history to make the migration report look complete.

The useful completion record is more precise than “import succeeded”: it identifies the destination configuration, identity schema, approved mapping, and observed result after the first ordinary update. Include those findings in the broader identity migration plan before expanding the import cohort.