SendBeam blog

Automations that listen to your other tools, and answer back

SendBeam team — Tue, 22 Sep 2026 00:00:00 GMT

Most small email platforms have the same shape of integration story. There is a list of logos, and behind each logo is a recipe that creates a subscriber. Data goes one way: into the tool. If you want the tool to tell something else what happened — a CRM, a helpdesk, your own application — you are usually told to poll an API on a schedule, or to wait for the vendor to build a partnership.

We have just shipped the two halves that remove that. Anything that can make an HTTP request can now start a SendBeam automation by saying what happened, and an automation can now tell your systems that a contact has reached a point in a flow. Neither needs a partnership, an app review or a marketplace listing.

The inbound half: say what happened, by name

There is a new endpoint. You post an event name and an email address:

POST /api/v1/events
x-api-key: sb_live_...
Content-Type: application/json

{ "event": "deal_won", "email": "sam@example.com" }

In the automation builder there is a matching trigger, Something happened elsewhere, where you type the same name: deal_won. Every active automation listening for that name runs for that contact.

That sounds small. The design decision inside it is not, and it is worth explaining because it is the reason this works without us calling anyone.

SendBeam already had a way to start an automation from outside — POST /api/v1/automations/{id}/trigger — and it has a flaw that only shows up in practice. It names one automation, by id. So the integration has to know that id, which means somebody has to copy it out of our UI and paste it into theirs, and it breaks the day the workspace rebuilds the automation. Worse, a partner cannot ship a recipe that works for anybody but the person who configured it, because every customer’s id is different. That is exactly the coupling that turns a five-minute job into a business-development conversation.

A name inverts the dependency. The sending system says what happened; the workspace decides what that should mean; either side can change without telling the other. deal_won is the same string in every workspace on the planet, so a recipe built once works for everyone — and it is a string a person can guess, which matters more than it sounds when you are debugging at eleven at night.

In practice that means a Pipedrive webhook for a deal moving to Won, a Typeform partial submission, a Calendly booking, or a row changing in a spreadsheet, each becomes a Zapier webhook step or an n8n HTTP Request node pointing at one URL. No app review anywhere.

What it deliberately will not do

An event never creates a contact. Somebody else’s system mentioning an address is not consent to email that address, and we are not going to launder a purchased list through an integration endpoint. If we do not already hold the contact, the response says so:

{ "ok": true, "event": "deal_won", "matched": false, "enrolled": 0 }

Note that it is a 200, not a 404. An unknown address is a completely normal thing for a busy CRM to send, and returning an error for it would have every sending system treat a non-event as a failure and retry it for ever. It is accepted, it is not acted on, and it says which.

Two other limits worth knowing before you build on it: the event carries a name and an address and nothing else — there is no custom payload to read inside the automation yet — and a contact who has unsubscribed or been suppressed is not enrolled by one, the same as every other trigger.

The outbound half: a step that calls your systems

The other direction is a new automation step, Call Webhook. Drop it anywhere in a flow and, when a contact reaches it, your systems hear about it: a CRM to update, a task to raise, an order to check.

The interesting part is what the step does not have: a URL field.

We could have put a box on the step and posted to whatever you typed. Every one of those requests would then be an unvalidated outbound call from our infrastructure, and we would need to build signing, retries, timeouts and failure handling for a second time — a worse copy of what our webhook endpoints already do.

So the step sends an event, automation.step_reached, and the endpoints you have already set up deliver it: signed, retried, and switched off automatically if your server goes away. One endpoint serves every automation you ever build, and a URL that changes is changed in one place rather than hunted through a dozen flows.

You give the step a label — notify-crm, say — and that is what arrives:

{
  "event": "automation.step_reached",
  "data": {
    "contact": { "id": "…", "email": "sam@example.com", "first_name": "Sam" },
    "automation": { "id": "…", "name": "Trial day 3" },
    "step": { "id": "…", "label": "notify-crm" }
  }
}

Branch on the label, not on the automation’s name: names get edited, and step ids change when a flow is rebuilt. The label is the bit you control and nobody else will touch by accident.

Because an endpoint has to be subscribed for any of this to happen, the step tells you whether one is. If nothing in the workspace is listening for automation.step_reached, the step says so while you are building it and links straight to the form with the event already ticked — and the pre-flight check warns you again if you try to activate an automation containing a step nothing would hear. A step that silently does nothing is the worst possible outcome for a feature like this, so we spent the effort on making that state impossible to miss rather than on a cleverer builder.

If you run more than one site

Because the trigger matches on a name rather than an id, one recipe covers every workspace you run. An agency with fifteen client workspaces writes the deal_won automation once and copies it into the rest with a workspace blueprint, and the same integration, pointed at the right API key, feeds all of them. Nothing in the sending system needs to know which workspace it is talking to beyond the key.

