Open Source SendGrid Alternatives

BillionMail combines a mail server with a campaign platform, so newsletters, promotional mail and transactional messages all leave from infrastructure you own. It removes the per-contact monthly bill and the sending caps that come with hosted marketing services.

Installation is a single shell script or a Docker Compose file, and the project puts eight minutes between the install and a first successful send. After that you add the sending domain, verify its DNS records and let the installer switch on free SSL, then write the campaign and pick a list and a send time.

The running system covers the marketing side as well as the mail side.

• Unlimited sending: no restriction on how many messages you push through your own server.
• Campaign analytics: delivery, open rates and click-through rates tracked for each send.
• Reusable templates: professional marketing templates you customize once and use again.
• Webmail included: RoundCube is integrated and reachable from a path on the same install.
• Management script: a bm command prints default logins, shows DNS records and applies updates.

A live demo with public credentials is available for anyone who wants to look before installing, and aaPanel offers a one-click Docker install for its users. Nothing is forwarded to a third party, so contact lists and open tracking stay on the machine you control.

Plunk puts transactional email, marketing campaigns and workflow automation in one self-hosted platform, so a product team stops paying for and stitching together a separate sender, newsletter tool and automation service. It positions itself against SendGrid, Resend and Mailgun.

Mail leaves through the API with template support and variable substitution, or through Plunk acting as an SMTP relay, which lets any existing tool or framework send through it without code changes.

Beyond sending, the platform manages the audience and the reporting.

• Campaigns: send newsletters and product updates to large audiences.
• Workflows: build automations with triggers, delays and conditional logic.
• Segments: filter contacts dynamically to reach the right audience.
• Contact management: keep custom fields and a full activity history per contact.
• Analytics: track opens, clicks, bounces and engagement in real time.
• Inbound email: receive incoming messages and route them with custom rules.

Custom domains are verified with DKIM and SPF so mail goes out under your own name. The easiest deployment is the official Docker image, with a full guide in the documentation, and the code is licensed AGPL-3.0. The project advertises a cost of $0.001 per email and no contact limits, which suits teams mailing long lists.

useSend is sending infrastructure you host yourself. Like most email products it uses Amazon SES underneath, and adds the dashboard, contact management and subscription handling that SES alone leaves you to build.

The stack is Next.js with Prisma, Tailwind and shadcn/ui, authentication through NextAuth.js, tRPC for the internal API and Hono for the public one, and Redis for the sending queue. The email editor is built on tiptap, converts its output to HTML with jsx-email, and takes its cues from maily.to.

The current release covers transactional and marketing sending alike.

• Domains: add and verify the domains you send from.
• Transactional mail: a REST API plus SMTP support for applications that already speak it.
• Marketing email: bulk sends such as newsletters and product updates, with subscriptions handled for you.
• Scheduling and webhooks: a schedule API for future sends, and webhooks for delivery events.
• Dashboard: delivered, opened, clicked and bounced figures in one view.

Inbound email and bring-your-own AWS credentials are listed but not yet built, and the project describes itself as being in beta while it opens up for public testing. Docker images are published on Docker Hub and the GitHub Container Registry, needing environment variables for the database, Redis and AWS, and a Railway template is the quickest way to stand an instance up.

Amazon SES is cheap, reliable and almost silent about what happens after you press send. That silence is why so many teams end up paying a transactional email provider that is largely an SES wrapper with a nicer interface. Sessy is the open source version of that interface, sitting on top of raw SES.

It is a Rails application, most easily run as a Docker image with a secret key base and a storage volume, with deployment docs for Kamal and Dokku if you want to run a fork. Background work goes through Solid Queue, and a dashboard at the jobs path lets you watch queues, retry failures and inspect recurring tasks.

What you get beyond the send itself is visibility and programmatic access.

• Delivery events: deliveries, bounces, complaints, opens and clicks presented in one interface.
• MCP server: a read-only endpoint lets coding agents search events, inspect a message timeline with bounce diagnostics and pull aggregate stats.
• API keys: created in the web UI, and the MCP endpoint authenticates with those keys only, ignoring HTTP basic auth entirely.
• CDN caveat: Cloudflare bot protection blocks MCP clients unless you exempt that path.
• Hosted code in the open: the managed version's engine lives in this repository, and the test suite verifies the open source build behaves identically without it.

