Self-hosted transactional email

Why self-hosted transactional email is a different build from newsletters

If your application team must send receipts, password resets and security alerts from infrastructure you control, listmonk is the main fit for a transactional API that uses pre-defined templates, and Dittofeed fits event-triggered journeys that depend on user behavior. Neither platform delivers mail to a mailbox provider itself. Both hand messages to an email service provider or an SMTP server, so the sending service and the DNS records that authenticate your domain decide whether those messages reach the inbox. Treat the sending service as part of the build from the first design session, not as a detail to add at launch. Transactional mail must not share a sending stream, domain or reputation with marketing campaigns. A promotional complaint spike can push a shared domain toward the spam folder and delay a password reset that a customer is waiting for. Use a separate subdomain and separate SMTP credentials or sending configuration for transactional traffic, and confirm with your sending provider whether it supports dedicated streams or configuration sets for that split. In listmonk, the transactional API and the campaign queues are different paths, so decide which SMTP servers each one may use before the first template is approved. Before go-live, your team should confirm three things in writing: which sending service carries each stream, which DNS records (SPF, DKIM and DMARC) authenticate each sending domain, and who owns bounce and complaint handling for the transactional stream. Ask the sending provider for its suppression and bounce feedback model, because a listmonk instance cannot see mailbox-level outcomes on its own. Those answers determine whether a security alert reaches an employee on time, and they belong in the design document before any template is written.

Which requirements shape a self-hosted transactional build

This table maps each requirement that changes a transactional email build to its source and to the setup decision it drives. Read each row as a question to answer before you configure streams, templates, logs and suppression lists. The main takeaway is that transactional mail carries the same authentication and consent exposure as marketing mail, so it needs its own streams and evidence rather than a shared configuration.

Requirement	Where it comes from	What it means for the build
Sender authentication	Mailbox provider bulk sender rules, which apply to the domain regardless of message type	Use SPF, DKIM and DMARC alignment on the sending domain for each stream. Confirm with your sending service how it signs messages sent through listmonk. See the sibling topic on Gmail and Yahoo bulk sender requirements.
Separate transactional and marketing streams	Deliverability risk: marketing complaints can damage reputation used by receipts and resets	Use distinct sending domains or subdomains and distinct credentials for each stream. Keep password resets and alerts off any list that carries newsletter traffic.
One-click unsubscribe headers	Mailbox provider bulk sender rules for marketing mail	Expect these headers on campaigns, not on account messages. Do not add marketing footers or unsubscribe prompts to receipts or resets, because that blurs the message type.
Consent and message classification	Anti-spam law such as CAN-SPAM and CASL, and GDPR consent as lawful basis	Transactional messages are usually exempt from marketing consent rules when they are strictly account-related. Record which templates are transactional and confirm the classification with counsel for each jurisdiction. See the sibling topics on CAN-SPAM, CASL and GDPR double opt-in.
Suppression and bounce handling	Mailbox provider complaint and bounce expectations, and the operator's own sending hygiene	Suppress hard bounces and complaints across the stream before retrying. Confirm whether suppression is shared between streams, since a marketing complaint should not silently block a password reset without a documented decision.
Data residency of message content and logs	GDPR transfer rules and sector rules that restrict where personal data is processed	Message bodies often contain names, order details or account data. Confirm where the sending service stores logs and whether the self-hosted instance keeps copies in your own infrastructure.
Retention of sent messages and logs	The operator's own retention duties and any sector record-keeping rules	Set a retention period for delivery logs and rendered copies that matches your duties. Ask your counsel which records are needed as evidence and which should be deleted on schedule.
Template change control	Internal change management and audit evidence expectations	Keep templates in version control and require review before production changes. Test rendering with variables and check links, since a broken reset link is a common and visible failure.

Which platform fits which transactional workload

