Transactional email vs marketing email: the rules, the reputation, and the line an agent must not blur

A transactional email is triggered by something a person did and goes to that one person. A marketing email is initiated by you and goes to a list. When an AI agent writes or sends both, the risk is that it blurs them: a promotion inside a receipt, a list send pushed through the transactional lane, or contacts it imported without consent.

A receipt, a password reset, a shipping notification: transactional. A newsletter, a promotion, a product announcement: marketing. The longer treatment of the first half of that pair is the transactional email guide.

Consent and unsubscribe rules

Marketing email needs consent where the law requires it, and an unsubscribe link everywhere. Privacy laws in many countries require permission before you send promotional mail, and most anti-spam laws require a working unsubscribe link in every marketing message.

Transactional email generally does not require prior consent, because the recipient took an action that makes the message expected. A receipt for a purchase they just made doesn't need a marketing consent record, and it doesn't strictly need an unsubscribe link.

Two warnings on that, though.

First, the exemption is narrower than people assume. The moment you slide a promotion into a receipt, that email can lose its transactional status and fall under marketing rules. Regulators look at the primary purpose of the message, not the label you gave it in your sending tool.

Second, the position on this page is firmer than most: put a real unsubscribe link on transactional sends anyway. Not because the law demands it on every message, but because an email a person can't get out of is a complaint waiting to happen, and complaints are what actually damage you.

The transactional flag in Nitrosend has teeth. Mark a flow step transactional and it reaches contacts who unsubscribed from marketing. Event data such as {{ event.confirm_url }} still fills in. The setting exists for legally required authentication and recovery steps. It does not force delivery to addresses that hard-bounced or marked an earlier email as spam. Those stay suppressed by design.

Production transactional templates, such as welcome emails, password resets and invites, are run through a compliance check before they are used for real sends.

What changes when an AI agent sends both

An agent in a coding assistant or an MCP client builds email features in code and runs them unattended. Asked to send email from an LLM, it reaches for whichever send path is closest, and the legal line above does not show up anywhere in the code. Three things go wrong most often.

• It adds an upsell to a receipt. Asked to make a receipt earn more, a model adds an offer. The receipt's primary purpose can tip to commercial, which pulls in the unsubscribe rules and, where the law requires it, consent. The consent section above covers those rules.
• It routes a list send through the transactional API. Nitrosend's transactional sends skip subscription checks, CAN-SPAM footers, warmup and List-Unsubscribe headers, while engagement tracking stays on. Those skips exist because the message goes to one person who asked for it. A newsletter pushed down that path keeps the skips and loses the reason for them, and unsolicited outreach sent through a transactional API breaks email compliance norms.
• It imports contacts without consent. With nitro_import_contacts, a CSV import asserts consent, and inline records subscribe only with an explicit opt_in. An agent that sets opt_in to make an import pass has written a consent record nobody gave.

A useful rule of thumb works for agents too: every email is either "triggered 1-1" or "bulk". Triggered mail goes through the transactional lane, one message per event. Bulk mail is a campaign or a flow. Nitrosend's nitro_compose_flow creates or edits a flow draft and never activates it, so a marketing sequence an agent builds waits for a person to approve it.

Separate the two streams on different subdomains

Marketing email generates complaints. That's normal, even for good senders. Someone forgets they signed up, hits "spam" instead of unsubscribe, and your complaint rate ticks up. If your receipts and password resets are sending on the same domain and the same reputation, that marketing complaint rate now decides whether your password resets reach the inbox.

That's a terrible trade. A promotional email landing in spam costs you a click. A password reset landing in spam costs you a customer and a support ticket.

The email deliverability fix is stream separation: run marketing and transactional on different subdomains, so each carries its own reputation. news.yourdomain.com for campaigns, mail.yourdomain.com for the functional mail. Then a bad campaign week can't take your receipts down with it. Isolating reputation between mail types means one big promotional send cannot drag down the messages a customer is actively waiting for.

The related trap: never build a bulk outreach or mail-merge feature on top of the transactional sending path. It's a deliverability and compliance trap. The transactional path exists precisely because it's clean, and pushing list mail through it destroys the thing that made it valuable.

