What Is Transactional Email? A Plain 2026 Guide

If you have ever clicked "forgot password" and watched your inbox, waiting for the reset link to show up, you have already met transactional email. You just probably never had a name for it. It is the quiet category of email that makes apps work, and most people only notice it when it breaks.

This guide explains what transactional email actually is, the kinds you send every day without thinking about them, how it differs from the marketing email people complain about, the ways you can send it in 2026, and the deliverability basics that decide whether it lands in the inbox or vanishes into spam. I will use Dreamlit as a worked example in a couple of places, because the way it sends mail off a database is a useful illustration, but the concepts here apply no matter what you use.

What transactional email is

A transactional email is a message your application sends to a single person because of something that person did, or because of an event tied to their account. The recipient triggered it, the recipient expects it, and the content is information they need rather than a promotion you decided to push.

A few things follow from that definition.

It goes to one recipient at a time. A receipt is for the one person who just paid. A login code is for the one person trying to sign in. This is different from a campaign that goes to ten thousand people on a list.

It is triggered by an action or an event. Someone signs up, someone resets a password, an order ships, a payment fails, a subscription is about to renew. The send is a reaction, not a scheduled broadcast.

It is expected, and often urgent. People wait for these messages. A verification code that arrives two minutes late might as well not arrive at all, because the person already gave up and tried again.

That expectation is the whole reason transactional email is treated as its own category. The reader asked for it, so the bar for getting it delivered fast and reliably is much higher than for a newsletter nobody is refreshing their inbox over.

Common types of transactional email

Here are the ones you run into constantly, grouped by what triggers them.

Account and authentication

These are tied to logging in and managing an account.

• Email verification, the "confirm your address" message after signup
• Password reset links
• One-time passcodes (OTPs) and magic login links
• Account alerts, like a new sign-in from an unrecognized device
• Email or password change confirmations

Auth email is the most time-sensitive group. If a magic link takes 90 seconds, the user is locked out of your product in the first 90 seconds they spend with it. That is a bad first impression and a real source of churn.

Purchases and money

These confirm something financial happened.

• Order confirmations and receipts
• Invoices and payment receipts
• Failed payment notices and dunning emails
• Refund confirmations
• Renewal reminders before a card is charged

Shipping and fulfillment

If you ship physical goods, these track the order's journey.

• "Your order has shipped" with a tracking number
• Out for delivery notices
• Delivery confirmations
• Delay or exception alerts

Activity and status

The catch-all group of "something changed and you should know."

• Someone mentioned you, replied to you, or assigned you a task
• A file finished processing or an export is ready
• A usage threshold was hit
• A scheduled job succeeded or failed

The line between this last group and notifications can get blurry, and that is fine. The point is that all of them share the same shape: an event happened, one person needs to know, and they get an email about it. If you want to think about that pattern more deliberately, we wrote about database-driven notifications as a way to model this.

One type in this group is worth pulling out, because it is the one teams underrate the most: lifecycle and onboarding mail. A "your project is ready" email after a slow setup step, or a nudge after someone signs up but never finishes onboarding, sits right on the edge between transactional and marketing. It is triggered by what the user did, which makes it feel transactional, but it is also trying to move behavior, which makes it feel like marketing. Classify these by their primary purpose. A factual service-status message may be transactional or relationship mail; activation, upgrade, re-engagement, and nurture content should usually be treated as marketing or commercial where local law requires it. We dug into one version of this in how one simple email type can 10x your user retention.

How transactional email differs from marketing email

People mix these up, and mixing them up causes real deliverability problems. The differences are worth being precise about.

The consent line is the one people get wrong. In the US, CAN-SPAM treats transactional or relationship content differently from commercial content. A receipt does not need a marketing opt-in. In the EU and UK, electronic marketing rules are generally stricter: marketing email usually needs consent or a narrow soft opt-in for similar products, and every marketing send still needs an opt-out. The trouble starts when you staple a promotion onto a transactional message, like adding "and check out our new plan" to a password reset. Now part of that email is commercial, and the rules for commercial email apply to it. Keep the two jobs in separate messages and you avoid the gray area.