listmonk is a good fit when the application needs to send receipts, password resets and alerts through a simple API call against templates that the team controls. It is distributed as a standalone binary with PostgreSQL as its only dependency, and it is licensed under AGPL v3, which matters if you modify the code and offer it to users over a network. Its transactional mail API sends pre-defined templates, so the calling application passes a template reference and variables rather than building the message itself.

Operational footprint: One binary and one PostgreSQL database keep the stack small, and the project publishes a Docker image and a sample docker-compose.yml.
Sending path: Multi-threaded queues send across multiple SMTP servers with rate limiting, which lets you control throughput during a spike such as a mass password reset.
Access control: OIDC single sign-on, granular roles, permissions and API tokens let you separate senders and scope application credentials.
Visibility: Built-in analytics cover campaigns, bounces and links, which gives operators a first view of delivery outcomes.
Release line: listmonk v6.2.0 was published on June 26, 2026. Confirm the release line your team will pin, and how it handles upgrades, before you build against the API.

Check that your template variables, error responses and retry behavior match what the calling application expects, and test them under load in a staging environment.

Integration points and deployment pattern for transactional sends

A transactional sending setup is a chain: each application calls an API, listmonk queues and relays the message through an SMTP provider, and bounce and complaint events flow back. Each link needs an owner, a backup or monitoring plan and a check in your own environment before go-live.

Transactional API client in each application

Each application calls the listmonk transactional API with a pre-defined template ID and data fields, using an API token scoped to that sender. Decide per application who owns its template and token, and whether requests are retried on failure. Confirm in your environment how listmonk responds to a timeout so your application does not send duplicate receipts or drop password resets silently.

Sending relay: SES, another ESP or your own MTA

listmonk sends through one or more SMTP servers with rate limiting, so the relay is a configuration choice rather than a rebuild. Amazon SES, another email service provider or your own mail transfer agent each carry different reputation, logging and data location terms. Confirm which relay handles transactional traffic, its sending limits, and whether it sits inside the approved infrastructure your data rules require.

Bounce and complaint webhook path

Hard bounces and complaints must reach listmonk so suppressed addresses stop receiving sends. Map each relay's bounce and complaint notifications to the endpoint your listmonk instance exposes, and test that a bounce changes subscriber status. Confirm the exact configuration keys for your version, since a missed webhook keeps sending to dead or complaining addresses.

Separate marketing and transactional domains

Give transactional mail its own sending subdomain, separate from newsletter traffic, so a marketing complaint spike does not affect receipts and password resets. Each subdomain needs its own SPF, DKIM and DMARC records and a named owner. Confirm with your DNS team that the records are published before the first live send, and that marketing and transactional streams use distinct sending identities.

PostgreSQL backups and recovery

PostgreSQL is listmonk's only required dependency, so it holds the subscriber lists, templates, campaign history and send logs. Define backup frequency, retention, encryption and a tested restore procedure in your own infrastructure. Ask whether the transactional logs you need for dispute handling are included in backups and how long they are retained for your records policy.

Monitoring and deployment packaging

listmonk ships as a standalone binary, a Docker image on Docker Hub and a sample docker-compose.yml, so the deployment pattern can follow your existing container or VM standards. Monitor queue depth, send errors, bounce rates and relay health, and alert on a sudden drop in delivery. Confirm which metrics your monitoring stack can collect and who receives alerts outside working hours.

Why transactional and marketing streams need separate sending identities

A complaint spike in a newsletter can damage the sending reputation that password resets and receipts depend on. Mailbox providers evaluate senders at the level of the domain and, in many cases, the sending IP address, so a marketing campaign that draws spam complaints or high bounce rates does not stay contained to the newsletter. When a single shared identity carries both, a poorly performing list can push a one-time password email into the spam folder, and the application team usually learns about it from a support ticket rather than a dashboard. The practical question for your team is not whether this can happen, but how far the damage would travel and how quickly you would see it.

