phpList: self-hosted email campaigns with a plugin architecture and a queue

An application you host, with a hosted option alongside it

phpList is described as a fully functional open source email marketing manager for creating, sending, integrating and analysing email campaigns and newsletters, and the deployment model is stated plainly: deploy it on your own server, or get a hosted account. The project presents three things side by side, the community site, the hosted offering and a demo installation that is wiped and refreshed every hour. The scale figures in the README are historical but concrete: used in 95 countries, available in 20 languages, and used to send more than 25 billion campaign messages in 2018. The current release line is visible in the tags, with v3.7.0-RC5 and v3.7.0-RC4 as release candidates and v3.6.17 as the stable build, all published in August 2026 and June 2026. So a release candidate and a stable release sit side by side in the tag list, which is worth understanding before you pick one to install.

The message queue is the feature that matters at volume

The feature list leads with the operational pieces rather than the campaign editor. Message-queue management load-balances and throttles multiple accounts and campaigns, and tracks every delivery outcome. Domain-based throttling exists to comply with host-specific policies by defining custom rules, which is the mechanism that keeps a large send from tripping a receiving provider's limits. Automated bounce management and processing works on policy and regex-based handling, with every bounce accessibly archived so that a list can be cleaned automatically rather than by hand. Campaigns can be scheduled, paused, resumed, repeated and requeued. Content personalisation customises every message to individual subscriber attributes and preferences, and the messaging is that the customisation is computed per subscriber rather than being a template slot. The combination is what makes a self-hosted sender workable: the queue absorbs the burst, the throttle respects the destination, and the bounce handler keeps the list clean.

Analytics, segmentation and the plugin architecture

The remaining headline capabilities are analytics, segmentation, content personalisation, bounce processing, a plugin-based architecture and multiple APIs. Real-time analytics track message responses and subscriber behaviour, which is the part that distinguishes a campaign tool from a mailing list. The plugin architecture is what makes the thing extensible without forking it, and it is why a project of this age can still be worth running. Multiple APIs means it can sit inside a wider system rather than being an island, and the topic tags reflect the interfaces it exposes, with newsletter API and marketing API both listed, along with transactional email and bounce message handling as distinct concerns. The subscriber import and export path is CSV and Excel based and includes attributes and preferences, so a list can move in and out of the system without a migration service.

Sending a webpage and reading RSS feeds

Two features on the list are less common and worth knowing about. Send a Webpage does automatic remote HTML polling, conversion and dispatch, which means a campaign can point at a live page rather than at a static message body, and the tool fetches it and converts it. RSS feed support lets phpList be set up to read a range of RSS sources and send the contents to users on a regular basis, with the user deciding how often they want to receive them. That second one is a mailing list that publishes automatically from feeds you subscribe to, without anyone writing copy. Email attachments are supported as well, which is a feature that most modern mail providers have restricted and that a self-hosted sender can decide for itself. Amazon SES has built-in optimised support, which matters because SES behaves differently from a conventional SMTP relay in ways that otherwise show up as delivery problems.

Upgrading means a database dump and a file copy

The upgrade procedure documented in the README is worth reading in full before you plan one, because it is manual and the order matters. First, back up your database, with the example given as a mysqldump redirect into a phplist-backup.sql file. Second, copy your old configured files to somewhere safe, which are lists/config/config.php and possibly lists/texts/english.inc or another language.inc file if you edited it. Third, copy the files from the tar file to your webroot, and the README explains why the tar is structured the way it is: the configurable files have been put in their own directory, lists/config, so that this is the directory you keep between upgrades and it holds the only information you need to change for your own site. Fourth, copy your configuration files into lists/config or re-edit the new config file, because new features are sometimes added to it and it is better to use the new file and re-adapt it. An example .htaccess file exists in that directory, and the README says you should not allow access to it from the webserver at all.

What is in the repository

The repository layout shows a PHP application with the structure of a long-running project. There is public_html for the web root, a bin directory for the command line interfaces the README mentions, a composer.json and composer.lock for dependencies, and a scripts directory. Tests are configured with Behat, with a default.behat.yml file at the root, and there is a TESTING.md. The Docker side is handled with a Dockerfile.release and a docker directory, and the Docker Hub image is published under the phplist organisation with a semver tag scheme. There is a Vagrantfile for local environments, an INSTALL file, an UPGRADE file and a VERSION file, and a TODO file, which is a fair description of a project that documents its own outstanding work. The documentation lives in doc and there are separate docker and public_html trees. The licence is AGPL-3.0, with a COPYING file and a LICENSE file at the root.

Where phpList is the wrong choice

Four limits apply. It is a self-hosted application, so somebody has to run a web server, a database and a mail path, and somebody has to keep that patched and backed up, and the upgrade procedure above shows how much of the operational burden lands on you. The release line shows a 3.x version with release candidates and stable builds published in parallel, which is a sign of a codebase in maintenance mode rather than of one being actively modernised, and the admin interface and the plugin API reflect that era. The AGPL-3.0 licence is a genuine constraint for anyone who wants to modify it and offer the result as a service, since the copyleft reaches network use. And the sending side is your problem: you need a mail path that your recipients' providers will accept, whether that is SES, a relay or your own servers, and the deliverability work that goes with it is not something phpList does for you.

Editorial conclusion

Use phpList when you need to run your own email infrastructure and want campaign management, segmentation and analysis without handing your subscriber list to a hosted provider, since the queue, the throttle rules and the bounce handling are the parts that make bulk sending survivable. Do not adopt it expecting a modern SaaS interface, since the admin interface is old and the release line is still on a 3.x version with release candidates alongside stable builds. Verify first which branch you install, because v3.7.0 release candidates and v3.6.17 stable are published from the same period and they are not the same codebase, that your server meets the documented system requirements, and that you read the upgrade procedure's backup step, since the documented upgrade path is a file copy with a database dump and a separate configuration directory that has to survive the upgrade.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. phpList/phplist3 on GitHub
3. Project website
4. README
5. Releases