# django-newsletter: mass mailing that lives inside the Django admin

> django-newsletter is a Django application for running multiple mass-mailing lists, with plaintext and HTML templates, a rich text editor, image handling, web subscription pages and a queue for sending, all managed from the admin interface. It supports Django 4.2 and 5.2 on Python 3.9 through 3.13, and it is released under AGPL-3.0-or-later.

**jazzband/django-newsletter** — An email newsletter application for the Django web application framework, including an extended admin interface, web (un)subscription, dynamic e-mail templates, an archive and HTML email support.

- Repository: https://github.com/jazzband/django-newsletter
- Stars: 925 · Forks: 208
- Language: Python
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/jazzband-django-newsletter

## Subscribers, templates and campaigns in one admin

django-newsletter is a Django app for managing multiple mass-mailing lists, and the defining decision is that all of it happens inside the Django admin interface. That is the whole pitch: a Django site that already has user accounts can run newsletters against the same database, write the templates in a rich text widget, and let staff assemble and send a campaign without an external tool. The feature set described in the README covers both plaintext and HTML templates, rich text widget integration, images and a smart queueing system, and the project description also lists an extended admin interface, web subscription and unsubscription, dynamic email templates, an archive and HTML email support. That combination is aimed at publishers and community organisations rather than marketing teams: the point is that the mailing list is a first-class Django model with its own admin screens, not a CSV export feeding somebody else's platform.

## Two template formats and pluggable editors

The templates are the part users touch, so their design is worth reading closely. The package supports both plaintext and HTML templates, and the project metadata describes the app as providing plaintext as well as HTML templates with pluggable WYSIWYG editors for messages. Pluggable is the important word: the optional test extra installs django-tinymce and django-imperavi, which means the rich text editor used to compose a message is a configuration choice rather than a hard dependency. The `contrib/` directory in the repository tree is where such additions live, and the thumbnail dependency is likewise pluggable, since the README states you need to install either sorl-thumbnail or easy-thumbnails to use the thumbnailing feature. Images inside a message therefore depend on a thumbnailer being configured, which is a genuine deployment step rather than a detail, and a site that installs neither gets no image handling in its templates.

## The queue is what makes a large send survivable

The smart queueing system is the mechanism behind the project's only concrete performance claim in the README, and it is worth being precise about what that claim is. The README states that fairly extensive tests are available for internal frameworks, web subscription and unsubscription, and mail sending, and that sending a newsletter to large groups of recipients, more than 15k, has been confirmed to work in multiple production environments. That is a statement about the queue absorbing a big recipient list without the request timing out, and it is why the app can be run inside a normal Django deployment rather than needing a separate sending service. It also sets a boundary for what to expect: the project is describing sends in the tens of thousands, in an environment where mail sending is already configured, not a high volume transactional mail system. Anything that needs per-recipient analytics or deliverability tooling at scale is asking for a different kind of tool.

## Subscription pages and list imports

Web subscription and unsubscription are part of the package rather than something you build, which matters for a site that wants opt-in without a custom form and a privacy workflow. Imports cover the three formats a mailing list usually arrives in, and each needs a dependency installed separately. LDIF files are read with python-ldap, CSV files with unicodecsv, and vCard files with python-card-me. Those three optional dependencies sit in the test extra of the project metadata, and the README is explicit that additional dependencies need to be installed separately for those features to work. The chardet dependency in the core requirements list is the encoding detection layer that makes those text imports behave predictably across files saved with different character sets. This is a sensible division of dependencies: a site that only needs templates and a queue installs three packages, while a site migrating an existing list installs the importer it actually needs.

## What the package requires from your project

The requirements are listed in the project's `pyproject.toml`, and the core set is short:

```toml
dependencies = [
  "Django>=4.2",
  "chardet",
  "Pillow",
]
```