Guides cover configuring SES itself and hardening an install for security and deliverability. The license is O'Saasy, except where a subdirectory says otherwise.

Building an email-heavy application on SES means two chores before you see a single bounce: wiring up the SES to SNS to SQS pipeline, which is a headache for anyone not fluent in AWS, and then finding somewhere to actually read the results. DoubleZero, published as 00, removes both.

An SST configuration step sets up the pipeline for you. Set the sending domain or address in an environment variable, run the deploy command, and SST does the rest; a wiki guide covers the manual AWS route for people who prefer to click through it. The app itself is a published Docker image on port 4000, backed by SQLite and configured with AWS credentials, the queue address, a system email, a secret and the public host.

Once it is up, it does the sending as well as the watching.

• Send over HTTP: POST a JSON body to the emails endpoint with a bearer token and the message is queued.
• Flexible payloads: markdown or HTML bodies, plus subject, cc, reply-to, custom headers, provider options and attachments.
• Multi-recipient tracking: a message record is created per recipient, so status is tracked individually.
• Search: query across emails and messages and view the body of any of them.
• Log tracking: requests and queue activity are logged for when something goes missing.

After the AWS side is configured you still verify your domain by publishing three DKIM records, which AWS says may take up to 72 hours. SST does not yet deploy the container itself.

Hyvor Relay is an email API you run on your own servers. It sends over SMTP from your infrastructure and your addresses, which puts deliverability and IP reputation in your hands rather than a vendor's, while still giving developers the simple send endpoint they expect.

The stack splits by job. PHP with Symfony runs the API backend, Go handles email workers, webhook delivery, the DNS server, and the incoming SMTP server as a single binary, SvelteKit and the Hyvor Design System build the frontend, and PostgreSQL serves as both database and queue. Deployment is Docker Compose or Swarm.

Running your own mail path means handling the parts a provider normally hides.

• Deliverability handling: greylisting, retries, bounces, feedback loops, and suppressions are managed automatically.
• Queue separation: transactional and distributional mail sit in separate queues to protect IP reputation.
• DNS automation: delegate DNS to the built-in server instead of maintaining records by hand.
• Multi-tenancy: tenants get scoped access and each holds isolated projects, which fits agencies and larger organizations.
• Observability: send logs and full SMTP conversations are kept for 30 days, alongside Prometheus metrics and Grafana dashboards.
• Webhooks: HTTP callbacks report email events to your own systems.

Health checks watch performance and deliverability, and scaling means adding more servers and IP addresses as volume grows. The license is AGPL 3.0, with enterprise licensing offered to organizations that need commercial terms or cannot comply with it.

Wraps sets up email infrastructure inside your own AWS account with one CLI command, then hands you a TypeScript SDK to send through it. The middleman disappears: you pay AWS directly for sending, and if the project vanished tomorrow the pipeline it built would keep working.

A single init run provisions the whole stack, namespaced under a common prefix and tagged as managed by the CLI, so it stays obvious what belongs to Wraps. Sending afterwards is a few lines of typed code, with visual templates, analytics and a dashboard on top.

That one command creates the pieces an email pipeline needs.

• SES: domain verification with DKIM, SPF and DMARC records handled for you.
• EventBridge and SQS: bounces, opens, clicks and deliveries arrive as real-time events.
• DynamoDB: email event history is retained for a configurable window.
• Lambda: event processing and webhook handling run as functions in your account.
• IAM: least-privilege roles with OIDC support for Vercel and AWS native workloads.

SMS has its own CLI and SDK, and CDK and Pulumi packages cover infrastructure as code. Node 20 or newer plus configured AWS credentials are the only prerequisites. The code is AGPL-3.0 with enterprise features under a commercial license, and the project publishes an agent-readable documentation bundle for people working through Claude Code or Cursor.