A transactional email is an automated message triggered by something a specific person did, or something that happened to their account, and it carries information they’re expecting or that they need to complete an action. Receipts. Password resets. Shipping updates. Two-factor codes.
The definition is the easy part. The interesting part is the line that separates a transactional email from a marketing email, because that line moves depending on who’s reading it (your customer, Gmail, the FTC, a Canadian regulator) and crossing it accidentally is the most common way teams blow up their own deliverability.
So this guide does three things: defines the category cleanly, walks the boundary with marketing email in detail, and then gets into how you actually send these messages reliably from a real application. If you just need the quick answer, the next section is yours. If you’re deciding what to build on, scroll down to “how to send.”
Sending transactional email and want a free plan to test with?
Try SMTP2GO free for 1,000 emails a month →
What is a transactional email?
A transactional email is an automated, one-to-one message that goes out in response to a specific action a user took, or an event the system recorded against their account. It contains information unique to that person, and it’s almost always expected. Most of the time, the user is actively looking for it (refreshing the inbox to grab the verification code, watching for the receipt).
Five traits that hold true for almost every transactional email:
- Triggered by an action or event, not scheduled
- Sent to one recipient at a time, not blasted to a list
- Contains user-specific information (their order, their token, their tracking)
- Expected by the recipient as part of using your service
- Time-sensitive – late is almost as bad as undelivered
If a message doesn’t tick all five, it’s probably not transactional, even if it feels like it should be. The shipping confirmation a customer is reloading their inbox to find? Transactional. The “we noticed you haven’t logged in for 30 days” nudge that pulls them back? That’s marketing, even though it’s triggered.
According to MailerSend’s 2026 transactional email benchmarks, this category averages 80–85% open rates against roughly 20% for marketing email. The reason isn’t a content secret. It’s that recipients are actively waiting for these messages.
Transactional email vs marketing email
| Transactional | Marketing | |
|---|---|---|
| Purpose | Inform or complete an action | Persuade, nurture, promote |
| Trigger | User action or system event | Campaign schedule or automation |
| Audience | One recipient | Many recipients |
| Content | User-specific | The same message to a segment |
| Consent | Implied by the transaction | Explicit opt-in required |
| Unsubscribe | Generally not required | Mandatory |
| Timing | Immediate | Scheduled or sequenced |
| Example | Order receipt | Weekly newsletter |
The diagnostic that works best in borderline cases is to ask why the email exists. If the recipient can’t reasonably finish what they started without this message (can’t log in without the reset, can’t expect their package without the tracking), it’s transactional. If you’re sending it to influence behavior that hasn’t happened yet (open, click, buy, upgrade, come back), it’s marketing.
Gmail and Yahoo both apply their own classification on top of yours, and they pay close attention to whether the content is genuinely personalized versus “Hi {first_name}” template fill. If the same message goes out to thousands of recipients at once with only superficial personalization, inbox providers tend to read it as bulk regardless of what your code calls it.
Common types of transactional email
Account and access
Account creation confirmations, email verifications, password resets, magic links, two-factor codes, new-device login alerts, admin notifications when teammates join or trials expire. The login-adjacent emails. If they don’t land, your support
queue fills up the same hour.
Payment and billing
Order confirmations, receipts, invoices, dunning emails when a card fails, subscription renewal notices, refund confirmations. These are also the ones with the strictest legal expectations: receipts must be honest, refunds traceable.
Shipping and status updates
Shipping confirmation, delivery updates, appointment reminders, reservation confirmations. Often the highest-engagement messages a brand sends. Order confirmations average 70–90% opens.
Security alerts
Password changed. New device login. Suspicious activity. Account locked. These overlap with account-access emails but earn their own category because the deliverability bar is highest: a security alert that lands in spam is a security hole.
Requested content
Data exports, CSV downloads, return labels, statements, itineraries, PDFs. Triggered when the user explicitly clicked “send me this.” Often the heaviest payload of any transactional email (attachments, signed URLs) and where API-side errors tend to bite.
Product and activity notifications
Mention alerts, comment notifications, usage summaries, digest emails. These are the most contested category, because some of these (the daily digest, the weekly summary) start to look like content marketing to inbox providers if they aren’t tightly user-specific.
Transactional, marketing, or borderline?
| Email type | Usually transactional? | Why |
|---|---|---|
| Password reset | Yes | Required to access the account |
| Order receipt | Yes | Confirms a completed transaction |
| Shipping update | Yes | Status of an in-progress transaction |
| Two-factor code | Yes | Required to complete login |
| Welcome email (account confirm only) | Yes | Completes signup |
| Welcome email (with promo content) | Borderline | Crosses into marketing under CAN-SPAM if promo is dominant |
| Abandoned cart | Usually no | Designed to recover a sale; classified as marketing in many jurisdictions |
| Back-in-stock alert | Usually no | Promotional notification, not a transaction |
| Review request | No | Customer feedback or marketing |
| Replenishment reminder | No | Designed to drive next purchase |
| Referral request | No | Promotional, even if event-triggered |
| Newsletter digest | No | Bulk content delivery |
| Birthday or anniversary email | No | Marketing dressed up as personal |
This is the part most explainer pages get wrong. Anything designed to influence
a future purchase is marketing, even when the trigger looks transactional.
The compliance line, and where it moves
Under the US CAN-SPAM Act, the FTC applies a “primary purpose” test. If the email
is primarily transactional, the marketing rules don’t apply. If it’s primarily
commercial, they do. The industry working rule is 80/20: at least 80% of the
content should be the actual transactional information, with no more than 20%
promotional add-ons, and the transactional content has to appear first.
The moment you flip that ratio, the email is a commercial message in the FTC’s
eyes, and you need a working unsubscribe mechanism, accurate from address,
identification as an ad, and the rest of CAN-SPAM. Adding a “10% off your next
order” banner to a receipt is the most common way teams cross the line without
noticing.
GDPR and CASL are stricter. Under GDPR, mixing marketing into a transactional
message in a way that suggests the recipient consented to marketing by completing
the transaction is risky. Canada’s CASL effectively prohibits it for any
recipient inside Canada. If you sell into Europe or Canada, treat transactional
and marketing as completely separate sending streams. We cover the full
breakdown in our GDPR, CAN-SPAM, and CASL guide.
A second compliance reality that matters more than the legal one: inbox providers
penalize promotional content in transactional streams. Gmail’s spam filter doesn’t
care about the FTC’s primary-purpose test. It cares whether the email looks like
the bulk mail it’s seen from your IP before.
How to send transactional email reliably
Three real options for any production system. They aren’t ranked. The right
choice depends on what you’re sending from.
Option 1: SMTP relay
Best for apps that already speak SMTP (Drupal, WordPress, WHMCS, most CRMs and
ERPs), devices that only speak SMTP (Ricoh, Kyocera, Sharp, Xerox multifunction
printers, security cameras, phone systems, SIP servers), and anything legacy.
You point the application at a host like mail.smtp2go.com, give it a username
and password, and let the relay handle authentication, queuing, retries, and
inbox placement. We’ve got a deeper introduction to SMTP relay
if you want the full picture. Port 587 with STARTTLS is the default. Use 2525
when an upstream ISP or cloud provider is blocking 587. We don’t recommend port
25 for relay traffic.
Option 2: Email API
Best for custom application code where you control the send-side. Better error
handling than SMTP (you get a JSON response, a message ID, a structured error).
Webhooks for delivery, open, click, bounce, spam-complaint, and unsubscribe
events. Template support with merge variables, so the same payload can render
differently per recipient. Faster to integrate from scratch in a new codebase
than wiring up an SMTP library. See the API setup guides
for Node, Python, PHP, Ruby, and Django.
Option 3: Plugins and integrations
Best for WordPress, WooCommerce, cPanel, Microsoft Dynamics, Pipedrive, Zoho, Salesforce, and the long tail of off-the-shelf software where someone has already written the integration. Lowest setup effort. Easiest to maintain. You usually end up using SMTP under the hood, but the plugin handles the wiring.
What we recommend you don’t do: send production transactional email through a Gmail or Microsoft 365 mailbox SMTP account. The rate limits are low (Gmail caps unauthenticated apps at very small daily volumes, M365 at 10,000/day even on paid plans), the deliverability footprint is shared with everybody else on the platform, and Microsoft’s retirement of basic auth for SMTP keeps breaking integrations that depended on it. It works in dev. It breaks in production.
Regardless of which option you pick, three things have to be in place before volume goes up:
- SPF authorizing your sender to send from your domain (SPF basics)
- DKIM signing your outgoing mail so receivers can verify it wasn’t altered
- DMARC at minimum
p=nonefor visibility, moving top=quarantineor
p=rejectonce you’re confident (what is DMARC)
Since February 2024, Google and Yahoo both require DMARC for senders pushing more than 5,000 messages a day to their domains. That’s not negotiable anymore.
What to look for in a transactional email service
Past the marketing copy, this is what actually matters when you pick one:
Honest deliverability evidence, not just a “99% delivery rate” claim. Look for M3AAWG membership, ISO 27001, real customer placement numbers, and a postmaster team that you can reach. Both SMTP and API support, because you’ll probably need both eventually (devices on SMTP, app code on API). Webhooks for the six core events (delivered, bounced, opened, clicked, spam-complained, unsubscribed), and real-time reporting that lets you actually find the bounce that broke your reset flow yesterday.
Suppression-list handling that lets you query and manage it via API. Dedicated IP options for senders above ~200K/month who want to control their own reputation. A free or generous starter tier so you can integrate before talking to sales. Support that answers in hours, not days, especially when a reset flow is down.
We’ve got a longer breakdown of how to choose a transactional email service that covers the trade-offs for AWS SES, Postmark, SendGrid, Mailgun, and us.
Honest comparison: if you’re a developer with strong AWS chops, deep cost sensitivity, and a willingness to operate your own deliverability, SES is hard to beat on price. If you want something that just works out of the box, with 24/7 support and a free plan that doesn’t expire, we’d put SMTP2GO in your shortlist. Both are valid choices for different teams.
Why teams use SMTP2GO for transactional email
We’ve been doing this since 2006. M3AAWG member, ISO 27001 certified, GDPR compliant, based in New Zealand with support coverage that genuinely runs 24/7 because the team’s spread across timezones.
A few specific customer stories we can point to:
StoredTech, an MSP, has been sending through us since 2011, originally for office phone systems and copier MFCs that needed a reliable SMTP relay. Still running today.
Group IMD started on the free plan sending around 10,000 emails a month. Six years later they’re sending over a million a month for media-asset delivery notifications, on the same account.
ThinkPorch migrated to us from AWS SES specifically because support response times on SES weren’t workable for them. Their transactional flows now run on SMTP2GO with a dedicated IP.
If you want to try it on real traffic, the free plan runs 1,000 emails a month with no time limit, full API and SMTP access, webhooks, and the same dashboard paying customers use.
FAQs
What is a transactional email in plain language?
An automated email triggered by something a specific user did, sent only to them, that carries information they need or are expecting. Receipts, password resets, shipping updates, two-factor codes.
Is a welcome email transactional or marketing?
It depends on the content. If it confirms the account was created and contains verification or onboarding mechanics, it’s transactional. If it leads with promo content, product pitches, or upsells, it’s marketing under CAN-SPAM and needs to follow marketing rules.
Do transactional emails need an unsubscribe link?
Strictly transactional emails do not, because there’s nothing to unsubscribe from. The risk is that an email you’re calling transactional might actually be classified as marketing if it carries promotional content. When in doubt, keep transactional clean and run marketing on a separate stream with a working unsubscribe.
Do I need an opt-in for transactional emails?
No marketing opt-in is required, because the transaction itself is the consent. This doesn’t extend to mixing marketing in with the transactional message.
Should I use SMTP relay or an email API?
SMTP for apps and devices that already speak SMTP, especially anything legacy. API for new application code where you want webhooks, better error handling, and templates. Most production teams end up using both.
About the author
Simon Slade
Simon is a co-founder of SMTP2GO, launched in 2006 out of Christchurch, New Zealand. The idea was simple: a reliable way to send email from anywhere, even when local networks were blocking the usual ports. Twenty years on, SMTP2GO delivers for 35,000+ businesses across 130+ countries. SMTP2GO is ISO 27001 certified, GDPR compliant, an M3AAWG member, and a five-time Deloitte Technology Fast 500 company.
