Transactional Emails

Transactional emails serve an account action or transaction, such as a password reset or receipt. Their purpose distinguishes them from marketing email.

A transactional email is an automated email sent to one person because of something they did or something that changed in their account, such as a password reset, a receipt or a login code. Its job is to complete or confirm that action, not to promote anything.

Other common examples are account verification, invoices, team invites, security alerts and product notifications. People expect them within seconds, so apps usually send them through an email API the moment the event happens.

Transactional vs marketing email

Transactional and marketing email can use the same sending platform, but they serve different jobs. If you are choosing a provider, start by comparing transactional email services. Then follow transactional email best practices for reliability, security, and deliverability.

Type

Trigger

Main purpose

Examples

Transactional email

User action or product event

Confirm or complete a specific action

Password reset, receipt, verification, login code

Marketing email

Campaign, segment, or lifecycle strategy

Promote, educate, or nurture

Newsletter, product launch, upgrade campaign

Lifecycle email

User behavior or customer stage

Move a user through activation or retention

Onboarding nudge, trial reminder, winback

The distinction matters because users expect transactional email to arrive quickly and clearly. Adding unrelated promotions to account-critical email makes it less useful, and it can change how the message is classified under anti-spam law (see the FAQ below).

Examples of transactional emails

Account verification. Confirms a new user controls the email address they used at signup.

Password reset. Lets a user regain access after requesting a reset link or code.

Magic link login. Sends a time-limited sign-in link after the user asks to log in.

Payment confirmation. Confirms a payment, renewal, upgrade, refund, or invoice.

Team invite. Lets a user join a workspace after another user invites them.

Security alert. Notifies a user about a login, password change, two-factor change, or other account-sensitive action.

Product notification. Sends useful product-triggered updates, such as export completion, failed import, usage threshold, or report-ready notifications.

Worked example: a password reset

A user clicks "Forgot password" in Acme, a project management app. Acme's backend creates a single-use reset link that expires in 30 minutes. It then calls its email provider's API with three things: the ID of the password reset template, the user's address, and two template values, the user's first name and the reset link.

The email arrives a few seconds later with the subject "Reset your Acme password". The body says why it was sent, shows one Reset password button, states that the link expires in 30 minutes, and tells the user to ignore the email if they didn't ask for it. There's no newsletter signup and no feature announcement.

Receipts, invites and login codes follow the same pattern: an event in your app, one API call, and one email with one job.

Best practices for SaaS teams

Send immediately. Transactional email is part of the product flow. A delayed password reset, receipt, or verification email feels like the product is broken.

Use one purpose per email. The email should explain the action and give one clear next step. Save product education for a separate lifecycle message.

Keep account-critical mail plain. Avoid heavy marketing templates, link shorteners, unrelated promotions, and unnecessary tracking on verification, login, password reset, and receipt email.

Use clear sender identity. The From name should match the product or team the user recognizes. The reply-to address should route to a monitored inbox when replies are likely.

Separate suppression logic carefully. A marketing unsubscribe should not block a password reset or receipt. Keep campaign preferences separate from account-critical delivery rules.

Monitor bounces and complaints. Hard bounces, spam complaints, and delivery failures on transactional email need fast handling because they affect product trust.

Include fallback text. For links and buttons, include enough context that the user understands what happened even if images do not load.

Common mistakes

Sending from noreply. Some transactional email does not need a reply, but billing, account, and invite messages often generate support needs. See no-reply email address.

Hiding the account context. Include workspace, invoice, plan, or action details so users can recognize the message.

Ignoring deliverability until something breaks. Transactional email needs authentication, clean sending domains, and bounce handling before volume grows. Check SPF, DKIM and DMARC with the DNS checker.

Transactional email in Loops

In Loops, you design a transactional email in the editor or upload MJML, add data variables for the values that change per send, and publish it. Your app sends it with the send transactional email endpoint, passing the email's transactional ID, the recipient's address and the data variables. You can also send over SMTP from tools such as Supabase, Rails or Laravel.

Loops applies these rules to transactional email, per its transactional vs marketing guide:

  • It can go to any address. The recipient is only added to your audience if the request sets addToAudience.

  • Unsubscribed contacts still receive it. Suppressed addresses, after a hard bounce or spam complaint, don't.

  • No unsubscribe link is added, and opens and clicks aren't tracked by default.

  • Welcome emails and "your trial ends in 3 days" reminders count as marketing. Send them from a workflow so they respect unsubscribes.

Related pages: account verification email examples, payment confirmation email examples, Next.js transactional email, email deliverability, and the email API.

FAQ

What are transactional emails?
Transactional emails are automated one-to-one messages triggered by a user's action, account state, or product event, such as password resets, receipts, verification emails, and security alerts.

What is the difference between transactional and marketing email?
Transactional email helps complete or confirm a specific user action. Marketing email promotes, educates, or nurtures an audience through campaigns or lifecycle programs.

Are receipts transactional emails?
Yes. Receipts, invoices, renewals, refunds, and upgrade confirmations are transactional because they are triggered by a billing event and expected by the recipient.

Is a welcome email transactional?
Usually not. A welcome email builds the relationship rather than completing an action, so it counts as marketing. Loops' docs recommend sending it from a workflow so it respects unsubscribes.

Can transactional emails include marketing content?
Avoid unrelated marketing in account-critical transactional email. In the US, the FTC's CAN-SPAM compliance guide says the primary purpose of a mixed message decides how it is treated. If a recipient reading the subject line would conclude the message is an ad, or the transactional content does not appear mainly at the beginning, the message is commercial and all CAN-SPAM requirements apply. Send product education separately.

Do transactional emails need unsubscribe links?
Account-critical transactional emails usually do not carry a marketing unsubscribe link. Under CAN-SPAM, a message whose primary purpose is transactional or relationship must still use truthful routing information but is otherwise exempt from most of the Act's provisions. Marketing and promotional messages need unsubscribe controls. In Canada, the CRTC's CASL guidance says commercial electronic messages need consent, sender identification, and an unsubscribe mechanism, subject to CASL's exemptions.

How do developers send transactional emails?
Developers call an email API, or send over SMTP, from their application when a signup, login, payment, or product event happens. In Loops, that is the send transactional email endpoint with a transactional ID and data variables.