Maildun/maildun

Self-hosted email marketing, transactional email, and automations for teams — on your own infrastructure.

Maildun is a single application for the whole outbound email lifecycle: audiences and subscribe forms, campaigns built in a visual editor, transactional email behind a JSON API, event-driven automations, and first-party open and click tracking. It runs on your servers, sends through your Amazon SES or SMTP account, and keeps subscriber data out of third-party hands.

It is built for teams that have outgrown a hosted newsletter tool, or that cannot hand a customer list to one in the first place.

• Audiences — custom attributes, tags, segments, list hygiene, double opt-in, CSV imports, and hosted subscribe forms with configurable branding
• Campaigns — visual email builder, reusable templates, scheduling, attachments, test sends, and per-campaign engagement insights
• Transactional email — reusable templates published behind a team-scoped, versioned JSON API
• Automations — event-based flows with timers, driven by durable jobs that resume after a restart
• Delivery — Amazon SES or SMTP, configured and verified per workspace, with bounce and complaint processing for SES
• Tracking — first-party open and click tracking with optional local geolocation databases; no third-party pixels
• Teams — workspaces, invitations, roles, two-factor authentication, and passkeys
• Operations — local or S3-compatible media storage, Redis-backed queues with Laravel Horizon, and a local and OAuth-protected remote MCP server for AI-assisted workspace operations

Laravel 13 · Inertia 3 · React 19 · TypeScript · Tailwind CSS 4 · Redis · Laravel Horizon · Pest

Maildun deliberately separates two kinds of outbound email:

• System email uses the application-wide MAIL_* environment settings for account verification, password resets, workspace invitations, and operational notifications.
• Workspace email uses one delivery connection per workspace for campaigns, automations, and transactional email. The connection is tested first; every exact sender address is then verified against that connection.

Adding a sender or provider in workspace settings does not configure system email. A self-hosted installation must configure a working application-wide mailer before enabling registration or inviting other users, then configure each workspace provider before sending to its audience.

git clone https://github.com/Maildun/maildun.git
cd maildun
cp .env.example .env
# Review the database, Redis, storage, and system MAIL_* values in .env.
touch database/database.sqlite
composer setup
composer dev

Start Redis before running the installer. The example environment expects a local SMTP relay at 127.0.0.1:2525; start one for local development or set MAIL_MAILER=log. For a public installation, replace the example MAIL_* values with a real system mail relay before running the installer.

composer setup installs dependencies, runs the interactive app:install command, and builds the frontend. composer dev starts the web server, Vite, Horizon, and the log viewer. Open http://localhost:8000 and sign in with the administrator account the installer created.

For automation timers, segment synchronization, tracking recovery, and cleanup tasks, also run:

php artisan schedule:work

To explore with sample audiences and campaigns, pass --demo to the installer. It never adds demo data unless asked, and refuses to on production without --force.

Dockerfile and docker-compose.yml bring up the web server, Horizon, the scheduler, PostgreSQL, and Redis together:

cp .env.example .env
docker compose run --rm --entrypoint php app artisan key:generate --show   # paste into .env, and set DB_PASSWORD
docker compose up -d
docker compose exec app php artisan app:install --no-interaction \
    --admin-name="Your Name" --admin-email=you@example.com \
    --admin-password='a-strong-password' --registration=closed

See the installation guide for system mail configuration, a manual setup, demo data, and common problems.

A production deployment needs more than a web process. Keep Horizon supervised, run Laravel's scheduler every minute, configure both the application-wide system mailer and each sending workspace, and back up the database, APP_KEY, and uploaded files.

Read the production deployment guide and configuration reference before exposing an installation to the internet. New public installations should normally use invitation-only registration:

php artisan app:install --registration=closed

Run the same checks used by continuous integration:

composer validate
composer ci:check
composer audit --locked
pnpm audit --audit-level=high

composer ci:check runs ESLint, Prettier, PHPStan, Pint, and the Pest suite. Maildun is maintained hands-on right now: contributions come in as issues, and pull requests are accepted by prior agreement only. See CONTRIBUTING.md for how that works, test expectations, and licensing of contributions. Participation is governed by the Code of Conduct.

• Bugs and feature requests — open a GitHub issue.
• Security vulnerabilities — use private vulnerability reporting, never a public issue. See SECURITY.md.
• Commercial licensing — see Removing the attribution below.

Operators are responsible for consent, unsubscribe handling, sender identity, retention, and compliance with the laws and provider policies that apply to their recipients. Maildun is not a substitute for legal advice, a sending reputation program, or abuse monitoring.

Copyright (C) 2026 Dunn.

Maildun is free software licensed under the GNU Affero General Public License, version 3 (AGPL-3.0-only), with additional terms under section 7 stated at the top of LICENSE.

You may run, study, modify, and redistribute Maildun, including commercially. Hosting it for other people is allowed. The conditions are:

• Keep the attribution. Every interface must show a "Powered by Maildun" link to the source of the version you are running — in the app itself and on every public page (subscription forms, confirmation pages, unsubscribe pages). You may restyle it; you may not remove or hide it.
• Publish your changes. If you modify Maildun and let anyone use it over a network, section 13 requires you to offer those users the complete corresponding source of the version you are running. Point APP_SOURCE_URL at it.
• Do not pass it off as your own. Modified versions must be marked as different from the original and offered under a different name. No rights are granted to the Maildun name or logo.
• Derivative works stay under the AGPL.

Running an unmodified Maildun — for your own organization or as a hosted service for others — obliges you only to leave the attribution in place.

The attribution and naming conditions are the only things standing between Maildun and a white-labeled resale of it. If you want to ship Maildun under your own brand, with the notice removed, that needs a separate commercial license: werk@abduns.com.

Third-party packages, artwork, and trademarks remain subject to their own terms; see Third-party notices.