If you want a deeper treatment of where the boundary sits and how to design each type, we have a full breakdown in transactional vs marketing email.

There is also a reputation reason to keep them apart, which I will come back to in the deliverability section. Marketing mail attracts complaints and unsubscribes. Transactional mail almost never does, because people want it. If both share the same sending reputation, a bad marketing campaign can drag your password resets down with it.

The volume difference matters too, and it shapes how each one is built. A marketing send might fire a hundred thousand messages in an hour and then go quiet for a week, so the system has to handle bursts. Transactional mail is the opposite: a steady trickle of single messages, one per event, all day long. That steadiness is part of why transactional reputation tends to stay healthy, since steady sending patterns look more trustworthy to inbox providers than spiky ones. It also means the two have different failure modes. A marketing tool that chokes on a burst is a different problem from a transactional path that adds thirty seconds of latency to every login code.

How transactional email actually gets sent

Once your app decides to send a message, something has to hand it off to the wider email system and get it into the recipient's inbox. There are a few ways to do that, and the right one depends on how much you want to build yourself.

Raw SMTP

SMTP is the protocol email runs on. The oldest approach is to talk SMTP directly: your app opens a connection to a mail server, authenticates, and hands over the message. You can run your own mail server, but almost nobody should. Self-hosted senders start with no reputation, get blocked easily, and turn deliverability into a full-time job. In practice "SMTP" today usually means pointing your app at a provider's SMTP endpoint rather than running the server yourself.

A provider over API or SMTP

This is what most teams do. You sign up with a sending provider, and your app either makes an HTTPS API call or connects to the provider's SMTP relay for each message. The provider handles the hard parts: warming up IPs, managing reputation, retrying failed sends, and giving you delivery and bounce data back.

The API route tends to be the friendlier one for a modern web app. You send a request, you get a response with a message ID and status, and you can log it. Providers like Resend, Postmark, and SendGrid all offer both API and SMTP. If you are weighing which one to use, we compared the field in best transactional email services, and there is a head-to-head on two of the big names in Postmark vs SendGrid.

Here is roughly where those three sit as of June 2026, based on their own pricing pages:

Pricing is current as of 2026 and changes often; confirm on each provider's site.

A platform

Some tools bundle sending with templates, a dashboard, and workflow logic so non-engineers can manage email too. These lean toward the marketing side, but many handle transactional flows as well. The tradeoff is less control over the raw sending path in exchange for not having to build the surrounding tooling.

An AI agent off your database

This is the newer model, and it is worth explaining because it changes where the work happens. Instead of calling a sending API from every place in your code that needs to fire an email, you connect your database and let an agent build the flows.

Dreamlit is the clearest example I have seen. You connect your Supabase or Postgres database, describe the email you want in plain English ("send a welcome email when a new row lands in users, and a renewal reminder three days before subscription_ends"), and it builds the trigger logic, the template, and the copy off your actual schema. It covers auth, transactional, drip, and broadcast email in one place. There is no API to wire up and no SMTP credentials to manage in your app code, because it reads the database directly. It exposes an MCP server, so you can also drive it from Claude, Cursor, Lovable, or Bolt.

The honest scope: the email workflow is the core use case, with no SMS or push channel, and it is Postgres or Supabase only. If your data lives somewhere else or you need multi-channel messaging, this is not your tool. But if you are building a Supabase app and you keep putting off the email work, the pitch is that you skip most of it. There is a longer writeup in a new way to manage transactional emails, and if you are specifically on Supabase, how to send emails from Supabase covers the options including this one.

A worked example helps. Say you run a small SaaS on Supabase and you need three transactional emails: a verification email on signup, a password reset, and a receipt after a Stripe payment writes a row to your payments table. With a traditional provider you would add API calls in three different code paths, build three templates, and test each trigger. With the agent model you point it at the database, describe the three flows in a sentence each, and the triggers hang off the rows that already exist. Same outcome, different amount of plumbing.