Separation in practice means giving each stream its own identity at every layer. Use distinct subdomains for transactional mail (for example, a subdomain used only by the application) and for campaigns, each with its own authentication records. Issue separate sending credentials, such as distinct SMTP users or API keys on your relay, so that a leaked or misconfigured newsletter credential cannot send application mail. In listmonk, the transactional mail API and campaign sending should be configured and monitored as separate paths, with rate limits and queues sized for each, so a large campaign does not delay time-sensitive messages. Suppression handling also needs to be split: a campaign unsubscribe must not block a password reset, but a hard bounce on a transactional address should be visible to the application so it can be corrected.

Confirm the specifics with your sending service and your mailbox provider documentation before you finalize the design, because the rules for bulk senders change over time. The sibling topic on meeting Gmail and Yahoo bulk sender requirements sets out the authentication, unsubscribe and complaint thresholds that apply to the marketing stream. Ask your implementation partner to document which identity, credential and suppression list each email type uses, and to test a complaint scenario in a non-production environment before go-live.

How the rollout moves from sending domain to live alerts

This sequence takes a transactional email platform from a sending domain with no records to a live service that sends receipts, resets and alerts with authentication, tested inbox placement and monitoring in place before go-live. Each phase closes with a named artifact the next phase depends on.

Set up the sending domain and authentication records
Decide which subdomain will send transactional mail so it can be kept separate from marketing traffic, then publish SPF, DKIM and DMARC records for it with your DNS team. DeployOpen's engineers confirm alignment against the sending service you use, and the client's domain owner approves the record set. Done means a working DNS record set is live, DKIM signing is confirmed on test messages, and the DMARC policy is recorded with a reporting address you monitor.
Deploy listmonk and connect single sign-on
Deploy listmonk into your own cloud account, data center or air-gapped network with PostgreSQL as its database, following the project's documented Docker or binary options. Configure OIDC single sign-on with your identity provider, then assign granular roles and create API tokens only for the services that need them. Done means administrators log in through SSO, a test role cannot reach restricted functions, and the deployment configuration is stored in version control.
Define templates and the API contract
Agree with product and support owners which messages exist (receipts, password resets, account alerts), what data each one needs, and who may change each template. Build the templates in listmonk's transactional mail API, using its Go template functions, and store them in a versioned repository with a change log. Done means a versioned template library and a written API contract document that application teams sign off before integration begins.
Integrate the relay and webhook feeds
Connect listmonk to the SMTP relay or sending service your domain is authorized for, and configure the rate limits and queues to match expected traffic. Route bounce and complaint notifications back to the platform so suppression lists update automatically. Done means application calls succeed in a staging environment, bounce and complaint events reach the suppression list, and credentials for the relay are stored in your secrets manager rather than in configuration files.
Test inbox placement with seed mailboxes
Send each template through seed mailboxes at the major mailbox providers your users rely on, and check authentication results, spam folder placement, rendering across clients and link behavior. Testers record failures and retest after each fix. Done means a written test report lists each template, provider and result, with every blocking issue closed or formally accepted by the owner.
Configure monitoring and alert thresholds
Set up dashboards for send volume, delivery failures, bounce and complaint rates, queue depth and API error rates, then define the thresholds that trigger an alert and who receives it. Confirm that alerts fire by triggering a controlled test. Done means a runbook documents each alert, its owner, the first response steps and the escalation path, and the on-call team has acknowledged it.
Go live with a tested rollback plan
Switch application traffic to the new platform in a controlled change window, keeping the previous sending path available until results are confirmed. Watch the monitoring dashboards and the first live messages closely, and follow the rollback steps in the runbook if a threshold is breached. Done means the rollback has been rehearsed, live messages are arriving with correct authentication, and the owner signs off that the service is operating under the runbook.

Evidence an auditor or security reviewer will ask for

