Every web or mobile app that sells something ends up sending two very different kinds of email, and if you’re commissioning one, it pays to decide early which kind your developers will own. The first kind exists because the user did something: a password reset, an order confirmation, a shipping notice, a receipt. The second kind exists because the business wants something: a welcome series for new sign-ups, a reminder about an abandoned cart, a seasonal sale, a message to customers who haven’t bought in a while.
Both can be sent from the same codebase, and early in a project it’s tempting to do exactly that. The second group behaves differently, though. Its content, timing and audience change constantly: new offers each month, subject lines tested against each other, segments rebuilt as the catalogue grows. That pace suits a marketing team working in a dedicated tool far better than a developer shipping template changes through a release cycle.
The line between transactional and marketing email
The test is simple. If the user would be confused or harmed by not receiving the message, it’s transactional. A missing password reset locks someone out; a missing order confirmation sends them to support. These messages belong in the app, close to the events that cause them, and they should keep working even if the user has unsubscribed from everything else.
If the message exists to sell, inform or re-engage, it’s marketing. Welcome series, cart reminders and seasonal sales, the staples of most email marketing campaigns, all sit on this side. The user can opt out of it, it needs an unsubscribe mechanism, and it’s judged on clicks and revenue instead of delivery alone. Mixing the two in one email, such as a receipt stuffed with promotions, blurs the line and can push the whole message into the marketing category.
Why mailbox providers want the two streams apart
Mailbox providers have made the split a practical requirement. The Yahoo Sender Hub best practices ask senders not to send bulk and marketing email from the IP addresses they use for transactional mail and alerts, and to separate email types by IP or by DKIM domain, because each IP and DKIM domain builds its own reputation. A promotional campaign that draws complaints should not drag password resets into the spam folder with it.
The same guidance sets a ceiling: spam complaint rates below 0.3% for all senders.
Bulk senders also need SPF and DKIM in place, along with a published DMARC policy of at least p=none that passes. None of this is difficult, but it’s easier to get right once, in a platform built for marketing volume, than to rebuild inside a custom mail service.
How the app feeds events to the campaign tool
A dedicated platform still needs to know what users do, and that information comes from the app as events: account created, item added to cart, checkout started, order placed, subscription cancelled.
The cleanest architecture sends those events to the marketing platform through its API or an official integration, with a consistent customer identifier on every call. The marketing team then builds the logic on their side: wait an hour after a cart is abandoned, check that no order arrived, send the reminder. Developers define the events once and stay out of the campaign calendar.
Two details save trouble later. Send the event even when the user hasn’t consented to marketing, and let the platform decide whether to act on it, since consent can change after the event is recorded. And include the values the emails will need, such as product names, prices and image URLs, in the event payload itself, so the platform doesn’t have to call back into the app at send time.
One-click unsubscribe lives in the headers
Marketing email now needs an unsubscribe option that mail apps can trigger directly. Yahoo asks bulk senders for a working List-Unsubscribe header that supports one-click unsubscribing, a visible unsubscribe link in the body, and for requests to be honoured within two days. The mechanism behind it is defined in RFC 8058, Signaling One-Click Functionality for List Email Headers: a List-Unsubscribe-Post header carrying List-Unsubscribe=One-Click tells the mailbox provider it can send the request in the background, with no confirmation page.
Most dedicated marketing platforms add these headers to campaigns automatically. A custom mail service has to implement the endpoint, handle the POST request and feed the result back into your user record, which is one more piece of infrastructure to maintain. It also has to cope with the edge cases: a request that arrives twice, a user who unsubscribes from marketing and then places an order the same afternoon, a token that expires before the mailbox provider gets round to sending it. Each of these is a small task, but together they turn a weekend feature into a service your team owns for the life of the product.
A team scoping a new app can settle this boundary before the first sprint: which messages stay in the codebase, which events the app will emit, and which platform will receive them. Doing it then saves a migration later, when the marketing team is already sending campaigns and the transactional stream is sharing their reputation.
- How to Run a React App in VS Code Step by Step - October 23, 2026
- Transactional or marketing email: which messages your app should send itself - October 23, 2026
- How Software Teams Write SOPs for Releases and Deployments - October 22, 2026