Try it in five minutes

Build an automation, give it the Something happened elsewhere trigger, and type an event name.
Activate it — only active automations enrol.
Send yourself one event with curl, using an API key that has contacts:write:

curl -X POST https://sendbeam.io/api/v1/events \
  -H "x-api-key: $SENDBEAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"event":"deal_won","email":"you@example.com"}'

For the return path, add a Call Webhook step, give it a label, and make sure an endpoint subscribes to automation.step_reached.

The full reference is in the docs: triggers, step types and webhooks. If your store sends order events, the same machinery already carries cart, product and order triggers.

Both halves are live on every plan now. If you build something with them that we did not think of, we would like to hear about it — that is rather the point of not requiring a partnership.

UK email marketing rules in 2026: PECR, UK GDPR consent, and what changing provider actually requires

SendBeam team — Sun, 06 Sep 2026 00:00:00 GMT

This post explains the rules as we understand them, with links to the legislation and the regulator’s guidance. It is not legal advice. If a decision turns on it, ask a solicitor.

Two pieces of UK law govern a marketing email: the Privacy and Electronic Communications Regulations, which say whether you may send it, and the UK GDPR, which governs the personal data you hold to send it. People tend to know the second exists and forget the first, which is unfortunate, because most of the enforcement action for email has been under the first.

This post covers what each law requires of a small site, what the regulator has actually fined people for, what changing your email provider does and does not oblige you to do, and a checklist you can work through in an afternoon.

The Privacy and Electronic Communications (EC Directive) Regulations 2003 apply to marketing by electronic mail, which covers email, SMS and similar messaging. Regulation 22 is the operative rule. In summary:

You must not send unsolicited marketing by electronic mail to an individual subscriber unless they have previously notified you that they consent to receiving it (reg. 22(2)).
There is one exception, usually called the soft opt-in (reg. 22(3)). You may email someone without prior consent if you obtained their details in the course of a sale or negotiations for a sale of a product or service, the marketing is for your own similar products or services, and they were given a simple means of refusing, free of charge, at the time their details were collected and in every message since.

“Individual subscriber” means individuals, sole traders and, in most of the UK, partnerships. Corporate subscribers (limited companies, LLPs, public bodies) are outside reg. 22, though the UK GDPR still applies to the named person you are emailing, and regulation 23 applies to everyone: you must not disguise or conceal who the message is from, and you must provide a valid address at which the recipient can ask you to stop.

For a small site the practical reading is simple. A newsletter signup form is consent. A contact form is not consent to marketing, because writing to ask a question is not “negotiations for a sale” of anything. A customer who bought something from you may fall under the soft opt-in for similar things, provided you offered an opt-out at the checkout and offer one in every email. And a list you bought, scraped or were given is none of these.

The ICO’s Guide to PECR covers each of these points in plain language, and its direct-marketing guidance goes into the edge cases.

PECR says you need consent; the UK GDPR says what consent is. Article 4(11) defines it as a freely given, specific, informed and unambiguous indication of the person’s wishes by a statement or a clear affirmative action. Article 7 adds three obligations that bite in practice:

You must be able to demonstrate that the person consented (Art. 7(1)).
If consent is bundled into something else, the request must be clearly distinguishable and in plain language (Art. 7(2)).
Withdrawing consent must be as easy as giving it (Art. 7(3)).

Recital 32 rules out pre-ticked boxes and silence. A checkbox that is ticked by default is not consent. A visitor who fills in a form to download something and is quietly added to the newsletter has not consented to the newsletter.

The ICO’s consent guidance sets out what a record of consent should contain, and it is worth quoting the shape of it because it is exactly what you will be asked for if anyone ever complains:

Who consented: the name or other identifier.
When they consented: a timestamp, or a dated copy of a paper form.
How they consented: the form or page and the method (a ticked box, a double opt-in confirmation).
What they were told at the time: the wording of the consent statement and the privacy information shown, as it was then.
Whether they have withdrawn consent, and when.

Double opt-in is not required by UK law. It is, however, the easiest way to produce a record that satisfies all five points, because the confirmation click is dated, tied to an address the person controls, and unambiguous. It also keeps other people’s addresses off your list, which is the main cause of spam complaints, so the deliverability case and the compliance case point the same way.

In March 2017 the ICO fined two companies for sending emails that asked people about their marketing preferences.

Flybe was fined £70,000 for sending about 3.3 million emails in August 2016 to people who had opted out of marketing, with the subject line asking them to update their details and preferences and the chance to win a prize. The ICO’s finding was that an email asking whether someone wants marketing is itself a marketing email, and those people had already said no.

