# Should the application or the identity service send verification and recovery emails? > Let the identity service issue and validate verification and recovery credentials, even when your application controls the interface or email delivery. Canonical URL: https://www.devobs.io/articles/should-the-application-or-the-identity-service-send-verification-and-recovery-emails/ By: Claire Dubois Published: 2026-10-28T11:28:13.232Z Updated: 2026-10-28T11:28:13.232Z Section: Architecture If an identity service already manages your accounts, keep it authoritative for verification and recovery: issuing and validating codes or links, enforcing expiration, and making the resulting account-state changes. Use its configured email delivery path by default. If your application needs to send the messages, use a supported delivery integration rather than building a parallel identity flow. The important distinction is **security ownership versus message delivery**. Owning the email template, sender infrastructure, or recovery screen should not require owning the credential that authorizes an account change. ## Separate the flow into four responsibilities A useful architecture separates responsibilities that are often bundled together as “sending a recovery email.” | Responsibility | Recommended owner | | --- | --- | | Present the interface and initiate the flow | Application UI, using the identity service’s flow APIs | | Issue, expire, and validate the code or link | Identity service | | Render and deliver the message | Identity service’s configured delivery path, or a supported trusted mailer integration | | Record verification or authorize recovery changes | Identity service | This is a recommended division of responsibility, not a requirement that every component come from one provider. For example, Ory documents self-service verification and recovery flows alongside custom interfaces built with its SDKs and REST APIs. An application can own the user experience without independently implementing the underlying identity flow. [Ory Identities introduction](https://www.ory.com/docs/network/kratos/intro) Avoid introducing an application-generated token store and a separate application-owned verification flag merely to change email branding. That design creates a second authority whose behavior must stay consistent with the identity service. ## Customize the experience before replacing delivery Start by checking whether the identity service’s existing customization options meet the requirement. Ory Network’s documentation lists email notifications for verification and recovery, SMTP/HTTP customization, and customizable templates. These are options for changing presentation or transport without replacing the security flow. For an application mailer, confirm the delivery interface, payload, authentication, and error handling supported by your deployment before designing the adapter. [Ory Identities introduction](https://www.ory.com/docs/network/kratos/intro) Recovery also involves more than sending a message. Ory’s recovery guide describes a sequence in which the user receives a code or link at a recovery address, proves ownership, and receives a privileged session to set a new password in account settings. Recovery does not reset the user’s second authentication factor; the guide also documents an option to require MFA during recovery. [Ory account recovery documentation](https://www.ory.com/docs/kratos/self-service/flows/account-recovery-password-reset) The practical implication: a custom recovery page should drive the identity service’s flow, not substitute an application endpoint that accepts an unrelated token and changes account credentials. ## Keep an application mailer within a narrow contract An application-controlled mailer can be a reasonable choice when a shared transactional-email pipeline or specialized routing is required. Treat it as a trusted delivery component, with an explicit boundary: - **Accept authorized delivery requests.** Authenticate the integration rather than allowing arbitrary callers to submit recovery messages. - **Preserve the service-authorized recipient and credential.** Do not accept browser-supplied overrides of the destination or recovery URL in the mailer after the identity service has authorized the message. - **Deliver rather than invent.** Send the identity-service-generated message, or render its authorized template data, according to the supported integration. Do not mint replacement codes. - **Leave redemption to the identity flow.** Direct users through the service’s verification or recovery flow. Do not let the mailer mark an address verified or change account credentials. These are recommended requirements for the adapter, not claims about the behavior of a particular Ory integration. Keep the mailer’s delivery acknowledgment separate from the user’s completion of verification or recovery. ## Preserve the security properties of password recovery Moving delivery must not weaken the recovery flow. OWASP’s password-reset guidance includes these controls: - Consistent response messages and response timing for existing and nonexistent accounts. - Protection against excessive automated requests, such as per-account rate limits, and against brute-force attempts to redeem reset tokens. - Cryptographically random, sufficiently long tokens or codes associated with an individual user. - Secure token storage, single use, and expiration after an appropriate period. - HTTPS reset URLs built from a configured address or validated against trusted domains, rather than trusting the incoming `Host` header. Treat these as controls to verify in the deployed recovery system, not as guarantees that an identity product satisfies them automatically. [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) The choice between links and codes also affects the interface. Ory documents one-time codes as its default and preferred recovery method. It says magic links remain supported but are legacy and deprecated. One reason Ory gives is that email security scanners can open links and invalidate them before the user does. If you change recovery methods, update and test the corresponding UI rather than treating the change as an email-template edit. [Ory account recovery documentation](https://www.ory.com/docs/kratos/self-service/flows/account-recovery-password-reset) ## Assign delivery operations without transferring account authority Before rollout, assign responsibility for submission failures, retries, duplicate delivery, bounces, and monitoring. Define what the interface should show when a message arrives after its credential expires, and establish how resend requests interact with outstanding credentials. Verify those semantics for the chosen integration rather than assuming they are interchangeable. Most importantly, successful email submission must not count as successful verification or recovery. OWASP explicitly advises against changing the account until a valid recovery token is presented. Keep delivery status separate from identity-flow completion. [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) Keep welcome messages, newsletters, and ordinary product notifications in the application messaging system unless another requirement dictates otherwise. Share branding or transport where useful, but preserve one authority for verification and recovery: **the mailer delivers the credential; the identity service decides whether it authorizes an account change.** ## Source references - - -