11 Best Open-Source Bulk Email Tools in 2026
For developers choosing a self-hosted bulk email stack, listmonk and Keila handle newsletters, Mautic and Dittofeed handle automation, Sympa handles discussion lists, and Postal, ZoneMTA, and Haraka handle delivery. This comparison covers 11 open-source tools, their licenses, APIs, deployment components, and the sending infrastructure you'll still need to operate or buy.
Quick picks by the job you need done
Start with listmonk for a developer-operated newsletter, or Keila when the campaign editor is the deciding factor. Choose Mautic for contact-centric marketing automation and Dittofeed for journeys driven by application events. Use these category links to jump straight to the relevant tool:
- Newsletters: listmonk · Keila.
- PHP campaigns: phpList · SendPortal.
- Automation: Mautic · Dittofeed · Plunk.
- Discussion lists: Sympa.
- Mail transport: Postal · ZoneMTA · Haraka.
Or jump to the comparison table, decision matrix, or cost breakdown.
For the newsletter shortlist, the listmonk vs Keila guide goes deeper into their APIs and deployment differences. The bulk email guide covers the surrounding sending pipeline.
Choose the layer your team needs to own
Open your scenario to separate application ownership from mail delivery. Each shortlist points to the relevant tools and the operating work that comes with them. You can compare several scenarios without losing an open recommendation.
I need newsletter editing and audience control, with delivery handled elsewhere
Start with a newsletter application: compare listmonk for developer-operated audience queries and Keila when the editor is the deciding factor. Both need application/database operations and a sending path; self-hosting the campaign app doesn't include a delivery network.
Use the listmonk versus Keila guide to narrow that pair. If Laravel integration is the requirement instead, inspect SendPortal's application/core boundary before adding a separate stack.
I need automated journeys driven by contacts or product events
Start with automation: compare Mautic for contact-centric campaign decisions and Dittofeed for product-event-driven journeys. Scheduled processing in Mautic and event/workflow services in Dittofeed are operational dependencies, not just optional editor features.
If an SES-backed combined campaign/workflow stack fits, inspect Plunk. For occasional newsletter editions, a focused campaign application is the smaller commitment; compare the hosting and transport costs before adopting automation.
My application prepares the messages; I want to operate mail delivery
Start with the transport layer: inspect Postal for an SMTP/HTTP delivery platform, ZoneMTA for outbound routing control, or Haraka for programmable SMTP hooks. Audience selection and campaign editing still belong upstream; your team takes on queues, connectivity, DNS, sending IPs, and feedback.
If you want audience control but not mail-network operations, keep the campaign application self-hosted and compare managed sending APIs. If members instead post to a shared list address, read Sympa's discussion-list model; that is a different application job, with a separate MTA still required.
Compare the software and its transport separately
All 11 tools below have an open-source software license and a self-hosting path. Their roles differ. A newsletter manager stores audiences and prepares editions; automation reacts to contacts or events; a discussion-list manager redistributes posts; a mail transfer agent (MTA) queues and delivers messages. Only some provide campaign editing.
This is a curated comparison of 11 options, not an exhaustive directory. Omission of another project, including GNU Mailman or Mailtrain, isn’t a finding about its license, maintenance, or suitability. Numbering makes the sections easy to find; recommendations depend on the job, not a universal rank.
Primary repositories and documentation were checked on October 14, 2026. License links refer to the named software, not every plugin, dependency, hosted plan, or enterprise extension. Component lists identify the deployment shape, not a measured minimum server size.
1. listmonk: a focused newsletter service for developers
listmonk puts audience queries and campaign state within reach of your application. Subscribers carry arbitrary JSON attributes, which you can query into lists and insert into Go templates. Its concepts documentation also separates a list subscription from the subscriber record: one address can belong to multiple lists with different subscription statuses.
That model is useful when your product already knows the audience attributes and you want to generate editions programmatically. The campaign API supports drafts, previews, scheduled sends, and running statistics. Status changes have rules: a running campaign can pause or cancel, while starting requires a draft or paused campaign. Design around those transitions rather than treating every status as freely assignable.
Deployment is a Go binary or container plus PostgreSQL. SMTP is the default messenger; custom HTTP messengers provide an extension point. Bounce processing can use a POP mailbox or supported provider feedback. Keep the database and uploaded assets in your backup plan.
Choose it for a focused newsletter service, with SQL-based segmentation as a strength. If your main requirement is a branching journey canvas, compare the automation entries instead. The AGPLv3 license and installation guide establish the software and self-hosting scope.
2. Keila: newsletters with an editor-oriented workflow
Keila’s appeal is the newsletter workflow: campaign editing, forms, and segmentation share a dedicated application. It’s a candidate when people preparing editions need that interface, while your product integrates through the JSON API-style API. Bearer keys give access to contacts and campaigns, including scheduling and delivery actions.
The Sender model makes transport selection explicit. Create an SMTP, SES, SendGrid, Mailgun, or Postmark sender before sending a campaign. “Send with Keila” is a Cloud option; self-hosted installations bring their own service. This gives you provider choice, but no bundled delivery infrastructure.
Run the container with PostgreSQL and forward WebSockets through your reverse proxy, as the requirements specify. Compare its editor and API resource model with listmonk rather than assuming their interfaces are interchangeable. Keila’s AGPLv3-or-later grant excludes its logo and extra files.
3. Mautic: campaigns built around contacts and decisions
Mautic earns its larger application footprint when emails are steps in a contact’s campaign rather than independent editions. Its email model has a distinction worth checking before integration:
- Template emails are used by campaigns, form actions, and other components, and can reach the same contact repeatedly.
- Segment broadcasts target selected segments, including exclusions; each contact receives that email only once.
- Reply decisions can advance a campaign after Mautic detects a contact’s response through a monitored mailbox. That requires the documented IMAP setup and fetch processing.
These are different execution paths, not merely editor options. For example, sending a template directly from a contact profile clones its content, so statistics don’t accrue against the original template. Scheduled broadcasts also rely on cron. Those details matter if your application expects one template ID to represent all sends.
Install a production package or Composer-managed deployment with PHP, a database, scheduled processing, and SMTP or a provider transport. Administrators enable the JSON REST API separately. Mautic’s GPLv3-or-later project suits contact-centric automation; for an occasional newsletter, the campaign jobs, segment updates, and extensions are additional machinery to maintain.
4. phpList: standalone campaigns on a PHP stack
For an existing PHP/MySQL environment, phpList offers a standalone campaign manager with personalization, scheduling, and domain-based throttling. Its repository documents pause, resume, repeat, and requeue operations, plus bounce handling. Installation deploys the lists directory, configures the database, and initializes the administration interface.
Two settings deserve attention during setup. The shipped configuration enables TEST, which displays intended sends instead of actually sending. It also falls back to PHP’s mail() when no SMTP host is configured. Set the transport deliberately and arrange queue processing through cron or the command line. Bounce collection has its own POP or mbox configuration.
phpList’s plugin architecture is useful for extending a working campaign system, but adds a compatibility boundary for integrations. The official REST API plugin targets phpList 3; check the plugin alongside your application release. The campaign manager is AGPLv3.
5. Sympa: shared-address mailing lists and moderation
Sympa serves members posting to a shared address: it redistributes messages and manages subscriptions, moderation, and archives. Those list-management functions make it relevant to communities and institutions, but don’t supply the edition-composition workflow of a newsletter application.
Its SOAP/HTTP API exposes operations such as reviewing membership, subscribing, adding members, and creating lists. Authorization follows the same scenario rules as the mail and web interfaces. An application integrating with Sympa therefore needs to model list privileges, not just obtain a send key.
Operate Perl, SQL, spools, a separate MTA, and the web server together; the requirements include mail-domain DNS and SMTP connectivity. This is mail-system integration rather than an isolated campaign container. The project-specific source notice grants GPLv2-or-later.
6. Postal: an SMTP and HTTP delivery platform
Postal supplies the delivery platform behind your application: SMTP submission, HTTP sending, and delivery-oriented administration. A campaign manager can sit upstream; subscriber segmentation and newsletter composition belong there rather than in Postal.
The HTTP API accepts either individual message attributes or a complete raw message, authenticated with X-Server-API-Key. Its send response includes a message ID and a map of recipient addresses to their individual message IDs and tokens. That gives an integration recipient-level identifiers, rather than only an opaque campaign ID. The API doesn’t cover every administrative function.
Current prerequisites specify containers, MariaDB, and outbound port 25. MySQL isn’t supported in place of MariaDB. Run the application and workers, provision sending domains, and retain message data. Choose this MIT-licensed platform when owning transport is intentional: sending IPs, DNS authentication, deferrals, and reputation become part of your operations. For merely composing newsletters, it adds the wrong layer.
7. ZoneMTA: routing control for outbound mail
ZoneMTA’s distinguishing unit is the sending zone, which groups routing, sending IPs, and connection settings. Its README describes selection by explicit zone headers, other headers, sender domain, or recipient domain. This is useful when different message streams need different outbound handling, while audience selection remains upstream.
Start from its Node.js application template with MongoDB and Redis. SMTP or the enabled HTTP interface accepts messages; JSON /send and raw /send-raw are separate submission forms. MongoDB stores message bodies and per-recipient queue entries, while Redis supplies locking and counters. Install the web administration interface separately.
Pay particular attention to delivery semantics. ZoneMTA retains queued work until the destination acknowledges it, but a lost acknowledgement can produce a duplicate. Its documented connection limits also don’t establish a global per-domain message-rate ceiling. Those are concrete integration constraints for an outbound MTA. Licensing is EUPL 1.2-or-later, with the EUPL text here.
8. Haraka: programmable SMTP handling
Haraka exposes JavaScript hooks at SMTP stages such as connection, recipient, data, and queue processing. That’s the reason to choose it: application-specific SMTP decisions can live in plugins, as the README explains. Its native interface is SMTP, not an HTTP campaign API.
Install via npm, initialize a service directory, and select domains and plugins. Default local-domain handling uses smtp-forward; authorized messages marked for relaying can use the built-in outbound queue. These are distinct paths to configure. Haraka doesn’t provide a mail store or IMAP service, and campaign state needs an upstream application.
The server is MIT-licensed. Keep plugin maintenance, relay authorization, TLS, and queue monitoring in scope when choosing this programmable approach over a delivery platform with more administration built in.
9. Plunk: campaigns and workflows backed by SES
Plunk combines transactional sends, campaigns, and workflows around an SES-backed sending path. Its current README also lists SMTP submission, segments, and contact activity. That combination can consolidate app-triggered messages and newsletter editions, provided AWS integration fits your deployment.
There are two useful boundaries in the API contract. The secret bearer key authorizes sending and campaign management; the public key is limited to event tracking. Public /v1/send and /v1/track responses use a success/data envelope, while dashboard resources return objects directly. Campaigns have their own create and send/schedule actions. Don’t design one response parser around all these interfaces.
For self-hosting, the Compose guide includes PostgreSQL, Redis, MinIO, ntfy, and the app with nginx. SES setup adds IAM credentials, configuration sets, and an SNS feedback callback. Plunk’s SMTP endpoint accepts mail from existing clients; SES still performs delivery.
The practical limitation is a multi-service stack tied to AWS rather than interchangeable transport. Current instructions use next and the GitHub container image, so match those docs to your chosen release. The AGPLv3 application and SES usage remain separate budget items.
10. Dittofeed: journeys driven by application events
Dittofeed starts with identity and activity rather than an edition. Its Segment-compatible source API accepts identify, track, page, and screen events, authenticated with a write key over HTTP Basic. Existing event instrumentation can therefore supply the inputs for segmentation and journeys without routing through a third-party data source.
The public core includes broadcasts, automated journeys, templates, and message channels beyond email. For email, choose a provider integration or SMTP. Event ingestion is one interface; delivery credentials are another. This makes Dittofeed relevant when messaging decisions follow product behavior, but brings little benefit if you only need to send a prepared edition to a static list.
Its lite Compose manifest still contains PostgreSQL, ClickHouse, and Temporal, plus storage services. “Lite” isn’t a synonym for one process. Plan for event retention and workflow-service health as well as the ordinary application/database backups; the self-hosting guide explains the deployment path.
The license boundary is also decisive. Broadcasts and journeys belong to the MIT core; multi-tenancy, embedding, and white-labeling belong to the separately licensed closed-source offering described in the README. If your requirement is to embed a campaign builder into your own product, the MIT license alone doesn’t supply that feature set.
11. SendPortal: a campaign layer for Laravel teams
SendPortal offers two adoption paths: run the standalone application with authentication and workspaces, or add SendPortal Core to an existing Laravel application that already handles users. That package boundary is a concrete advantage for a Laravel team, rather than a reason to introduce Laravel into an unrelated stack.
The v4 requirements are PHP 8.3+, Laravel 13, Composer, and MySQL or PostgreSQL. Its queue configuration lets you choose synchronous, database, or Redis processing. Database queues avoid another service but can compete with application queries; Redis adds a service and supports Horizon. Asynchronous operation requires workers for both message dispatch and incoming webhook processing, plus the scheduler.
Workspace API tokens use bearer authentication for JSON resources. Configure campaign SMTP/provider services per workspace; password-reset and invitation mail use separate application configuration. The application and core are MIT-licensed. Choose it for the campaign/package integration; the sending service remains a separate component.
Decide which responsibility belongs in your stack
Choose the category first, then the smallest operational footprint that satisfies the job. A developer who already has SMTP delivery usually needs a campaign application. A team whose application already selects recipients may need only delivery infrastructure. Event-driven journeys and member-posted lists introduce different state and routing requirements.
For newsletter-only work, compare the editor, audience query model, and campaign API. For automation, inspect event ingestion, journey state, delays, and failure visibility. For transport, inspect queue persistence, retry behavior, routing, and the feedback contract your upstream application will consume. An HTTP send endpoint alone doesn’t establish campaign management.
What open-source bulk email actually costs
Separate software licensing, mail transport, and application hosting in your budget. The licenses above let you run the listed open-source software without purchasing a proprietary application license. Commercial support, managed hosting, and separately licensed extensions are different purchases. None of that makes email delivery or database operation free.
- Software: track the license of the exact release and any plugins. MIT, GPL, AGPL, and EUPL impose different obligations, particularly when modifying or distributing software. Dittofeed’s enterprise features are outside its MIT core.
- Transport: an SMTP/API provider bills under its own service terms and may require a particular stream or product for campaigns. Plunk specifically adds SES usage. Direct-delivery MTAs replace that provider dependency with your own servers, IPs, connectivity, and delivery operations.
- Hosting and data: budget for application machines, databases, queue services, object storage, backups, logs, and maintenance. Dittofeed’s event store and workflow service have a different footprint from listmonk’s binary and PostgreSQL.
Self-hosting the campaign application is often the middle ground: you keep audience and template state while a managed sender operates delivery. Fully self-hosting both layers is also possible, but selecting Postal, ZoneMTA, or Haraka is a decision to operate mail infrastructure, not just a cheaper campaign editor.
License checks change the shortlist
A public repository isn’t enough to qualify as open source. Notifuse was considered for this list, but its current licensing statement says v40 and later use Business Source License 1.1, with conversion to AGPL after four years. Earlier v39.x releases remain AGPL; that doesn’t make the current release open source. SendPortal replaces it here.
The practical next step is to shortlist within one category, pin a release, and inspect its install manifest and API contract against your requirements. For app-controlled audience selection, see programmatic newsletters. For managed sending alternatives, the companion best bulk email APIs comparison covers the transport-side choice.
Source check: October 14, 2026. Recheck licenses, release-matched deployment instructions, and provider integrations before adopting a tool; this reference is scheduled for editorial refresh within 30 days.