It is also worth being clear about what this model does not give you, so you can decide if the tradeoff fits. You give up some of the low-level control you get from calling a sending API yourself. If you need to construct a message body byte by byte in code, branch on twenty conditions, or send from a stack that is not Postgres, the database-driven approach is the wrong shape. What you get back is time. For a small team that keeps shipping the product and never quite getting to the email work, removing the plumbing is often the thing that finally gets transactional mail set up at all. If you are building on Lovable specifically, the email flows your Lovable app needs writeup walks through the common ones.

Deliverability basics that keep transactional email landing

You can send a perfectly written email and still have it land in spam if the technical setup is wrong. For transactional mail this is worse than annoying, because a password reset in spam is a locked-out user. A few fundamentals cover most of it.

Authenticate your domain with SPF, DKIM, and DMARC

These three records prove to receiving servers that you are allowed to send for your domain. As of 2024, Gmail and Yahoo started requiring authentication for bulk senders, and inbox providers broadly trust authenticated mail more, so this is no longer optional.

SPF (Sender Policy Framework) is a DNS record listing which servers are allowed to send mail for your domain. When a receiver gets a message claiming to be from you, it checks whether the sending server is on that list.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The receiver fetches your public key from DNS and confirms the message was actually signed by you and was not altered in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It tells receivers what to do when a message fails the checks, and it sends you reports about who is sending mail using your domain. A common rollout is to start at p=none with reporting on, watch the reports until you have accounted for every legitimate sender, then tighten to quarantine and eventually reject. Jumping straight to p=reject before you know all your senders is how teams accidentally block their own mail.

One subtlety worth knowing: passing SPF or DKIM is not enough on its own for DMARC. The domains have to align, meaning the domain in the From header has to match the domain that SPF or DKIM authenticated. This trips people up when they send through a provider that signs with its own domain by default instead of yours. The fix is usually to set up a verified custom sending domain with the provider, so the DKIM signature carries your domain rather than theirs. Most providers walk you through adding a handful of DNS records to make this happen, and it is the step a lot of people skip when their mail mysteriously starts landing in spam.

Send transactional mail from a separate domain or subdomain

This is the single highest-leverage habit. Put your transactional mail on its own subdomain, for example txn.yourdomain.com, and keep marketing on something like news.yourdomain.com. Separate subdomains help inbox providers see different reputation signals for each stream.

The payoff is isolation. Marketing campaigns are where spam complaints and unsubscribes come from. If that activity lives on a separate subdomain, a rough campaign is less likely to drag down the reputation of the subdomain your receipts and password resets send from. Your critical mail has a better chance of staying trusted even on a bad marketing week.

Remember that each sending subdomain usually needs the DNS records your provider gives you for SPF and DKIM. SPF checks the envelope-from or return-path domain, DKIM checks the signing domain and selector, and DMARC then compares those authenticated domains with the visible From domain for alignment. Configuring a provider only on yourdomain.com does not automatically verify txn.yourdomain.com. DMARC behaves differently: a subdomain can inherit the parent domain's DMARC policy by default, through the parent's p policy or an sp tag, unless you publish a DMARC record directly on the subdomain. So the practical rule is to configure every sending subdomain with the provider and decide per subdomain whether to rely on the inherited DMARC policy or override it.

Keep streams separated even within transactional

Many providers let you tag different message streams, and some let you use distinct DKIM selectors per stream. Splitting auth mail from receipts from activity alerts makes it easier to see where a problem is coming from, and it limits the blast radius if one key is compromised. You do not have to get fancy here on day one, but it is good to know the option exists as you grow.

Watch the basics that build reputation

Reputation comes from behavior over time. Send to addresses that bounce and your reputation drops. Get marked as spam often and it drops faster. For transactional mail this is mostly self-correcting, because people want the messages, but a few habits help: handle bounces and remove dead addresses, keep your sending volume steady rather than spiky, and make sure the From name and address look like they come from you rather than a random relay.

If transactional mail going to spam is a live problem for you right now, we have a focused guide in the email deliverability guide, and a Supabase-specific one in why your Supabase auth emails go to spam.

Putting it together

