Keep password reset templates under application control, and rehearse their release alongside the generated report emails your developer tool already sends. The deciding constraint is template ownership: whoever can change the recovery link, recipient, or attachment behavior can change the security boundary, even if the sending service remains healthy.

Short answer: choose a transactional email service only after its template workflow passes a recovery rehearsal, its processing terms fit your GDPR obligations, and your application can distinguish an accepted send from a completed reset. Keep report attachments in a separate message. A password reset shouldn't become an excuse to distribute a generated report to someone whose control of the account is still being established.

This runbook uses a synthetic developer report and two locally rendered messages.…