Honda Motor Europe was fined £13,000 for sending 289,790 emails asking whether customers wanted to hear from the company, on the basis that Honda could not show it had consent to send marketing to those people in the first place. Honda argued the emails were customer service, not marketing; the ICO disagreed.

The ICO’s monetary penalty notices for Flybe and Honda Motor Europe set out the reasoning. The lesson for a small site is not about the size of the fines; it is the principle. You cannot fix a list with no consent by emailing it to ask for consent. If you do not have evidence that someone agreed to hear from you, the lawful options are to obtain consent through some channel that is not a marketing email, or not to email them.

The maximum penalty under PECR was £500,000 at the time. The Data (Use and Access) Act 2025 provides for PECR penalties to rise to the UK GDPR maximum (up to £17.5 million or 4% of worldwide turnover) and extends the soft opt-in to charities; those provisions come into force by commencement regulations, so check the ICO’s site for the current position.

What changing provider does and does not require

This is the question we are asked most often when someone is considering moving to SendBeam, so it deserves a straight answer.

Consent is given to you, not to your software. Under the UK GDPR you are the controller; the email platform is a processor acting on your instructions. Moving from one processor to another does not change what your subscribers agreed to, so you do not need to ask them to consent again. Sending a “please confirm you still want to hear from us” email to a list that already has consent is unnecessary, and sending it to a list that does not have consent is the Honda problem.

What a change of provider does require:

A contract with the new processor covering the points in Article 28(3): acting only on your instructions, confidentiality, security, sub-processors, assistance with rights requests, deletion or return at the end, and audit. Platforms usually publish this as a data processing agreement; SendBeam’s is at /legal/dpa.
The evidence comes with the data. Export the consent record, not just the addresses: source, timestamp, IP where held, and the double opt-in status. If the old platform never kept it, you cannot invent it; those contacts should be left out rather than emailed, and you should decide what to do about them separately.
The suppression list moves first. Unsubscribes, bounces and complaints must be loaded into the new platform before a single address is imported, so that nobody who opted out on the old system is emailed by the new one. Then keep the old platform’s unsubscribes syncing for a period after cutover, because emails already delivered still carry the old unsubscribe links.
Update your privacy notice if it names the provider, describes where data is stored, or lists international transfers, and the new arrangement differs.
Check the lawful basis for anything that is not a newsletter. Transactional email (receipts, sign-in links) is not marketing and does not need consent, but it should not carry marketing content either, or it becomes marketing.

What it does not require: fresh consent, a re-permission campaign, or a gap in sending. If someone tells you otherwise, ask them which regulation they are relying on.

A practical checklist

Work through this once, and again whenever a form or a list changes.

Every list has a source. For each list you can say where the addresses came from: which form, which purchase flow, or which import, and the consent basis for each.
Forms are unambiguous. No pre-ticked boxes. The newsletter checkbox is separate from the terms checkbox. The wording says what people will receive and how often.
Contact forms do not subscribe. A message from a visitor creates a conversation, not a marketing contact.
Double opt-in is on for any list that collects addresses from a public page.
You can produce the record. For any contact, you can show who, when, how and what they were told.
Every email says who it is from and how to stop. A real sender name and address, a working unsubscribe link, and one-click unsubscribe headers for Gmail and Yahoo.
Unsubscribes are processed at once, and suppressed addresses stay suppressed through imports.
Soft opt-in customers were offered an opt-out at the point of sale and are only emailed about similar products.
Nobody is emailed to ask for consent.
When you change provider, the DPA is in place, the suppression list goes first, the consent evidence travels with each contact, and your privacy notice is updated.

Most of this is how a well-run small site behaves anyway. The value of writing it down is that when a complaint arrives, and eventually one will, you answer it in ten minutes with a record rather than in a week with an apology.

Again: this is a summary, not legal advice. The legislation is linked above and the ICO’s guidance is free; when the stakes are real, read both and take advice.

One-click unsubscribe and the bulk-sender rules: what Gmail, Yahoo and Microsoft check in 2026

SendBeam team — Sat, 05 Sep 2026 00:00:00 GMT

In February 2024 Google and Yahoo started enforcing a shared set of requirements for anyone sending bulk email to their users. Microsoft followed in May 2025 with matching rules for Outlook.com, Hotmail and Live addresses. The rules are not long, but they are checked by machines, and mail that fails them is junked or rejected without anyone telling you.

This post lists what the three providers actually require, shows you how to look at the headers of your own email to see whether you meet them, and then says exactly what SendBeam sets for you and what it does not. The last part matters: a platform that says “deliverability handled” without saying which headers it emits is asking you to take it on trust.

