Self-hosted email marketing in 2026 — own your list, your sending, your costs.

§1 · Definition

What is self-hosted email marketing?

Self-hosted email marketing is the practice of running an email-marketing application — list management, campaign builder, automation flows, analytics — on your own server, alongside a sending pipeline you also control. The opposite is the SaaS model where a vendor (Mailchimp, Brevo, Constant Contact, Klaviyo, ConvertKit, MailerLite, Campaign Monitor) hosts the application and the sending infrastructure on your behalf, and bills you a recurring fee scaled to your subscriber count.

A self-hosted setup has three components, and you own the bottom two:

1. The application layer. An installable web app — typically PHP/Laravel, Go, Ruby, or Node — that handles subscriber lists, campaign drafts, automation triggers, click/open tracking, and the dashboard your marketers use. Examples: AcelleMail, Listmonk, Mautic, Sendy.
2. The sending pipeline. The mechanism that takes a queued message and hands it to a Mail Transfer Agent (MTA) which speaks SMTP to recipient mail servers. You can run your own MTA (Postfix, Postal, Haraka), use a relay-as-a-service (Amazon SES, SendGrid, Mailgun, Postmark, SparkPost), or both — depending on volume and your tolerance for IP-reputation work.
3. The infrastructure. A Linux VPS, a managed Postgres/MySQL instance, a Redis or beanstalkd queue, a domain you control, and DNS authority for SPF, DKIM, DMARC, and PTR records. A small list (under 50K subscribers) runs comfortably on a $5–$20/month droplet; larger lists scale horizontally with extra queue workers and read-replica DBs.

The trade you're making is administrative work for cost-per-send and data residency. SaaS vendors abstract steps 2 and 3 entirely; you pay them the abstraction tax in monthly fees that scale with subscriber count. Self-hosting recovers that tax in exchange for the time it takes to provision a server, configure DNS, and set up a sending relay — operations that are now down to under an hour for someone who has done it before, and a weekend for a first-timer with the documentation in front of them.

"Self-hosted" should not be conflated with "DIY from scratch." All of the major open-source platforms ship as turnkey installs — upload, configure DB credentials, point a domain. The DIY part is the sending relay and the DNS — and if you use Amazon SES (or any SMTP relay) the DIY part shrinks to one form filled out once.

§2 · Architecture

How a self-hosted email-marketing system actually works.

A campaign send walks through five stages. Understanding them is the prerequisite for picking platforms, picking a sending relay, and debugging deliverability when a campaign underperforms.

