Sendy SMTP Setup for 100K+ Subscribers

Sendy is a $69 one-time PHP app that most people run on Amazon SES at $0.10 per 1,000 emails, which puts a 100,000-email month at roughly $10 of sending plus a $12 VPS. What almost nobody uses is the SMTP option sitting in the same settings panel, which lets Sendy send through your own server and your own IP instead. Both paths work at 100K plus. The difference is who owns the reputation, and how much SNS plumbing you have to build.

What Sendy is, and what it is not

Sendy is a self-hosted campaign sender with a licence you buy once. Per Sendy's own pricing page the fee is $69, one time, no subscription. That is the entire pitch, and the feature list is narrower than people expect.

Autoresponders are the ceiling on automation: a timed series fired on list join or a date field, plus rules and webhooks. No canvas, no branching on clicks. People who buy Sendy expecting a Klaviyo-shaped flow builder return within a week.

What Sendy has that listmonk does not is white-labelled client accounts. If you send on behalf of customers, that alone decides it. Compare the wider field in Sendy alternatives, or the pure-speed option in the listmonk SMTP server setup.

The Amazon SES path

This is the default and the reason Sendy exists. You give Sendy an IAM access key and a region, and it calls the SES API directly rather than talking SMTP.

Create an IAM user with AmazonSESFullAccess, or a tighter policy allowing ses:SendRawEmail, ses:GetSendQuota and the SNS actions. Then fill in Settings.

Two things trip people. Region mismatch: verify your domain in eu-west-1, set Sendy to us-east-1, and every send fails on an unverified identity. And the sandbox, where a fresh SES account can only mail verified addresses, capped at 200 a day and 1 a second. File the production access request before any of this matters at 100K.

Out of the sandbox the default is 50,000 emails a day at 14 a second. That number governs your throughput, and you raise it by asking, with your bounce and complaint rates as the argument.

Pointing Sendy at your own SMTP server

Sendy will happily ignore SES. Each brand has an SMTP block, and setting it makes that brand send through a normal mail server instead of the API.

Why do it. On SES you sit in a shared IP pool by default, priced at $0.10 per 1,000, with a dedicated IP available at $24.95 a month per IP according to the Amazon SES pricing page. Add two IPs and you are at $50 a month before a single email. On your own server the IP is yours, the reputation is yours, and nobody reviews your account because there is no account.

The catch is bounce handling. On SES, SNS hands Sendy structured bounce data. On your own server you route bounces to a mailbox Sendy polls, which is slower and worth testing before you trust it.

I run the hybrid more often than either pure path: transactional brands on SES, the main newsletter on a dedicated server. Sendy's per-brand setting makes that a five-minute config change, not a migration.

Cron, PHP limits and real throughput

Sendy sends from cron. That single fact explains most of the throughput complaints.

Two jobs, both every 5 minutes:

*/5 * * * * php /var/www/sendy/scheduled.php > /dev/null 2>&1
*/5 * * * * php /var/www/sendy/autoresponders.php > /dev/null 2>&1

Miss these and scheduled campaigns simply never fire. It is the most common Sendy install complaint and it is always the cron.

Each pass sends a chunk and exits when the PHP script limit hits. On shared hosting with max_execution_time = 30 you get a few hundred emails per pass, so a 100,000-email campaign drags across many hours. Raise the limits:

max_execution_time = 300
memory_limit = 256M

Now the real ceiling. Sendy cannot exceed the SES rate limit, and SES throttles you at your granted rate.

The 14 per second default is fine for 100K and stops being fine past 500K, where you either request a rate increase or move that brand to your own server.

Faster is not automatically better. A young IP pushing 50 per second at Gmail collects 4xx deferrals, and deferrals turn a fast campaign into a slow one. Target a 2 to 4 hour finish and follow an IP warm-up schedule if the IP is new.

Sizing the box for 100K plus

Sendy is light. MySQL is what grows, and it grows on clicks and opens, not subscriber rows.

A 100K list on a $12 VPS is comfortable. What kills these installs is not subscriber count, it is the tracking tables after two years of daily sends. Purge old campaign data on a schedule.