Who the rules apply to

Google’s requirements have two tiers. Every sender to Gmail must authenticate with SPF or DKIM, keep spam rates low and not impersonate Gmail in the From header. Senders of 5,000 or more messages a day to Gmail addresses must meet the full list below. Google’s own page is the reference: Email sender guidelines.

Yahoo published the same requirements for bulk senders at the same time; its Sender Best Practices page is the source. Microsoft announced in April 2025 that domains sending more than 5,000 messages a day to consumer Outlook addresses must have SPF, DKIM and DMARC in place, with non-compliant mail routed to junk from 5 May 2025 and rejected later; the announcement is on the Microsoft Tech Community.

Two practical points about the threshold. It is measured per sending domain, and Google counts across all your mail streams, so a site that sends 4,000 newsletter emails and 1,500 transactional emails on a busy day is a bulk sender for that day. And there is no benefit in staying under it: the requirements are also simply what a well-configured domain looks like, and the cheapest time to meet them is before you have a reputation problem.

The requirements, one by one

1. SPF and DKIM, both

SPF (RFC 7208) is a DNS record on the domain in the message’s return path that lists the servers allowed to send for it. DKIM (RFC 6376) is a cryptographic signature added to each message, verified against a public key in DNS under <selector>._domainkey.<domain>. Bulk senders need both to pass. When you send through any platform, the platform’s servers do the signing and the sending; what you control is whether the keys and the return path are set up on your domain rather than the platform’s.

2. A DMARC record, and alignment

DMARC (RFC 7489) is a TXT record at _dmarc.<your domain>. The minimum the providers ask for is v=DMARC1; p=none, which changes nothing about delivery but declares a policy and lets you receive reports. The part people miss is alignment: the domain in the visible From header must match the domain that SPF or DKIM authenticated. If your From address is news@example.com but the DKIM signature is for the platform’s own domain and the return path is the platform’s too, DMARC fails even though SPF and DKIM individually passed. For email sent through a platform, DKIM alignment (a signature whose d= is your domain) is the one to get right; an aligned return path gives you SPF alignment as well.

3. One-click unsubscribe, RFC 8058

For marketing and subscribed mail, bulk senders must include two headers:

List-Unsubscribe: <https://example.com/unsubscribe?token=...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

RFC 8058 defines how this works: the mailbox provider shows an unsubscribe button next to the sender’s name, and when the reader clicks it the provider sends an HTTP POST to that URL with the body List-Unsubscribe=One-Click. No page is shown to the reader, so the URL has to do the job on that POST alone, and it has to be safe against link scanners and prefetchers that follow every URL in a message with a GET. That is why the URL should carry a signed token and change state only on POST. There must also be a clearly visible unsubscribe link in the message body, and requests must be honoured within two days. A mailto: form of the header is allowed as well, but it is the HTTPS form together with List-Unsubscribe-Post that satisfies the one-click requirement.

4. Spam rate below 0.10%, never at or above 0.30%

Google measures the rate of user-reported spam per domain in Postmaster Tools and asks senders to stay below 0.10%, and never to reach 0.30%. Yahoo’s guidance is to keep complaints under 0.3%. These are low numbers. Three complaints in a thousand messages is enough to put you over the line, and the usual cause is not malice but an old list, a purchased list, or a signup form with no confirmation step that has been collecting other people’s addresses.

5. The rest

The remaining items are infrastructure: valid forward and reverse DNS (PTR records) for sending IPs, TLS for the connection, a From header that does not imitate gmail.com or yahoo.com, ARC headers if you forward mail on behalf of others, and standard formatting under RFC 5322. On a platform these are the platform’s responsibility. On your own server they are yours, and PTR records in particular are where self-hosted senders on cheap VMs fall down.

How to check your own headers

You do not need a tool to see most of this. Send yourself a campaign and look at the raw message.

Gmail: open the message, click the three-dot menu, then Show original. The summary at the top shows SPF, DKIM and DMARC as PASS or FAIL, with the domain each was checked against. Below, search the headers for List-Unsubscribe and List-Unsubscribe-Post. If the DKIM domain is not yours, alignment is your problem.
Outlook.com: open the message, click the three dots, then View > View message source. Look for Authentication-Results: near the top; it lists spf=, dkim= and dmarc= with the domains.
Apple Mail: View > Message > All Headers.

Then check DNS directly. From a terminal, dig TXT _dmarc.example.com shows your DMARC record, or its absence, and dig CNAME <selector>._domainkey.example.com shows whether the DKIM key is published. If you would rather not use a terminal, we are building a sender check that runs these lookups from a browser and reports alignment against a test message.

