This error occurs when you attempt to initiate account recovery for an email address that Kratos doesn't recognize as a valid recovery address for any identity in the system. The issue might be that while the email exists in the

identity_verifiable_addresses

table (which stores verified email addresses), it may not be properly configured as a recovery address in your identity schema. Here are some potential solutions: 1. Check your identity schema configuration: Make sure the email field in your identity schema has the recovery configuration properly set up:

json "email": {   "type": "string",   "format": "email",   "<http://ory.sh/kratos|ory.sh/kratos>": {     "recovery": {       "via": "email"     }   } }

2. Verify recovery addresses: Check if the email address is properly registered in the

identity_recovery_addresses

table, not just in the

identity_verifiable_addresses

table. The recovery process specifically looks for addresses in the recovery addresses table. 3. Enable notifications for unknown recipients: If you want to send recovery emails even to addresses not registered in your system (to prevent account enumeration attacks), you can enable the "notify unknown recipients" setting:

yaml flows:   recovery:     enabled: true     notify_unknown_recipients: true

This can be configured either through the [Ory Console](https://console.ory.sh/projects/current/recovery) or via the CLI as described in the [Attempted recovery notifications documentation](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset#attempted-recovery-notifications). 4. Check for fallback recovery addresses: If you're using a secondary email as a fallback recovery address, ensure it's properly configured in your identity schema as shown in the [Fallback recovery address documentation](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset#fallback-recovery-address). If you've confirmed all the above and still face issues, you might want to check if there's a mismatch between the email format in your database and the one being used for recovery (case sensitivity, trailing spaces, etc.).

I'm glad the previous solution worked for you! Regarding your question about automatically resetting a user's MFA integrations (specifically TOTP) during the account recovery process - the account recovery flow in Ory Kratos doesn't automatically reset the user's second authentication factor. As mentioned in the documentation: > When the user accesses the configured recovery method, they receive a privileged session and are taken to their account's settings page where they must create a new password to regain access to their account. The account recovery flow doesn't reset user's second authentication factor. [Account recovery and password reset](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset) However, there are a couple of approaches you can take: 1. Admin API approach: You can use the admin API to delete the user's TOTP credentials after they've initiated recovery. This is confirmed in a GitHub issue where a member mentioned that you can use the identity credentials deletion endpoint:

DELETE /admin/identities/{id}/credentials/{type}

to remove TOTP credentials [Disable 2FA and/or Recovery Codes for an Identity via the Identity Admin API](https://github.com/ory/network/issues/378) 2. Manual approach: After recovery, users would need to manually disable their TOTP in their settings. They can do this by unlinking their TOTP authenticator app as indicated in the UI messages documentation [Unlink TOTP Authenticator App](https://www.ory.sh/docs/kratos/concepts/ui-messages#unlink-totp-authenticator-app-1050004) The issue you might be experiencing is related to a known bug where the recovery flow with Two-Factor authentication doesn't properly respect the

return_to

parameter, as described in [this GitHub issue](https://github.com/ory/network/issues/222). This happens because when a user has 2FA enabled and goes through recovery, they get redirected through multiple flows that don't properly maintain the original return URL. If you're looking to implement a more automated solution, you would need to create a custom integration using the admin API to delete the TOTP credentials when a recovery is initiated or completed.