This table lists the records a security reviewer or assessor typically asks to see for a self-hosted transactional email service, the component that produces each one, and what to check before sharing it. Use it to plan evidence collection from day one rather than reconstructing it during an assessment. DeployOpen prepares these artifacts, but independent auditors and certification bodies issue any audit opinion or attestation.

Evidence artifact	Produced by	What the reviewer checks	Gap to confirm early
DNS authentication records and validation	DNS zone and sending domain configuration, plus listmonk sending settings	SPF, DKIM and DMARC records exist, align with the sending domain and pass on live test messages	Whether the sending service signs with your domain or its own, and who controls DNS changes
Access logs for the transactional API	listmonk application logs and the reverse proxy in front of it	Which token or user called the API, when, from which source, and with which template	Log retention period and whether logs hold recipient addresses that need masking
API token inventory	listmonk user and API token administration	Each token has a named owner, a scope, a creation date and a last-used date	Tokens shared between applications or never rotated
Template version history	Git repository holding template files, or listmonk template records	Who changed each transactional template, when, and which version was live at send time	Whether edits made in the admin interface are captured outside the database
Bounce and complaint logs	listmonk bounce records and the sending service's feedback notifications	Hard and soft bounces are classified, and complaints are linked to the affected recipient	Whether the sending service forwards complaint feedback to listmonk automatically
Suppression list exports	listmonk subscriber status and blocklist records	Addresses that bounced, complained or opted out are blocked from later transactional sends	Whether suppression applies to both the marketing and transactional streams
Backup and restore test results	PostgreSQL backup jobs and the restore runbook	A dated restore test shows templates, subscriber status and token records come back intact	Frequency of restore tests and who signs off the result
Sending service data processing terms	Contract and data processing agreement with the sending service provider	Scope of personal data processed, sub-processors, data location and deletion commitments	Whether the agreement covers the region and sub-processors your regulator expects

What teams ask before running transactional email themselves

What drives the effort of self-hosting transactional email?

The effort follows the number of applications sending mail, the number and complexity of templates, the relay you choose, and whether your existing email service provider stays in place. Each sending application needs its own stream, credentials and template set, and each template needs testing across mail clients. A team that keeps one relay and migrates two templates faces far less work than one that moves five applications, retires a hosted provider and rebuilds its bounce handling. Ask any implementer to list these inputs in the written scope so the quote reflects your actual estate rather than a generic newsletter setup.

Can an in-house team with email operations experience run this internally?

Yes, a team that already runs mail infrastructure can usually handle listmonk's transactional API and templates, provided it has time for the parts that are easy to underestimate. These include sender authentication, bounce and complaint processing, separating transactional traffic from marketing traffic, and watching reputation over time. The question is less about skill and more about capacity. Someone must own the work after launch, respond when a mailbox provider changes its rules, and keep the platform patched. If that person is already committed elsewhere, an implementation partner can cover the build while your staff takes over operations.

What does the work need from our side before it starts?

The work needs four things from your organization before it can start:

DNS access to publish records for the sending domain or subdomain
Confirmed ownership of the sending domain, including who approves changes
A named owner for bounce and complaint handling who can act within a set working day
Access to the applications that will call the transactional API, with a contact for each

Without the DNS and domain items, authentication cannot be completed, and mail may not reach inboxes. Confirm these early, because they often sit with different teams.

How does the timeline depend on the fixed scope?

Most engagements are fixed-scope, so the timeline is set in writing before work starts and depends on the scope you agree. The scope defines the applications in scope, the templates to build or migrate, the relay and its configuration, the monitoring to deliver, and the acceptance tests. Changes after signing, such as adding a new application or a second relay, change the scope and the schedule. Ask for the timeline as milestones tied to named deliverables, and ask what the client must provide for each milestone, since DNS changes and approvals are common delays.

Does listmonk's free license remove the cost of transactional email?