Finally, if you send to Gmail in any volume, register your domain in Postmaster Tools. It is free and it is the only place you can see the spam-rate figure Google is actually using.

What SendBeam sets automatically, and what it does not

Here is what a campaign or automation email sent from SendBeam carries, based on the code that sends it rather than on a feature list.

DKIM and an aligned return path for your domain. When you add a domain, SendBeam shows CNAME records: DKIM signing records and a return-path record on your domain. Once they resolve, mail is signed with d= your domain and the return path is on your domain, so both DKIM and SPF align with your From address. If your DNS is on Cloudflare, SendBeam writes the records for you from a one-time API token. See Sending domain.

Both RFC 8058 headers on every campaign and automation email. List-Unsubscribe points at a URL carrying a signed token bound to the contact and the campaign, and List-Unsubscribe-Post: List-Unsubscribe=One-Click is set alongside it. The unsubscribe URL changes state only on POST; a GET shows a confirmation page with a button, so link scanners cannot unsubscribe your readers by prefetching. The one-click POST is processed immediately, not queued, which is comfortably inside the two-day requirement.

A visible unsubscribe link. If a template does not include one, SendBeam adds one to the message body before sending. The same signed URL is used for the visible link and the header.

Bounces and complaints suppressed automatically. A hard bounce or a spam complaint adds the address to the workspace’s suppression list and it is not sent to again, including after a re-import. Only a hash of the address is kept once the contact is deleted.

Guardrails on your complaint and bounce rates. Over a rolling 30 days, SendBeam warns workspace admins when the complaint rate reaches 0.3% or the bounce rate reaches 5%, and pauses sending when complaints exceed 0.5% (once there is a meaningful sample) or bounces exceed 10%. The warning line is set at Google’s “never exceed” figure on purpose: by the time Gmail is unhappy, you should already have heard from us.

Double opt-in available on every list, and compulsory on Free. Confirmation is the single most effective thing you can do for your spam rate, because it stops other people’s addresses ever reaching your list.

Now the things SendBeam does not do, so you are not surprised.

It does not publish your DMARC record. DMARC belongs to your domain as a whole, covering your ordinary mail as well as SendBeam, so you add the _dmarc TXT record yourself. We recommend starting at p=none with a reporting address, moving to p=quarantine once you have confirmed everything aligns, and going to p=reject when you are confident. The docs page above has the record format.
On the Free plan, and before a domain is verified, mail goes from a shared SendBeam address. It is fully authenticated, so it meets the rules, but the reputation it builds is ours rather than yours, and the From address is not your domain. Verify your own domain before you send to a real audience.
Owner-notification emails from contact forms (the message a visitor writes to you) carry no unsubscribe headers, because they are not bulk mail and there is nothing to unsubscribe from.

A short checklist

Own domain verified, DKIM and return path resolving, From address on that domain.
_dmarc TXT record published, at least p=none with rua= so you receive reports.
Send yourself a campaign and confirm SPF, DKIM and DMARC all show PASS against your domain in Show original.
Confirm both List-Unsubscribe headers are present and that the visible link works.
Register in Google Postmaster Tools and look at the spam-rate graph once a month.
Switch on double opt-in for any list that collects addresses from a public form.

None of this is difficult, but all of it is invisible until something goes wrong. Ten minutes with Show original now is worth a great deal more than a week of wondering why open rates fell.

What Mailchimp, Kit, beehiiv, MailerLite and EmailOctopus cost when you run three sites

SendBeam team — Fri, 04 Sep 2026 00:00:00 GMT

Email pricing pages are written for one brand with one list. If you run three sites, the number you need is not on the page; you have to work out how the platform treats a second and third audience, and then multiply. This post does that for five platforms people ask us about, with a worked example at 1,000 contacts per site.

Two ground rules. First, every figure here comes from the platform’s own pricing page and was checked on 3 September 2026; pricing pages change, so treat this as a snapshot and use the links to verify. Second, we compare the cheapest plan that removes the platform’s branding from your emails, because that is the plan most people running a real site end up on. Where a free tier would genuinely do the job, we say so. Prices are in US dollars, billed monthly.

If you would rather put in your own numbers, the cost calculator uses exactly the same figures and rules, and the alternatives pages go platform by platform.

The unit of billing is the whole story

Every platform prices by list size in some form, but they differ on what a “list” is and whether you may have more than one.

