A SaaS transactional email system needs two things that are often split apart: reliable delivery code and a place for the owner to control what gets sent. The base includes both. It can send through five transports, render six branded templates, and let the owner edit, preview, and test those templates from the admin.
The five implemented transports are Resend, SendGrid, Brevo, Mailgun, and generic SMTP. Four are branded API services; the fifth is plain SMTP, which matters more than it sounds — it is the escape hatch for a product that has to send through a mail server it already owns, or through a provider none of the four adapters covers.
Every transport implements the same small interface: recipient, subject, HTML, sender, and reply-to data go in; a provider message ID comes back. The factory resolves the organization's active provider, loads its required configuration, and returns no provider when the setup is incomplete.
One sending path
Application email goes through one sendBrandedEmail function. It resolves a provider, chooses the recipient's locale, renders the requested template, and sends the HTML. Instead of throwing into the business action that triggered it, the function returns one of four explicit states: sent, no provider, render error, or delivery error.
That failure shape is deliberate. An invitation or billing webhook should be able to record that email delivery failed without turning the whole underlying operation into an unknown exception.
If the primary transport throws during delivery, the sender can try a second configured transport. The fallback resolver excludes the provider that just failed and auto-detects another configured option. A common setup is a self-hosted SMTP relay with a third-party service behind it.
Provider selection is stored per organization. The factory reads an explicit active provider first, then auto-detects configured credentials. Auto-detection checks all five transports. A sender address is required, and the renderer can combine it with the configured display name in a valid From header.
Six templates the owner can edit
The template registry contains welcome, admin password reset, subscription upgrade, notification, invoice, and user invitation emails. Each definition declares its subject, accepted variables, and rendering component.
The admin editor is wired to the template API. It can list the registry, load a saved override, update or delete it, edit email branding, render a preview with sample data, and send a test message. The renderer supports both structured string-slot overrides and a full custom HTML document.
Overrides can be locale-specific. At send time, the system looks up the recipient's profile locale, defaults to English for non-users or missing profiles, resolves translated subject and body strings, applies organization branding, and renders the final HTML. Custom HTML can interpolate both template variables and branding values.
That separation gives the owner useful control without changing delivery code. Switching from SendGrid to SMTP does not replace the invitation template. Editing the welcome subject does not change how Mailgun authenticates.
Authentication email is a separate channel
Signup confirmation, self-service password reset, magic-link, and email-change messages are sent by the authentication backend, not by the six application templates. The base includes an optional SMTP synchronization bridge so those identity messages can leave through the same provider account.
The bridge supports Resend, SendGrid, and authenticated generic SMTP. It needs a management access token because it updates the authentication project's SMTP configuration. Brevo and Mailgun report an unsupported status: their API credentials are not the dedicated SMTP credentials the authentication backend needs, and the code refuses to guess them.
The bridge changes delivery, not authorship. Identity-email content still lives in the authentication provider's dashboard. The product admin edits the six application templates. A buyer who wants a branded confirmation or self-service reset email must edit the separate identity templates there.
The honest limit
There are five switchable transports in the implementation, not four. That is good news for capability and a real documentation discrepancy. SMTP deserves to be named because it is the self-hosting path and because its configuration is different from an API-key provider.
The fallback only works when a second provider is actually configured. It also cannot rescue a render error, an unknown template key, or a bad recipient address rejected before provider failover. Returned status still has to be observed by the business flow if the owner wants retries or alerts.
Authentication email remains partly outside the product admin. SMTP synchronization does not copy branding or body content into the authentication dashboard. It does not support Brevo or Mailgun with the credentials the product currently stores, and it is a no-op without the management token.
There is also a known gap in the verification-required signup path. The current registration call does not set an email redirect URL, while the welcome-on-confirmation behavior depends on the authentication callback. The base defaults email verification off, so the normal path uses server-side confirmation and sends the welcome there. A buyer who turns verification on should treat the post-confirmation welcome as incomplete until that redirect is wired.
Why email belongs in every product
Email appears early: account creation, invitations, password recovery, subscription changes, invoices, and system notifications. If each trigger chooses its own provider and HTML, the product accumulates inconsistent branding and five different failure modes.
The included layer gives those triggers one sender, one provider factory, one template registry, and one admin editor. A small product can use one API provider. A self-hosted deployment can use SMTP. A cautious operator can configure a fallback. Localized products can render the same template in the recipient's language.
The strongest part is not the provider count. It is that transport, content, branding, and locale are separate concerns with clear boundaries—including the boundary where identity email still belongs to the authentication service.