Pillow is there for image work, and Django itself is a hard requirement at 4.2 or later. The README does not give a copy-paste install recipe for the package itself, and it points instead at the `pyproject.toml` for an updated list of required packages, and at the extended documentation on Read the Docs for configuration, including the settings page that covers configuring thumbnailing applications. The build backend is setuptools with setuptools_scm, so the version is derived from the repository state rather than written by hand, and the packaging metadata excludes the `tests` and `test_project` directories from the distributed package. A `tox.ini`, a `uv.lock` file and a `test_project/` directory in the tree indicate a conventional multi-version test setup for a library that supports several Django and Python combinations.

## The supported version window is narrow and deliberate

Compatibility is stated precisely: django-newsletter officially supports Django 4.2.x LTS and 5.2.x LTS, and Python 3.9 through 3.13. The project metadata matches, listing Django 4.2 and 5.2 as supported framework versions and Python 3.9 to 3.13 as supported interpreters, with a `requires-python` of 3.9 or higher. The classifier in the metadata describes the development status as mature, and the README adds a candid note that the package is used in several large to medium scale production environments but should be considered a permanent work in progress. For an adopter, the practical consequence is a familiar Django trade-off: you get an app that is tied to specific LTS releases, and when a new Django LTS arrives you may wait for a release that widens the window. The alternative, writing the list, templates and queue inside your own project, avoids the version constraint but means owning every part of the sending path.

## AGPL, Jazzband and a steady release line

The licence is the item that most often decides adoption, and here it is AGPL-3.0-or-later, stated in both the README and the project metadata with the `LICENSE` and `COPYRIGHT` files shipped in the tree. That is the strongest copyleft licence in common use, and for a project that runs as a networked service it can reach beyond the server code into how you offer the service. Whether that matters for your deployment is a question for your own legal review, not something this article can decide, but it should be checked before the package enters a product. On governance, the project lives under the Jazzband organisation, which handles releases for Python projects, and the release line is regular: v1.0 on 2024-12-11, v1.1 on 2025-09-08 and v1.2 on 2025-10-03, with the last push on 2026-10-14. Translations are handled through Transifex and are said to be fully translated into many languages, with contributions welcome and strings included once coverage is close to complete, which is a realistic statement about the state of a volunteer-run translation effort.

## Conclusion

django-newsletter fits a Django team that already owns its user accounts and wants newsletters to read from the same database, with templates edited by staff in the admin rather than by engineers in a separate campaign tool. It does not fit teams without a Django application, teams that want delivery infrastructure handled for them, or organisations that cannot accept an AGPL-3.0-or-later dependency in a networked service. Before adopting it, confirm your Django version is 4.2.x or 5.2.x and your Python is between 3.9 and 3.13, install a thumbnailing backend since one is required, and check the v1.2 release notes, since the last push was on 2026-10-14 and the project describes itself as a permanent work in progress.

## FAQ

### What does django-newsletter actually do?

It is a Django app for managing multiple mass-mailing lists, with plaintext and HTML templates, rich text widget integration, images, a smart queueing system, web subscription and unsubscription, and an archive, all handled from the admin interface.

### Which Django and Python versions are supported?

The README states that django-newsletter officially supports Django 4.2.x LTS and 5.2.x LTS, and Python 3.9 through 3.13. The project metadata requires Python 3.9 or higher and Django 4.2 or later.

### Do I need extra packages for images and imports?

Yes. You need one of sorl-thumbnail or easy-thumbnails for thumbnailing. Importing lists needs python-ldap for LDIF files, unicodecsv for CSV files and python-card-me for vCard files, all installed separately.

### Under what licence is django-newsletter released?

The README and the project metadata both state AGPL-3.0-or-later, with the LICENSE and COPYRIGHT files included in the repository.

## Sources

- [Issues](https://github.com/jazzband/django-newsletter/issues)
- [jazzband/django-newsletter on GitHub](https://github.com/jazzband/django-newsletter)
- [License: AGPL-3.0](https://github.com/jazzband/django-newsletter/blob/master/LICENSE)
- [README](https://github.com/jazzband/django-newsletter/blob/master/README.md)
- [Releases](https://github.com/jazzband/django-newsletter/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jazzband-django-newsletter