Use 15 original transactional email templates for verification, security, billing, orders, shipping, account changes, and alerts—with production rules for every state.
Transactional emails are triggered by a person’s action, an account event, or an existing commercial relationship. They help someone verify an address, sign in, understand a payment, follow an order, respond to a security event, or operate a product. Their value comes from accuracy and timing, not from sounding promotional.
The 15 examples below are original templates organized by event. Replace bracketed fields from authoritative application state, remove claims your system cannot prove, and test the complete path from trigger to inbox. A beautiful email with the wrong account, amount, or status is a serious product defect.
Transactional email examples at a glance
EVENT MESSAGE PRIMARY ACTION
Address submitted Verify email address Verify once
Password reset requested Reset password Reset securely
Password changed Security confirmation Review activity
New sign-in detected Security alert Secure account
Account or workspace created Account confirmation Continue setup
Invitation issued Workspace invitation Accept or decline
Payment succeeded Payment confirmation View receipt
Payment failed Dunning notice Resolve billing
Order accepted Order confirmation View order
Shipment accepted by carrier Shipping update Track shipment
Delivery recorded Delivery confirmation Review issue
Subscription changing Renewal/change notice Review billing
Export completed Job completion Download safely
Comment or reply received Activity notification View conversation
Service incident affects user Status notification View current status1. Email verification
Subject: Verify your email for [Product]
Hi [First name or there],
Verify [masked address] to finish creating your [Product] account.
[Verify email]
This link expires in [lifetime] and can be used once. If you did not create
this account, ignore this email or report it to [security route].Create the account in a restricted pending state, use a single-use token, and keep the destination limited to verification. Do not subscribe the address to marketing merely because ownership was confirmed; verification and promotional consent are different records.
2. Password reset
Subject: Reset your [Product] password
We received a request to reset the password for [masked account].
[Reset password]
The link expires in [lifetime] and works once. If you did not request this,
your password has not changed. You can review account security at [safe route].Never email an existing or newly generated password. Make unknown-account responses neutral, rate-limit requests, and send a separate confirmation only after the password actually changes. The dedicated password-reset guide covers token and session handling in detail.
3. Password changed confirmation
Subject: Your [Product] password was changed
The password for [masked account] changed on [date, time, timezone].
If you made this change, no action is needed. If you did not, secure your
account now using a fresh route that does not reuse the completed reset token.
[Secure account] [Contact security support]4. New sign-in alert
Subject: New sign-in to [Product]
A new sign-in was recorded for [masked account].
Time: [date, time, timezone]
Approximate location: [coarse location, if reliable]
Device: [privacy-reviewed description]
Was this you? No action is needed.
Wasn’t you? [Review sessions and secure account]Explain that IP-derived location can be approximate. Do not expose a full IP address or exact location unless the security benefit and privacy policy justify it. The action should open an authenticated security surface rather than perform an irreversible change on GET.
5. Account created
Subject: Your [Product] account is ready
Hi [First name],
Your account for [workspace or organization] is ready.
Next step: [one state-aware setup action].
[Continue setup]
Account: [masked address]
Plan: [plan or trial state]
Support: [monitored route]This message confirms account state; it is not permission to begin an indefinite promotional sequence. If onboarding education is optional marketing, preserve that choice separately and stop onboarding steps when the user has already completed them.
6. Workspace invitation
Subject: [Inviter] invited you to [Workspace] on [Product]
[Inviter name or verified identifier] invited [masked address] to join
[Workspace] as [role].
[Accept invitation] [Decline]
This invitation expires on [absolute date and timezone]. Accepting grants
[plain-language access]. Forwarding this email does not transfer the invitation.Resolve the invitee and role on the server, not from editable URL parameters. Make expired, revoked, already-used, and wrong-account invitations produce safe, understandable outcomes.
7. Payment confirmation
Subject: Payment received for [invoice or order]
We received [amount currency] from [customer/workspace] on [date].
Reference: [customer-safe reference]
Payment method: [brand] ending in [last digits]
Billing period or items: [concise detail]
[View receipt and billing history]
Do not recognize this payment? Contact [billing support].Trigger this from a verified succeeded event, not the browser’s success page. Keep payment, receipt, invoice, order, and fulfillment states distinct. The payment-confirmation guide includes twelve specialized versions.
8. Failed payment
Subject: We couldn’t process your [Product] payment
The [amount currency] payment for [workspace / invoice] did not complete.
Next attempt: [date and timezone, or no automatic retry]
Current service state: [accurate state]
Payment method: [masked method]
[Review billing securely]Coordinate the copy with retry state and stop it after recovery, void, cancellation, or support takeover. Do not guess the decline reason. Use the dunning-email examples for a complete recovery sequence.
9. Order confirmation
Subject: Order [number] is confirmed
Hi [First name],
We recorded order [number] on [date].
[Item] × [quantity] [amount]
Tax / shipping / discount [amount]
Order total [amount currency]
Payment status [actual status]
Next: [fulfillment step and realistic timing]
[View order] [Get help]Order accepted, payment captured, inventory allocated, and shipment dispatched are separate facts. State each one accurately and avoid implying that an order confirmation is a carrier handoff.
10. Shipping confirmation
Subject: Order [number] has shipped
[Carrier] accepted your shipment on [date].
Tracking number: [reference]
Estimated delivery: [provider-supported date or range]
Items in this shipment: [items]
Delivery destination: [safely masked location]
[Track with carrier] [View order]Create this from a carrier-accepted or equivalent fulfillment state. Label estimates as estimates, support split shipments, and keep a durable order page available if a carrier link expires.
11. Delivery confirmation
Subject: [Carrier] marked order [number] delivered
[Carrier] reported delivery on [date and time].
Delivery detail: [carrier-provided safe detail]
[View tracking]
Can’t find it? Check [practical first steps], then report the issue by [deadline]
through [support route].12. Subscription renewal or plan change
Subject: [Workspace] changes to [Plan] on [date]
Your [Product] subscription is scheduled to change from [old state] to
[new state] on [date and timezone].
Price: [amount currency and interval]
Proration / credit: [amount or explanation]
Features affected: [concise consequence]
[Review subscription]Make the effective date, price, interval, taxes, credit, and feature consequences explicit. Use the message required by the actual plan transition—requested change, upcoming renewal, completed renewal, cancellation scheduled, or cancellation completed.
13. Export or background job completed
Subject: Your [Product] export is ready
The [export type] requested on [date] finished successfully.
Scope: [workspace / date range / object count]
Available until: [date and timezone]
[Download from Product]
For security, sign in before downloading. The email does not contain the file.Prefer an authenticated product page over a long-lived public object URL. If a signed download is appropriate, scope and expire it, keep it out of analytics, and explain the real retention window.
14. Comment, mention, or reply notification
Subject: [Actor] mentioned you in [Project]
[Actor] mentioned you in [safe object title]:
“[Short, escaped, privacy-reviewed excerpt]”
[View conversation]
Manage notifications for [Project] at [preference route].Treat user-authored content as untrusted: escape it in HTML, limit length, remove dangerous markup, and consider whether sensitive workspace text belongs on lock screens or forwarded email. Collapse bursts into a digest when immediacy is not needed.
15. Service incident update
Subject: [Resolved / Investigating]: [Product area] incident
Status: [current state]
Started: [date and timezone]
Affected: [verified customer-visible impact]
Not affected: [only if confirmed]
We are [specific current action]. The next update will be posted by [time],
even if the status has not changed.
[View live status page]Select recipients from observed impact, not the entire contact database by default. Corrections should name the earlier error. Preserve a public incident record when appropriate so the email is not the only source of current truth.
Production rules for every transactional email
- Trigger from verified server-side state and make event handling safe against duplicates.
- Re-read current state immediately before delayed work sends the message.
- Use a recognizable aligned domain, SPF, DKIM, DMARC, TLS, and a monitored reply or support path.
- Keep authentication, billing, and other critical traffic separate from promotional volume and failure budgets.
- Include accessible HTML and meaningful plain text; test images-off, dark mode, zoom, and keyboard paths.
- Store provider message IDs and process delivery, bounce, complaint, and suppression events.
- Remove secrets and unnecessary personal data from content, URLs, logs, templates, and analytics.
- Test duplicate, delayed, out-of-order, expired, canceled, and already-completed states.
Frequently asked questions
What are common transactional email examples?
Common examples include verification, password reset, sign-in alert, invitation, payment confirmation, failed payment, order confirmation, shipping update, subscription change, export completion, activity notification, and service incident messages. The trigger and primary purpose matter more than the template’s internal label.
Can transactional emails include marketing?
Mixing promotion into an operational message can distract from the requested action and alter its legal or mailbox classification. Keep factual content primary and send optional promotions separately when consent and applicable law permit. Obtain qualified advice for the jurisdictions you serve.
Do transactional emails need unsubscribe links?
Essential account messages and subscribed marketing have different purposes and may have different requirements. Do not add a link that pretends users can opt out of necessary security or receipt messages if the product will ignore it. Give notification preferences for optional product activity and meet one-click unsubscribe requirements for eligible marketing and subscribed mail.