Cold outreach is neither stream. It needs different domains, mailboxes, volumes and deliverability rules, and belongs outside both.

Different metrics, different jobs

Transactional email is judged on delivery speed and reliability. People are waiting for these emails, so a high open rate reflects that rather than measuring performance. What matters is that it arrived, fast.

Marketing email is judged on click-through, conversion, and revenue. Opens are a weak signal. The email exists to cause an action further down.

Judging a receipt on click rate, or a campaign on delivery speed, is how teams end up optimizing the wrong thing.

Worked example: an agent asked to add a promotion to the receipt

The prompt: "Add a 10 percent off banner to our order receipt email."

Before. Left unguided, an agent edits the live receipt template and the banner ships in every receipt to every customer, including customers who never agreed to marketing. Nobody reads it before they do.

After. With the Nitrosend MCP tools, the agent works through a fixed sequence:

1. nitro_get_status checks account readiness and the sender identity.
2. nitro_manage_template with based_on clones the receipt into a copy and adds the banner there. The live receipt is not touched.
3. nitro_review_delivery runs a read-only review of the copy, with validation, spam analysis, preflight and previews. It never sends.
4. A person reads the review output and preview, sees a discount banner inside a receipt, and decides: the receipt stays transactional, and the offer moves to a marketing flow for contacts who consented to marketing.
5. nitro_compose_flow drafts that flow. It never activates it.
6. nitro_review_delivery reviews the flow draft the same way.
7. nitro_send_test_message sends one real test of the clean receipt template to the test recipients set with nitro_configure_account. It never reaches an audience.
8. nitro_send_test_message sends one real test of the flow draft to the same test recipients. It never reaches an audience.
9. A person approves the flow with nitro_control_delivery, which approves or controls flow and campaign delivery after review.
10. The app keeps sending receipts through the transactional email API, with one idempotency_key per order, so a retry of the same order never sends twice. The order event in the app is the trigger, and delivery events such as delivered, bounced and complained come back through email webhooks.
11. nitro_get_insights then reports email analytics with trends, benchmarks and recommendations.

Where it goes wrong when an agent mixes the two streams

• Promotional content inside a transactional template. A banner, a coupon or a product grid added to a receipt can change the message's primary purpose, and the receipt then falls under marketing rules while still being sent as transactional.
• A list blast pushed through the transactional lane. A loop that calls the single-send path once per contact turns a newsletter into thousands of one-to-one messages with no unsubscribe. That is the mail-merge trap described above, run by a model.
• Contacts imported without consent, or with a made-up opt_in. The import goes through, and the account now mails people who never agreed to hear from it.
• Sends nobody reviewed. An agent that edits the live receipt template changes every receipt from the next order on. Clone with based_on, review with nitro_review_delivery, and have a person check the test first.
• Retry double-sends. Without an idempotency_key, a retry after a timeout sends the same receipt twice.
• A volume spike against plan limits. A list sent down the wrong lane counts against the account's daily allowance. On the Free plan, recipients per rolling 24 hours run from 100 to 5,000 by sender standing, and a new account starts at the low end. The tiers are on the pricing page.

Run both streams in one stack

The usual setup splits these across two vendors: a developer's transactional service and a marketer's campaign tool. Each team gets what it needs, and the customer gets two different-looking emails from what's supposed to be one company. Branding drifts. Data lives in two places. Nobody can answer which emails one person got this week.

The view here is that these should be two streams in one stack, not two products. Same brand, same contact record, same analytics, separated where separation actually matters, which is sending reputation, not tooling. Nitrosend splits the two streams so a password reset never competes with a newsletter.

That is how Nitrosend is built. Transactional messages go out through a dedicated send path, campaigns and flows run alongside them, and both share the same brand, contacts, and reporting. The developer gets a clean email API for receipts, and an agent gets the same tools through the Nitrosend MCP server. A team still sending from an older SMTP library can check the SMTP ports its current provider uses, then move the send to the API. The marketer gets campaigns and automation. The customer gets emails that look like they came from the same company, because they did.

FAQ

Go deeper