Mailchimp organises contacts into audiences. The Free plan allows one audience of up to 500 contacts and 1,000 emails a month, with Mailchimp branding. On the plans we checked, running several sites in one account means several audiences, and each audience adds to the contact count you pay for; a person who subscribes to two of your sites is counted twice. Mailchimp also counts unsubscribed and cleaned contacts towards your total, which is unusual and worth knowing before you import a list with a long history. Automations are no longer on the free plan. The ladder we checked: 500 contacts at $13 (Essentials), 2,500 at $45 (Standard), 10,000 at $100, 25,000 at $270. Mailchimp pricing.

Kit (formerly ConvertKit) is built around one creator. An account is one identity with one subscriber list, so separate sites with separate brands need separate accounts. The free Newsletter plan is generous on size, up to 10,000 subscribers, but it carries Kit branding and allows one basic automation. The Creator plan removes both limits: $29 at 500 subscribers, $49 at 2,500, $119 at 10,000, $199 at 25,000. Kit pricing.

beehiiv organises everything around a publication. The Launch plan is free up to 2,500 subscribers with beehiiv branding. The Scale plan is $39 at both 500 and 2,500 subscribers, $79 at 10,000 and $129 at 25,000. Extra publications cost extra on most plans, so three sites generally means three lots of Scale or three separate free accounts. beehiiv is a newsletter product with a website, an ad network and paid subscriptions built in; it is not designed to handle contact forms or transactional mail for a site. beehiiv pricing.

MailerLite is the friendliest of the five to more than one site: one account can hold several websites and domains, and pricing is per account. The Free plan covers 1,000 subscribers and 12,000 emails a month with MailerLite branding and one user. Growing Business, which removes the branding, is $10 at 500 subscribers, $20 at 2,500, $54 at 10,000 and $130 at 25,000. Every subscriber is counted once across all your sites, which is exactly what you want, though the ladder steps up quickly once three modest lists are added together. New accounts go through an approval process before they can send. MailerLite pricing.

EmailOctopus is the cheapest per contact at scale and keeps things simple. The free plan covers 2,500 subscribers and 10,000 emails a month with EmailOctopus branding, 30-day reporting, one form and one landing page. Pro removes those limits: $10 at 500 subscribers, $16 at 2,500, $36 at 10,000 and $68 at 25,000. One account is one sender identity, so several sites means several accounts, and there is no transactional email or contact-form handling. EmailOctopus pricing.

Worked example: three sites, 1,000 contacts each

Assume three sites with about 1,000 contacts each, 3,000 in total, sending a newsletter a month or so to each. You want your own branding on the emails.

One method note, so the table is fair. Platforms publish prices at steps (500, 2,500, 10,000 and so on). Where 1,000 contacts falls between steps, the figure shown is the next rung up on the ladder we recorded, which is how the cost calculator works too. Some platforms have finer bands in their own calculator and will quote a little less for exactly 1,000; the shape of the result does not change.

Platform	How you have to buy it for three sites	Free option that fits?	Monthly, branding removed
Mailchimp	One account, three audiences, 3,000 contacts (10,000 rung); or three accounts at the 2,500 rung	No (Free is one audience of 500)	$100 as one account, or 3 × $45 = $135 as three
Kit	Three accounts, one per site	Yes, with Kit branding and one automation each	3 × $49 = $147
beehiiv	Three publications; extra publications cost extra on most plans	Yes, with beehiiv branding	3 × $39 = $117
MailerLite	One account, 3,000 subscribers (10,000 rung)	No (Free stops at 1,000 in total)	$54
EmailOctopus	One account, three lists, 3,000 subscribers pooled	Yes, with EmailOctopus branding (free to 2,500)	$31.50
SendBeam	One account, three workspaces, 3,000 contacts pooled	No (Free is 500 contacts, two workspaces)	$29 (Pro)

Prices checked 3 September 2026 (EmailOctopus re-read from its live slider on 4 September). USD, billed monthly.

Three things stand out.

First, the platforms that treat a second site as a second account (Kit, beehiiv, EmailOctopus) turn a small audience into a medium bill, or push you onto a free tier with their branding on every email you send. If you are comfortable with that branding, Kit, beehiiv and EmailOctopus will all run three 1,000-contact lists for nothing, and that is a perfectly reasonable choice for a hobby project.

Second, the per-account platforms (MailerLite, and Mailchimp if you accept multiple audiences in one account) do better, but their ladders step steeply once you add lists together. 3,000 contacts is priced on the 10,000 rung on both.

Third, the SendBeam figure is not the cheapest possible in every scenario, and we would rather you saw where. At exactly 3,000 pooled contacts you need Pro at $29, because Starter caps at 2,500 contacts (Starter does allow five workspaces, so three sites of 800 contacts each would be $9). At the other end, our largest plan is 50,000 pooled contacts; three sites of 25,000 would exceed it, and at that scale EmailOctopus at 3 × $94.50 = $283.50 a month is a real option we cannot currently match with a listed plan. And if what you actually run is a single newsletter that you want to monetise with ads or paid tiers, beehiiv’s price buys you tools we do not have.