Transactional email is the plumbing layer of a product. It is the receipts, the codes, the resets, the alerts that a single user triggered and is waiting on. It is not the place for promotions, it lives best on its own authenticated subdomain, and the people receiving it almost never complain, which is exactly why keeping it clean and separate pays off.

How you send it is the part that has changed the most. You can talk SMTP, call a provider's API, run everything through a platform, or, if your data sits in Supabase or Postgres, let an agent like Dreamlit build the flows straight off your schema. The mechanics differ, but the goal is the same every time: the right message reaches the right person within a few seconds, and lands in the inbox. Get the authentication right, keep your streams separated, and most of the rest takes care of itself.

---

Frequently asked questions

What is a transactional email in simple terms?

A transactional email is a message your app sends to one person because that person just did something or because something happened on their account. A password reset, an order receipt, a one-time login code, a shipping update. The person expects it, often within seconds, and it carries information they need rather than a promotion.

What is the difference between transactional and marketing email?

Transactional email is triggered by an individual action and goes to one recipient at a time, like a receipt or a verification code. Marketing email is sent in batches to a list to promote or re-engage, like a newsletter or a sale announcement. They differ in trigger, volume, expectation, consent rules, and the inbox reputation they build, which is why most teams send them on separate domains.

Do I need consent to send transactional email?

In most cases you do not need marketing-style opt-in for genuine transactional messages, because the recipient triggered them and needs the information. CAN-SPAM in the US treats transactional content differently from commercial content, while EU and UK marketing rules still matter if the message includes promotional content. The moment you bolt a promotion onto a receipt, that part can be treated as marketing, so keep the two separate.

What does it mean to send transactional email over an API versus SMTP?

SMTP is the older protocol where your app opens a connection to a mail server and hands off the message. An API call is an HTTPS request to a provider that sends on your behalf and returns a status you can log. Most providers support both. APIs tend to be easier to add to a modern web app and give you better delivery data back.

What are SPF, DKIM, and DMARC and do I need all three?

SPF lists which servers are allowed to send for your domain. DKIM adds a cryptographic signature so receivers can confirm the message was not tampered with. DMARC ties the two together and tells receivers what to do when a message fails, plus it sends you reports. You want all three for transactional mail, because Gmail and Yahoo now require authentication for bulk senders and inbox providers trust authenticated mail more.

Should transactional and marketing email use the same domain?

Better to split them onto separate subdomains, for example txn.yourdomain.com for transactional and news.yourdomain.com for marketing. That helps isolate reputation signals. If a marketing blast picks up spam complaints, your password resets and receipts on the other subdomain are less exposed. Each sending subdomain usually needs its own provider-issued SPF and DKIM DNS setup, but DMARC alignment depends on the envelope-from and DKIM signing domains compared with the visible From domain; relaxed parent-child alignment can apply. A subdomain can inherit the parent domain's DMARC policy unless you publish a subdomain-specific policy.

Can an AI agent send transactional email instead of writing code?

Yes, that is the model Dreamlit uses. Instead of wiring an API into every place your app needs to send, you connect your Supabase or Postgres database, describe the email you want in plain English, and the agent builds the trigger, the template, and the copy off your schema. It works for auth, transactional, drip, and broadcast email. The email workflow is the core use case, with no SMS channel, and it is Postgres or Supabase only, so it is not a fit if you are on a different stack or need text messaging.

How fast should a transactional email arrive?

Seconds, ideally. People stare at the screen waiting for a login code or a password reset link, so anything past a minute reads as broken and they retry or abandon. Pick a sending path built for speed, keep your authentication clean, and watch for queue delays. Slow transactional mail is a common reason users get locked out of their own accounts.

Why do my Supabase auth emails land in spam?

Usually because they go out from a shared default sender with weak authentication for your domain, so inbox providers do not trust them. Setting up a custom SMTP sender with your own SPF, DKIM, and DMARC fixes most of it. Sources:

• https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business
• https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/
• https://support.google.com/a/answer/14229414
• https://senders.yahooinc.com/best-practices/
• https://www.rfc-editor.org/rfc/rfc7208
• https://www.rfc-editor.org/rfc/rfc6376
• https://www.rfc-editor.org/rfc/rfc7489