We paid about $3,000 a month for email. The sending cost about $30. Here is what the other $2,970 was doing.

We were paying about $3,000 a month for email across our products, on Mailchimp and Resend. Most of our contacts heard from us once a month, if that.

When we moved the same mail onto raw sending infrastructure, the sending line of the bill came to about $30 a month.

Before anyone does that arithmetic on their own stack: $30 is what our sending cost, for our volume profile. It is not what email costs, and it is not what your $3,000 turns into. The rest of this post is the difference.

Where the $3,000 went

Almost all of it went to the size of the list, not to the mail.

Mailchimp prices marketing plans by contacts, and its own help page says subscribed, unsubscribed and non-subscribed contacts all count toward the price. Resend prices transactional mail by volume, which tracks usage, and its marketing plans by contacts, which does not. So the account with the biggest list and one newsletter a month was the most expensive account we had, by a distance.

That shape matters for the rest of this post. A large list mailed rarely is the best case for leaving contact-based pricing. If your bill is mostly transactional volume, you will save far less, and possibly nothing worth the work.

What "about $30" does not include

The $30 is one line of the new bill. The others are the servers and database the layer runs on, which cost more than the sending does, and the engineering time to build and keep it working, which costs more than all of it. And one line that is not money: while we learned, one of our domains lost its reputation at Gmail for days. More on that below.

The work nobody puts on a pricing page

Raw sending gives you an API that accepts a message and a feed of events. Everything below was ours to build, and each item is something a managed provider was quietly doing for us:

• Suppression. A hard bounce or a spam complaint has to stop every future send to that address, across every product, forever. A full mailbox must not, or a healthy list shrinks for no reason.
• Scope. Someone who unsubscribes from the newsletter still needs their password reset. Opt-outs are per kind of mail, and only bounces and complaints block everything.
• Unsubscribe is two writes. Suppressing the address is one. Cancelling everything already scheduled for them is the other.
• Two reputations. Marketing and transactional mail go out on separate subdomains, so a bad newsletter cannot get password resets spam-foldered.
• Pacing. The sending account has a per-second rate and a daily ceiling. Every loop that fans out has to share one pacer, or three well-behaved loops exceed the limit together.
• Domains. DKIM, SPF, DMARC, a bounce subdomain, and checking they stay published.
• Compliance. CAN-SPAM wants an unsubscribe link and a postal address in marketing mail, plus one-click unsubscribe headers that the big mailbox providers now require from bulk senders.
• Replies. Inbound mail arrives as raw MIME. Joining a reply to the message it answers, stripping the quoted history and knowing what is still waiting on an answer is a small product of its own.
• Logs and support. When someone asks "why didn't I get the email", the answer has to be one search away.

The first working version took weeks of full-time engineering, and it has not stopped needing attention since. That is the cost the $30 does not show.

What broke

Everything on this list happened to us, on real mail, in the first few weeks. Each one is now handled by default.

1. We kept sending at the old rate after our limit was raised. The sending limit was a number we had written down, not one we read from the account, so when the account was granted far more, nothing noticed. Read limits from the source; never copy them into configuration.
2. A day-old domain sent a whole newsletter in under half an hour. Every mailbox provider accepted it except Gmail, which spam-foldered enough of it that the open rate collapsed. Reputation took days to recover. Every new domain now warms up over two weeks, anchored on its first send rather than on when its DNS was verified.
3. The first real reply started a new conversation. The sending layer assigns its own Message-ID to each message, and a reply references that one, not the one you set. Match replies against what was actually sent.
4. The unsubscribe link and postal address sat after </html>. Appended to the end of the message rather than inside the body. Mail clients render it anyway, which is why it went unnoticed. Splice anything you add before </body>.
5. Our open-tracking pixel made Gmail call a newsletter suspicious. It was the only image on a third-party domain in a message that otherwise passed every authentication check. Gmail hid every image. Tracking now runs on the sender's own domain.
6. Half of all "clicks" were security scanners. About half of the clicked messages showed the pattern of a corporate mail gateway checking links, not a person reading. Click counts are now settled after the fact instead of trusted as they arrive.

None of these is exotic. Each is something a managed provider had already learned and was quietly handling, which is part of what the $3,000 was buying.

Should you do this?

Probably not, if:

• Your bill is mostly transactional volume. Usage-priced providers are already close to cost plus a fair margin. The saving will not pay for the work.
• Nobody on the team wants to own deliverability. Every item in "What broke" landed on an engineer, usually on a weekend.
• Your marketing team lives in a visual editor. You will be rebuilding templates as HTML.
• You send from a brand-new domain and cannot wait. Warm-up is days, whoever you send through.

It is worth a look if:

• Your list is large and mailed rarely. That is where contact pricing and actual sending cost are furthest apart.
• You already run infrastructure and on-call. The layer is one more service.
• You need something providers do not sell, which for us was software, not a person, reading the replies and sending within limits.

Disclosure

We did not stop at replacing our own bill. The layer we built became SendRaven, which we now offer to other teams, priced per email sent and never per contact. If you would rather not build the list above yourself, that is what it is for. If you would, everything in this post applies without it.

How we price: per email sent · The warm-up incident in full · SendRaven