Short answer: for a Node.js logistics portal, use an API-based transactional welcome or password-reset email flow with provider-owned templates; keep templates in the repository only when review, localization, or coordinated multi-channel releases require application-level version control.
This is an operational choice, not a taste contest. Provider-owned templates reduce the amount of content shipped with every service release and make an API-based welcome or transactional flow relatively simple, but they also move an important artifact outside the normal code-review path. Before choosing a vendor, require custom-domain verification, DKIM readiness, template preview, suppression handling, and a delivery-event model that fits the reset token's short lifetime.
For the flow considered here, SMTP is not part of the design. The application calls an email API, and delivery, open, and bounce events are polled rather than pushed by webhook. That can be a good low-volume starting point. It is a poor fit for real-time orchestration.
The failure signal is event age, not open rate
Treat domain readiness as a deployment dependency. Verify the sending domain and DKIM before publishing a template, preview the rendered reset message with representative data, and permit sends only after that preflight passes. The template should accept a reset URL and a human-readable expiry, while the application remains responsible for creating and enforcing the actual short-lived token. Don't make an email-open event part of the security decision; Apple Mail Privacy Protection can prevent opens from being a dependable proxy for a person reading a message.