No. listmonk is licensed under AGPL v3, so the software itself carries no license fee, but running it still costs money. You pay for the hosting that runs the binary and PostgreSQL, for the sending relay that delivers the messages, for the staff time to configure and operate it, and for any implementation work. Relay pricing usually depends on message volume, which means the bill rises as your product grows. Note that AGPL obligations apply if you modify and offer the software over a network, so confirm the terms with your legal team before you change its code. Ask any partner to break the quote into infrastructure, relay, labor and recurring support.

What recurs after go-live, and who pays for it?

Three recurring items need budget and an owner after launch:

Upgrades to listmonk, the database and the operating system, tested against your templates before rollout
Relay fees, which scale with volume and may change if you move to a different sending service
Monitoring and reputation work, including reviewing bounces, complaints and authentication results

These run for the life of the platform. A retainer for upgrades and continuous monitoring is one option, and your own staff can cover them instead. Either way, agree on who receives alerts and how quickly they must respond.

Can we keep our existing email service provider while adding listmonk?

Yes, many teams keep their current provider for a period and route transactional messages through listmonk's API, or keep listmonk as the send layer and point it at the provider's SMTP servers. This is a common migration path because it lets you move one application at a time. The decision depends on whether the provider's contract, data processing terms and sending reputation are acceptable for the streams you move. Confirm the provider's SMTP and API details, its sending limits and its data terms before you commit to a split.

What to ask an implementation partner before signing

Start with stream separation, because it decides almost every other answer. Ask the partner to show, in writing, how transactional sends and marketing campaigns will use different sending domains or subdomains, different from identities, different listmonk lists or API token scopes, and separate bounce and complaint handling. Ask which of these controls it will configure on day one and which it will leave for your team to decide. A partner that cannot name the settings it will change in listmonk, and where Dittofeed fits if you also run journeys, has not yet scoped the work.

Next, ask which relay the partner will integrate and who holds the credentials. Ask whether it will connect listmonk to an SMTP relay or an HTTP sending API, how it will rotate those secrets, and what it will do if the relay suspends the account. Ask how it will test inbox placement before go-live, which seed accounts or third-party tools it will use, and what written result you will receive. Ask who owns DNS changes for SPF, DKIM and DMARC records, who approves each change, and who keeps the change log, because a mismatch here blocks delivery no matter how well the application is built.

Then ask about maintenance and exclusions. Ask how the partner will handle listmonk and Dittofeed version upgrades, including whether it tests on a staging copy, how it confirms that templates and the transactional API still behave after an upgrade, and how long it will keep older releases in place. Ask the partner to list in the written fixed scope what it does not cover, such as application code that calls the API, template copy, legal wording, or mailbox provider complaints. Finally, ask what support continues after go-live, who answers alerts at night, and whether the retainer covers monitoring of bounce rates, failed sends and certificate or DNS expiry.

How DeployOpen scopes and runs a transactional email build

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For transactional email, that means a written scope that covers the sending stack, authentication records, templates and monitoring, agreed before work starts.

How we scope

We confirm which application events send mail and which templates and transactional API calls each one needs.
We document the sending path, including whether listmonk relays through your SMTP service and who owns the sending domain.
Engagements are fixed-scope, and the written scope names deliverables, timelines and what sits outside the build.

How we build

We deploy listmonk in your environment with PostgreSQL, separate transactional and marketing streams, and access controls for template editors.
We configure SPF, DKIM and DMARC records with your DNS team and check alignment before the first live send.
We test bounce handling, rate limits and template rendering in a staging environment before any production traffic is sent.

How we hand over

We document the architecture, DNS records, template versions, API token ownership and runbooks for bounces and complaints.
We walk your operations and engineering staff through alerting, log review and how to roll back a template change.
We provide the evidence pack for your own auditors, which covers configuration, access and change records for review.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
We apply listmonk upgrades in a staging environment, using the release notes to confirm changes to the transactional API.
We rerun authentication checks and template tests after DNS, sending service or platform changes that affect delivery.