[Marketer's browser]
        │
        ▼  HTTPS POST /campaigns
[Web app — Laravel/Symfony/Go]  ◀── REST API also lands here
        │
        ▼  enqueue per-recipient job
[Job queue — Redis / beanstalkd / DB]
        │
        ▼  worker picks job, renders MIME
[Sending driver — SES/Mailgun/SMTP]
        │
        ▼  TLS, AUTH, DATA, .
[Mail Transfer Agent (MTA)]
        │
        ▼  SMTP to recipient MX
[Recipient mail server — Gmail/O365/Yahoo]
        │
        ▼  open pixel · click redirect · bounce · complaint
[Webhook back to web app] ◀── reputation feedback loop

Stage 1 — campaign authoring. The marketer writes a campaign in the web UI: subject line, sender name, list selection, content editor (drag-and-drop, MJML, or raw HTML). When they hit "send," the application creates a campaign record and enqueues per-recipient jobs to a background queue. Nothing leaves the server yet.

Stage 2 — queue + worker. Background workers pull jobs at the rate the queue is configured for (typically 5–50 sends/second per worker). The worker fetches the subscriber row, merges custom fields into the template, embeds a tracking pixel keyed by message-id, and rewrites every link to a click-tracking redirect. The result is a fully personalised MIME message ready to hand to a sending driver.

Stage 3 — sending driver. The driver is the adapter between your application and whatever transport you pick: an Amazon SES API call, a Mailgun HTTPS POST, a SendGrid Web API call, or a raw SMTP AUTH PLAIN handshake to your own Postal MTA. AcelleMail's sending-driver pattern, for example, defines a 5-method contract (connect, send, getDeliveryStatus, getCapabilities, validateConfig) that every driver implements — see /developers/sending-drivers for the full driver guideline. Built-in drivers ship for Amazon SES, SendGrid, Mailgun, SparkPost, Elastic Email, Gmail SMTP, and any generic SMTP server (8 vendors live in app/SendingServers/Drivers/Vendors/).

Stage 4 — MTA → recipient. The MTA (yours or your relay's) opens an SMTP connection to the recipient's MX server, presents itself with a HELO/EHLO, negotiates STARTTLS, authenticates DKIM-signing keys, and submits the message. The recipient mail server runs spam scoring, SPF/DKIM/DMARC verification, list-unsubscribe header processing, and either inboxes or rejects.

Stage 5 — feedback loop. Three signals come back, all asynchronous. Bounces arrive over SMTP (5xx codes for hard bounces, 4xx for soft) or via the relay's webhook. Complaints (recipient hit "spam") arrive via the Mailbox Provider's Feedback Loop or, again, the relay's webhook. Engagement (open pixel hits, click-redirect requests) arrives via plain HTTP back to your web app. The application uses these to update suppression lists, retire dead addresses, and feed campaign analytics. Acelle's webhook-event catalogue lives at config/webhook_events.php — it's the canonical list of events the application emits and consumes.

The shape is the same on every self-hosted platform, with one variable: where the queue and MTA live. AcelleMail's worker runs on the same box as the web app by default; Listmonk does the same; Mautic uses Symfony Messenger and supports separate worker boxes. Mail relay can be local (Postal on the same machine, Postfix on a sister box) or remote (SES, Mailgun) — that decision is the subject of §5.

§3 · Motivation

Why teams move from SaaS to self-hosted.

§4 · Cost math

What it actually costs at 5K, 10K, 50K, and 200K subscribers.

Assumptions: one campaign per subscriber per week (4.33 sends per month per contact), Amazon SES at the published $0.10 per 1,000 emails, a $5–$20/month VPS for the application, and either AcelleMail's $74 one-time Standard licence amortised over 36 months or a free open-source platform. Mailchimp Standard tier pricing is the published rate as of May 2026.

"Self-hosted" column = SES send fee + $5–$20 VPS + $2/mo amortised licence. Excludes setup time. Mailchimp Standard rates per mailchimp.com/pricing/marketing 2026-05.

What the math doesn't capture

The table is conservative on two axes and aggressive on a third. Conservative: it assumes one campaign per week — many lists send 2–4 per week, which doubles or quadruples the saving (sends are linear in count, the SaaS plan ceiling is the same). Conservative again: it doesn't model the savings from transactional email (password resets, receipt emails) which on SaaS often sits on a separate Mailchimp Transactional / Postmark / SendGrid plan and which self-hosted folds into the same SES bill.

Aggressive: it doesn't bill the engineering time for the initial setup or the ongoing maintenance. A reasonable estimate is 8–16 hours of engineering for the first install, then 1–2 hours/month for OS patches, certificate renewals, queue monitoring, and bounce-list curation. At a $100/hr internal rate that's $200/mo of overhead — material at 5,000 subscribers, immaterial at 50,000, profitable at 200,000.

The cleanest mental model: self-hosted is a fixed-cost-per-send architecture, SaaS is a subscriber-tax architecture. They cross at different points for different teams, but for any list above ~10,000 with steady weekly sending, the SaaS premium becomes the dominant expense. /vs/mailchimp walks the comparison side-by-side at feature granularity.

§5 · Sending architecture

Choosing your sending pipeline.

Self-hosted lets you decouple "the marketing app" from "the thing that talks SMTP." Three architectures dominate; each has a different cost, control, and reputation profile.

A. Cloud SMTP relay (recommended for most teams)

Amazon SES, Mailgun, SendGrid, Postmark, SparkPost, Elastic Email — these are commercial relays that accept your message via API or SMTP and handle the actual SMTP transaction with the recipient. They publish IP pools, handle warming defaults, monitor blocklists, and submit Feedback Loop reports. AcelleMail's vendor drivers cover the major five out-of-the-box (app/SendingServers/Drivers/Vendors/{Amazon, Mailgun, SendGrid, SparkPost, ElasticEmail}) plus generic SMTP for anyone else.

Why this is the default: SES costs $0.10 per 1,000 emails with no monthly minimum. The relay handles the messy parts (rDNS, MX backup, retry logic, complaint feedback parsing). The thing you own is your domain reputation; the thing you outsource is the IP reputation. For 95% of teams, that split is correct.

B. Run your own MTA (Postal / Postfix + DKIM)

Postal is an open-source mail platform that you install on your own server and treat as an SMTP target from your marketing app. Postfix is the venerable Unix MTA, more flexible but more configuration. Both let you control the sending IP entirely, which is the right call when you have specific deliverability requirements (a bank, a healthcare provider, a high-volume sender with a dedicated abuse desk).

Why this is harder: you now own IP warming, complaint feedback parsing, blocklist remediation, and the on-call rotation when port 25 starts emitting 5xx codes. Most cloud providers (DigitalOcean, AWS) restrict outbound port 25 by default — you'll need a colo, a dedicated MTA host, or a provider that explicitly allows direct send. Worth it above ~10M sends/month or in regulated industries; over-engineering for everyone else.

C. Hybrid (multiple relays, automatic rotation)

AcelleMail (and most mature self-hosted platforms) supports more than one configured sending server. You can route transactional through Postmark, marketing through SES, and re-engagement campaigns through Mailgun — each with its own daily quota, IP pool, and DKIM key. This is the high-volume sender's setup: relay diversity caps the blast radius if one provider's IP pool gets blocklisted, and lets you match cost-per-send to send urgency. The driver registry (app/SendingServers/DriverRegistry.php) is the central catalogue.

Decision rubric

• Under 1M sends/mo, want minimum operational load → Amazon SES (or Mailgun if you prefer their dashboard).
• 1M–10M sends/mo, dedicated IP needed → SES with dedicated IP ($24.95/mo per IP) or SendGrid Pro.
• 10M+ sends/mo, regulatory requirement for full IP control → Postal on owned infrastructure.
• Multi-tenant SaaS where each customer needs their own sending domain → SES per-domain configuration sets or multiple SendGrid subusers, configured as multiple sending-server records in the application.

§6 · Platforms

The major open-source self-hosted platforms — objective compare.

Disclosure. AcelleMail is the publisher of this page. We cite our own code paths transparently and link to competitors' published documentation for their factual claims. The table below records license model, language, sending model, and headline target audience — not value judgements.

The major axes that distinguish these platforms in practice:

• Multi-tenancy. AcelleMail and Mautic both have a Customer/Plan model that gates sending volume per tenant — useful if you're reselling email-marketing-as-a-service or running a multi-brand setup. Listmonk and Sendy are single-tenant.
• Marketing automation. Mautic was purpose-built around lead-scoring + drip-flow + CRM integration. AcelleMail has automation flows with conditional branches and event triggers (see the automation page). Listmonk is intentionally newsletter-shaped — campaigns and transactional, no flow builder.
• License model. Listmonk (AGPL v3) and Mautic (GPL v3) require source disclosure of derivative works under the terms of those licenses; AcelleMail is source-available with a CodeCanyon Regular License (use in unlimited installs you control) or Extended License (resale rights). Sendy is closed-source binary distribution.
• Plugin / extension model. AcelleMail ships a documented plugin SDK (hooks, lifecycle, drivers, gateways). Mautic has plugin support oriented around CRM bridges. Listmonk and Sendy do not have plugin systems — extensions are forks.

The decision is project-shape-driven, not "which is best." A solo newsletter author with 5,000 subscribers and no plugin needs is well-served by Listmonk. A SaaS team wanting per-customer plans plus REST API plus a plugin to integrate their billing webhook is the AcelleMail use case. A B2B sales team scoring leads is the Mautic use case. Postal is plumbing — pair it with one of the others.

§7 · Setup roadmap

From zero to first campaign — the seven-step roadmap.

A first-time setup with Amazon SES as the relay typically lands in 4–8 hours, with DNS propagation eating most of the wall-clock time. Subsequent installs (the second tenant, a staging environment) are 30 minutes.

§8 · Deliverability

The deliverability fundamentals every self-hosted sender owns.

Mailbox providers — Gmail, Outlook, Yahoo, Apple Mail — score every incoming message against a stack of authentication and reputation signals before deciding inbox vs. spam vs. reject. On SaaS the platform abstracts these signals; self-hosted you tune them yourself. The good news: the standards are public and stable.

SPF — Sender Policy Framework (RFC 7208)

A TXT record on your sending domain that lists the IPs allowed to send mail "as" that domain. Mailbox providers check the envelope-from against the SPF record; mismatches degrade reputation. With SES the record is one line: v=spf1 include:amazonses.com -all. For multi-relay setups, chain includes: v=spf1 include:amazonses.com include:mailgun.org -all. The -all tail says "anything not listed should be rejected"; for the first month use ~all (soft-fail) until you're confident the record is exhaustive.

DKIM — DomainKeys Identified Mail (RFC 6376)

A cryptographic signature on every outgoing message, signed by a key whose public half is published as a DNS TXT record at {selector}._domainkey.{domain}. The receiver fetches the public key and verifies the signature; tamper-evident header + body chain. SES generates three CNAMEs for you to add — done. Self-hosted MTAs need OpenDKIM or rspamd configured. DKIM failures don't usually trigger immediate rejection, but they erode the domain reputation score that drives placement.

DMARC — alignment + reporting (RFC 7489)

The policy on top of SPF + DKIM. DMARC says "the From-header domain must align with the SPF or DKIM domain, and here's what to do if alignment fails: monitor (p=none), quarantine (p=quarantine), or reject (p=reject)." Plus an rua address that gets daily aggregate reports of who's sending mail "as" you. Start at p=none for a month, read the reports, fix any forgotten subdomains, then move to p=quarantine, then p=reject. As of February 2024, Google and Yahoo require DMARC for bulk senders (5K+ sends/day) — not optional.

List hygiene — the suppression habit

Hard bounces (5xx codes — invalid mailbox, domain doesn't exist) must be suppressed permanently after the first occurrence; otherwise mailbox providers treat your list as poorly maintained. Soft bounces (4xx — full mailbox, temporary failure) are retried with exponential backoff and suppressed after 3–5 retries. Complaints — recipient hit "spam" — suppress immediately and forever. Re-engagement campaigns should target the engaged half of your list every 90 days; non-openers in 180+ days come off entirely. Every self-hosted platform exposes this; AcelleMail's per-list suppression model integrates with the bounce-handler webhook hooked up at step 4 above.

Engagement signals + IP reputation

Mailbox providers increasingly weight recipient engagement: opens, clicks, "not spam" gestures, replies. Sending the same message to your most-engaged 10% drives reputation up; sending to your dead 50% drags it down. Self-hosted means you have raw access to engagement data — segment campaigns to the engaged half, suppress the long-cold half, and watch the bounce + complaint rates. Tools to monitor: Google Postmaster Tools (free), Microsoft SNDS (free), the relay's own dashboard. Acelle's automation flows can branch on engagement-score custom fields, which is the cleanest place to encode the rule.

§9 · Compliance

GDPR, data residency, and the Schrems II question.

GDPR (EU 2016/679) treats subscriber email addresses + custom fields as personal data, with seven principles that bind the data controller (you) and the data processor (your hosting + sending vendors). The big practical implications:

• Lawful basis. For marketing email, consent or legitimate interest. Both require a record (timestamp, IP, source) and an unsubscribe path. The List-Unsubscribe RFC 8058 one-click header is non-negotiable since Feb 2024 for Gmail/Yahoo bulk senders.
• Data subject rights. Right of access (export their record), right to erasure (delete on request), right to portability. All three are SQL queries on a self-hosted setup; on SaaS they're vendor support tickets.
• Data Processing Agreement (DPA). Your relationship with each processor needs a written agreement specifying retention, security measures, sub-processors. SaaS platforms publish theirs; self-hosted you have one (with the host) plus one (with the sending relay) — fewer parties, simpler audit trail.
• International transfers (Schrems II). The 2020 Court of Justice decision invalidated Privacy Shield as the legal basis for EU→US personal data transfers, making cross-border SaaS storage a moving target. Self-hosted on EU infrastructure (Hetzner Falkenstein, OVH Strasbourg, AWS Frankfurt with EU-only configuration) sidesteps the question; the data never crosses a border.

Practical residency checklist:

• VPS region matches your customers' jurisdiction (eu-west-1 / Frankfurt for EU, us-east-1 for US).
• Sending relay region pinned (SES region selector — switching from us-east-1 to eu-west-1 is one config field).
• Backups stored in the same region (S3 with a region-locked bucket, encrypted at rest).
• Database backups, log retention, and tracking-pixel hosts all on the same continent as the application.
• Sub-processors documented in your privacy policy (e.g. "We use AWS SES eu-west-1 for email delivery; data does not leave the EU").

For more on AcelleMail's security posture and the underlying audit-log + RBAC model, see /security. None of this constitutes legal advice — engage a privacy lawyer for the DPA review.

§10 · Honest trade-offs

When self-hosted is the wrong call.

Self-hosted is not strictly better than SaaS — it's better for specific shapes of team and use case, and worse for others. Three patterns where the SaaS option is the right answer:

The honest framing: self-hosted shifts the work, it doesn't eliminate it. If shifted-to-you is the wrong place for that work, SaaS is correct. For the much larger group where shifted-to-you means "shifted to your existing devops capacity," self-hosted compounds the longer you run it.

§11 · FAQ

Frequently asked questions.

§12 · Cluster head

Where to go next.

This guide is the head of a content cluster. Follow the link that matches your next decision.

Stop renting your subscriber list. Start owning it.

AcelleMail is a self-hosted email-marketing platform with multi-tenant billing, a documented plugin SDK, and built-in drivers for Amazon SES, Mailgun, SendGrid, SparkPost, and any generic SMTP. Standard licence $74 one-time. Lifetime updates. Try the live demo before you buy.