Same Amazon SES economics. No server to run.

Sendy is beloved for good reason — it made SES-priced email marketing accessible years before anyone else, and it's still actively maintained. This comparison isn't about whether Sendy works. It's about what running it actually costs, and what a platform built on the same foundation looks like in 2026. It's most useful for three kinds of teams:

• teams running Sendy today who like the SES economics but not the server that comes with it
• teams paying a hosting service to run Sendy for them
• teams choosing between a one-time self-hosted license and a managed platform on the same SES foundation

Domain-wide visibility

The missing layer: who else is sending as your domain?

Sendy reports on the campaigns Sendy sent. It has nothing to say about the invoicing tool, the CRM, or the help desk that also puts your domain in the visible From address. Domain-based Message Authentication, Reporting, and Conformance (DMARC) aggregate reports are the one feed that covers all of them.

On a self-hosted stack, that feed is another subsystem to assemble. Something has to receive the reports at a published rua address, parse them, deduplicate rotating IPs, and keep the history somewhere you can query. That is a second thing to host, patch, and back up beside the Sendy server.

SendOps includes it. DMARC monitoring collects the aggregate reports receivers send about your domain and groups them by sending source. Because SendOps also knows your SES identities and DKIM selectors, it can prove which of that traffic is your own first-party sending.

That proof is what makes the rest useful. A misconfigured service you own reads very differently from traffic you have not identified yet, and SendOps separates the two instead of lumping them together. Each source is presented for review with a diagnosis and, where one exists, a next action.

An unidentified source is not automatically an attacker. It is often a forgotten SaaS subscription, a shared sending pool, or ordinary forwarding. SendOps asks you to record a decision on each one.

Rejecting a source records that it is not yours. It does not block the source or silence future alerts. A stricter DMARC policy is what asks receiving providers to act on unauthenticated mail.

So SendOps stops at a recommendation. It previews what a move to quarantine or reject would have affected, in messages per day, and generates the exact record with a field-level diff. You publish the change at your own DNS provider, and you can roll it back there.

One scope note: this covers the exact domain in your visible From address. It will not find lookalike registrations such as example-payments.com. SendOps also accepts aggregate reports only — forensic reports can carry recipient addresses and message content, and major mailbox providers generally do not send them.

The self-hosting tax

The real price of Sendy isn't $69

Sendy's list price is a one-time $69 license, and on that line item nothing competes. But the license is the smallest part of the bill. Running Sendy means running a server: PHP and MySQL to install and patch, cron jobs to keep alive, backups to verify, and scaling to handle when your list grows. Commonly cited pain points in public reviews are exactly these — the setup is technical, and the maintenance never really ends.

The clearest evidence is that an entire hosting sub-industry exists just to run Sendy for people — monthly-priced services whose whole job is absorbing the server ops. If you're paying one of them, you've already converted Sendy into a subscription; the question is only which platform the subscription buys.

SendOps removes that layer entirely. There is no server, no PHP, no MySQL, no cron. You keep your SES account — the part actually worth keeping — and SendOps runs everything else. The Free plan is $0 with unmetered volume and no contact limits, which is less than any VPS.

Automation depth

Autoresponders vs lifecycle workflows

Sendy's automation is autoresponders: time-based drips that fire on a schedule after signup. For welcome sequences and simple nurture emails, they work — and for many newsletters that's genuinely enough.

SendFlow is a different category. Workflows are multi-step, branching, and triggered by events and contact activity — a signup, an attribute change, an open, an action your application reports through the activity API. You author them as a plain-text DSL or on a visual canvas; both are views of the same workflow. Waits, conditions, and branches let you build lifecycle programs — onboarding, re-engagement, expansion — that respond to what a contact actually does, not just when they joined. A workflow run also renders its email for review before that email goes out.

The same gap shows up in segmentation. Sendy offers condition-based segment rules. SendQL is a query language over your contacts, attributes, and email activity — expressive enough to define the audiences your workflows target, and stored as plain text you can version.

Analytics and alerting

Reports tell you what happened. Alerting tells you before it hurts.

Sendy gives you campaign reports — opens, clicks, bounces, unsubscribes per send. That's useful, but it's backward-looking, and it's where the analytics story ends. A commonly cited limitation is that there's no deliverability monitoring: if your bounce rate creeps toward SES's thresholds, Sendy won't tell you.

SendOps treats deliverability as a first-class concern. Bounce and complaint rates are monitored continuously, deliverability analytics show trends across domains and sending identities, and alerting notifies you before a problem becomes an SES pause. On a platform where the SES account is yours — and its reputation is yours — this is the layer that protects the asset.

Everything as code

Templates in git, segments as queries, workflows as text

In Sendy, templates live in a drag-and-drop editor or as pasted HTML, and configuration lives in the app's MySQL database — which means none of it is something an AI coding agent can read, diff, or improve; a drag-and-drop editor was a convenience in 2015 and is a dead end in the agent era. In SendOps, template source is React Email TSX in your own git repository — edited in the SendOps UI or your editor, with PR write-back so every change is reviewable — and SendOps compiles it to the Handlebars templates SES runs natively. Images and assets ship through a built-in CDN.

The same is true across the platform: SendQL segments and SendFlow workflows are plain text. That makes them diffable and versionable, and it makes them legible to coding agents. An agent can author a segment, adjust a workflow, or open a pull request against a template the same way it works on the rest of your codebase; a human merges it, and the default branch is what deploys.

Live state is a separate surface. SendOps ships a native MCP server whose scoped tools let an authorized agent inspect reporting, maintain contacts, prepare broadcasts, and review DMARC posture. Sending a broadcast and activating a workflow each require an explicit confirmation after the impact is shown, and no agent can publish DNS.

For backend integrations, the Public API now supports OAuth 2.1, so browser and third-party clients can authorize without copied long-lived keys. An activity API covers the rest.

Architecture and ownership

Closer to Sendy's ethos than any SaaS ESP

Sendy's current pitch is "Send Newsletters Without SaaS Lock-In," and the instinct behind it is sound: your sending infrastructure and your data shouldn't be hostage to a vendor. SendOps takes that instinct seriously — which is why it's architected differently from a conventional ESP:

Your SES account, your domains, your sender reputation, and your templates (in your git repo) all remain yours. If you leave, the sending infrastructure doesn't move — because it was never ours. That's the ownership Sendy users actually care about, without the server that Sendy attaches to it.

Migrating from Sendy

Stop hosting Sendy. Keep everything that matters.

Because both tools sit on your own SES, moving off Sendy isn't an email-provider migration — the sending layer doesn't change at all. Your SES account stays exactly as it is. SendOps connects to the same account through a two-minute CloudFormation setup and imports your existing verified domains and configuration non-destructively. Your sender reputation, built over years of Sendy sends, carries over untouched because it was never Sendy's to begin with.

From there: export your Sendy lists to CSV and import them as contacts, rebuild segments in SendQL, and recreate autoresponders as SendFlow workflows — usually gaining triggers and branching in the process. When the last campaign has moved, you decommission a server instead of a sending history.