Sendy also stores your AWS keys and SMTP password in includes/config.php and the database. Lock the directory down and put the app behind HTTPS.

Bounces and complaints via SNS

Skip this section and Amazon will find you. AWS expects bounces under 5% and complaints under 0.1%, and it measures those regardless of whether you are processing the notifications.

The wiring, in order:

1. In the AWS console, create an SNS topic, one for bounces and one for complaints (one topic for both works too).
2. Subscribe the topic with protocol HTTPS and the endpoint URL Sendy gives you in Settings, which looks like https://yourdomain.com/sendy/_bounces.php.
3. Confirm the subscription. Sendy auto-confirms if the URL is reachable over valid HTTPS.
4. In SES, on the verified domain identity, set the bounce and complaint notifications to that SNS topic.
5. Send to a known-dead address and confirm the subscriber flips to bounced in Sendy.

Step 5 is the one people skip. A subscription that shows "pending confirmation" in the SNS console looks fine on the AWS side and does absolutely nothing.

Google's bulk sender guidelines put the spam complaint ceiling at 0.3% with a target under 0.1%, and Amazon acts earlier because your behaviour risks their shared pool. An unprocessed bounce list mails the same dead addresses every send, the rate climbs, and the account goes under review. Read Amazon SES account under review before you need it.

On your own SMTP server none of this exists. Route the MTA's Return-Path to a bounce mailbox and give Sendy the POP3 details. More work, no review queue.

What it costs at 100K, 500K and 2M a month

The licence is $69 once, so it barely registers past month one. Monthly figures below, rounded, licence excluded.

SES on the shared pool is the cheapest row at every volume. What it does not price is the review risk: one complaint spike, one sending pause, one lost launch window, worth far more than the $50 saved.

Add dedicated IPs to SES and the maths flips. At 2M the dedicated server row is a third of the SES-with-dedicated-IPs row, with an unmetered send rate instead of a quota you request. Mailchimp at 500,000 sends runs $500 to $700, roughly seven times Sendy plus SES. Full working in cost to send 500,000 emails per month.

The line missing from every table is your time. Patching PHP, renewing TLS, purging tracking tables, debugging a cron that silently stopped. An hour a month, and one bad afternoon a year.

Go-live checklist

Before the first campaign to a real 100K list, in order.

1. Licence and install. Sendy running on PHP 8 with the required extensions, includes/config.php permissions locked down, HTTPS enforced.
2. Cron. Both scheduled.php and autoresponders.php on a 5-minute schedule, verified by a test scheduled send.
3. PHP limits. max_execution_time at 300, memory_limit at 256M.
4. Sending method. SES keys plus the correct region, or the SMTP block with port 587 and TLS. Send a test to yourself.
5. SES production access. Out of the sandbox, quota confirmed at 50,000 a day or higher.
6. DNS. SPF, DKIM and DMARC published, DMARC starting at p=none.
7. rDNS. On your own server, the sending IP's PTR resolves to the HELO hostname and back.
8. SNS. Bounce and complaint topics created, HTTPS subscription confirmed (not pending), SES identity pointed at them.
9. Bounce test. Mail a known-dead address, confirm the subscriber flips to bounced within a minute.
10. Seed send. 50 addresses first, then check headers for DKIM d= alignment.

Steps 8 and 9 are one job. A confirmed subscription that never fires is the same as no subscription, and you find out at 3% bounce rate.

How BulkEmailSetup helps

Sendy solves the campaign side for $69. It does not give you an IP, a warmed reputation, or an SES account that survives a bad list. The sending infrastructure is where these stacks break, not the PHP.

We supply Sendy-ready SMTP: credentials that paste into the brand's SMTP block, dedicated IPs warmed on a managed schedule, and rate limits matched to the warm-up so your cron never outruns your reputation. Basic is $549 one-time for 1 SMTP server, 3 dedicated IPs, 25,000 emails/day and unlimited contacts; higher tiers go to 15 IPs and 200,000 emails/day. Details on the pricing page.

Frequently asked questions