The costs that are not on the pricing page

Three things tend to be missed when people compare on price alone.

Duplicate contacts. On any platform that counts per audience or per account, someone who signs up to two of your sites is paid for twice. For a portfolio of related sites the overlap is rarely zero. SendBeam also keeps contacts separate per workspace (a signup on one site is not a signup on another), so the same person on two of your sites is two contacts against your pool as well. The difference is that the pool is one number on one plan, not two invoices.

Unsubscribed and bounced contacts. Mailchimp counts unsubscribed and cleaned contacts towards the total you are billed on. If a list is old, a meaningful share of it may be people you can no longer email but are still paying for. Check how each platform treats suppressed addresses before you import.

Your time. Three accounts means three domain set-ups, three sets of DKIM records, three suppression lists that do not talk to each other, and three places to check when a subscriber complains. That is not a line on an invoice, but it is why small sites so often end up with no newsletter at all. We wrote about our own version of this in why we built SendBeam around one account for every site.

What to do with this

If you are choosing a platform for several sites, decide three things before you look at a single price: whether you can live with the platform’s branding on your email, how many contacts you have across all sites once duplicates are counted, and whether you need contact forms and transactional email or only a newsletter. Then put your real numbers into the cost calculator, which uses the same ladders as this post and will show you the plan on each platform, including ours.

And if you are already paying three times over, Move-in carries subscribers, suppressions and the consent evidence your old platform kept across into one account, workspace by workspace, and it is included on Pro and Business.

Why we built SendBeam around one account for every site you run

SendBeam team — Thu, 03 Sep 2026 00:00:00 GMT

We run five websites. None of them is big. There is a UK salary calculator, a UK house-price site, a directory of UK companies, a site of small image tools and a bidding SaaS used by a handful of businesses. Between them they have contact forms, newsletter signups, three weekly newsletters generated from live data, and the usual transactional email a SaaS needs: sign-in links, invoices, “your bid was accepted”.

That is not an unusual situation. Plenty of people run a portfolio of small sites: a freelancer with three client-facing brands, a developer with two side projects and a blog, a local business with a shop and a separate site for its trade customers. Every one of those sites needs email, and every one of them is too small to justify its own email budget.

SendBeam exists because the tools we tried were shaped for one brand with one list. This post is about what that shape cost us, and which decisions we made differently. It is the positioning post, so it is opinionated, but every claim about the product is something you can check in the docs.

What five sites’ email looks like on ordinary tools

Most email platforms are built around one identity. On some it is called an audience, on others a publication or a creator account. The name varies; the consequence does not. A second site means a second one of those, and a second one of those is either a second bill or a second account.

Here is what that turned into for us.

Five logins. Five dashboards, five sets of API keys, five webhook formats to handle bounces, five places to check when something looked wrong. When anything looks wrong, the first job is working out which account it happened in.

Costs that multiply instead of add. Per-audience billing means the price of email is roughly the price of one list times the number of sites, even when each list is tiny. A thousand contacts is a rounding error for any platform. Three lots of a thousand contacts, billed separately, is a real monthly cost. We have laid out the numbers platform by platform in what Mailchimp, Kit, beehiiv, MailerLite and EmailOctopus cost when you run three sites; the short version is that most of them charge you three times for what is, from your point of view, one small audience. You can check the two we quote most often yourself: Mailchimp’s pricing counts every contact in every audience, and Kit’s is one list per account.

Authentication set up five times, five different ways. Every domain needs its own DKIM keys and an aligned return path so that Gmail, Yahoo and Microsoft trust the mail. That part is unavoidable and correct. What is avoidable is doing it in five dashboards that each hand you a slightly different set of records, some as CNAMEs, some as TXT, some with a shared return path you cannot align to your own domain. DMARC, which you publish once per domain, then has to be checked against five different sending set-ups.

Suppression lists that never meet. When someone’s address bounces on one tool, the other four keep trying. When someone unsubscribes from a newsletter, the transactional tool for the same site has no idea. And when you move a list between tools, the unsubscribes are the thing most likely to get left behind, which is precisely the thing you must not leave behind.

Automation glued together by hand. Three of our newsletters are built from data. The house-price site emails each subscriber the sold prices in their own district when the Land Registry publishes a new month; the companies directory sends a weekly digest of newly incorporated companies; the salary site sends a weekly issue of pay and tax news. Each of those is a script that assembles an issue and calls an API. Five different SDKs and five different rate limits is a lot of surface area for what should be one job.

None of these problems is dramatic. Together they are the reason small sites end up with no email at all, or with a contact form that goes to a personal inbox and a newsletter that was going to launch next quarter for the last three years.

The shape we wanted

We wanted one account, one login, one bill, and inside it a clean separation per site. Not one giant list with tags for each site: that muddles consent, muddles reporting and means a mistake on one site is visible to subscribers of another. Each site should have its own contacts, its own lists, its own forms, its own automations, its own sending domain and its own team seats, while the plan and the money sit above all of them.

That is what a SendBeam account and its workspaces are. The account is the billed unit. Workspaces are the sites. Contacts and monthly emails pool across the account, so a site with 300 subscribers and a site with 3,000 share one allowance instead of each buying its own.

The decisions that followed

Once you commit to that shape, a number of product decisions make themselves.

Pooled plans, priced by contacts and never by domain

There are four plans: Free at $0, Starter at $9, Pro at $29 and Business at $79 a month. They are priced on total contacts across the account (500, 2,500, 10,000 and 50,000) and monthly emails (2,000, 15,000, 60,000 and 250,000). Free is two workspaces, Starter is five, and Pro and Business have no limit on workspaces. Adding a site never adds to the bill; only growing your audience does. The full table is on the pricing page, and we do not intend to add a per-domain or per-workspace charge later.

One workspace per site, and separation on purpose

A workspace is a hard boundary. Its contacts, suppression list, forms and domains belong to it alone. The obvious question is whether unsubscribes should sync across workspaces, and our answer is no: someone who unsubscribes from the house-price newsletter has not unsubscribed from the salary newsletter, because those are two different consents given on two different sites. Treating them as one would be wrong in law and rude in practice.

We should be equally clear about what that means in the other direction. A hard bounce recorded in one workspace does not currently suppress the same address in your other workspaces. That is a gap we know about and may close with an account-wide bounce list that you can switch on; complaints and unsubscribes will stay per site.

Delivery that is managed, not configured

You do not connect a delivery provider or paste an API key. Every workspace can send immediately from a shared platform address, and when you add your own domain, SendBeam shows you the CNAME records for DKIM signing and an aligned return path. If your DNS is on Cloudflare, it writes them for you from a one-time token. Bounces and complaints are handled automatically, every campaign and automation email carries an RFC 8058 one-click unsubscribe header, and there are guardrails that warn and then pause sending if complaint or bounce rates climb, so a bad import cannot quietly ruin the reputation of your other sites. The details are in the deliverability post.

Forms that do the two jobs small sites actually need

Two kinds of form: a signup form that creates a contact, with double opt-in available per list and compulsory on the Free plan, and a contact form that emails you the message with the visitor as reply-to and never creates a contact. Filling in a contact form is not subscribing, and the product should not pretend otherwise. Both kinds have an origin allow-list, rate limits and optional Cloudflare Turnstile.

An API and a scheduler, because newsletters from data are normal

Reads and writes through the API are on every plan; writes are metered per hour rather than gated. That is what lets a script assemble this week’s issue from live data and hand it to a template. There is nothing special about our five sites here. If you publish anything that changes weekly, you can do the same.

Move-in, because the hardest part is leaving

Most people who want this shape already have email running somewhere else, often in several places. Move-in is a migration service: suppressions go across first, then subscribers with whatever consent evidence your old platform kept, then forms and domains, then a parallel run, and unsubscribes on the old platform are synced for 30 days after cutover. It is included on Pro and Business. Contacts with no consent evidence at all are left out rather than emailed, and you are told who they were.

What SendBeam does not do

Positioning is as much about what you leave out.

No ad network. We do not sell ads into your newsletter or take a cut of sponsorships.
No paid subscriptions. There is no built-in paywall or reader billing. If your newsletter is the product and you want to charge for it, Substack or beehiiv will serve you better, and we say so on the alternatives pages.
No SMS. Email only.
No website hosting or landing-page builder. You bring the site; we handle the email.
No bring-your-own delivery keys. Delivery is platform-managed for everyone, which is how the guardrails and the deliverability defaults can be guaranteed.

If any of those is essential to you, we are the wrong choice, and it is better to know that now than after a migration.

What this blog is for

We are going to write about running email for small sites, honestly. That means the actual prices other platforms charge, checked on a stated date; what the mailbox providers now require and how to see whether you meet it; what UK law says about consent and about changing provider; and what we learn from sending three data-driven newsletters a week from our own sites. It will not become a list of subject-line tips.

If you run more than one site and email has been the thing you keep putting off, the Free plan covers 500 contacts and two workspaces, and Starter gives you five workspaces for $9 a month. Start with the site that most needs it.