Email for multiple websites: the definitive guide

Most email tools were designed for one brand with one list. The moment you run a second site — a blog and a shop, two newsletters, your own project and a client’s — you meet the same three problems: the tool wants everyone in one audience, it wants every message to come from one domain, and it wants to charge you again for the second site. This guide is about avoiding all three, with SendBeam or with anything else. Where a step refers to a SendBeam screen, it is because that is the product we can speak for; the principles hold everywhere.

Structure: one account, one workspace per site

Start with the shape, because everything else follows from it. There are only two sensible layouts for multi-site email: a separate account per site, or one account that holds separate spaces per site. Separate accounts give you clean separation and a mess of logins, invoices and forgotten API keys. A single account with everything in one list gives you one login and a slow-motion compliance problem. The layout you want is the third one: one account, with a hard wall between sites inside it.

In SendBeam that wall is the workspace. A workspace holds a site’s contacts, lists, tags, segments, campaigns, templates, automations, forms, sending domains, API keys and team. Nothing crosses the wall: a segment cannot see another workspace’s contacts, a form can only add to its own workspace’s lists, and a key created in one workspace cannot read another. What workspaces share is the account’s plan. Contacts, monthly emails, verified domains, live automations and seats are counted across every workspace and checked against one cap, which is what makes the bill flat when you add a site.

The practical rules that come out of this:

• Name workspaces after sites, not after purposes. “Blog”, “Shop” and “Client: Acme” age better than “Marketing” and “Sales”, because the wall is between sites, not between departments.
• Put a personal project and a client project in different workspaces even if you are the only person who will ever log in. The day you hand the client a seat, you will want them to see only their own data. In SendBeam you can be an admin in one workspace and a plain member in another.
• Do not split one site into several workspaces to mimic lists. Lists, tags and segments exist for that; a workspace is the unit of consent, reputation and access.
• Check the workspace allowance on the plan before you commit. SendBeam allows 2 workspace on Free, 5 on Starter and unlimited on Pro and Business; the creation form under Account settings → Account → Workspaces shows the count against the allowance.

A sending domain and DMARC per site

Mailbox providers judge the domain after the @ in the from-address, not the tool that sent the message. If two sites share a from-domain, they share a reputation: a scraped list on the second site drags the first site’s newsletter into the spam folder, and a DMARC report from the shared domain cannot tell you which site caused the failures. So the second rule of multi-site email is one verified sending domain per site, and in SendBeam that is enforced rather than recommended: a domain is verified inside a workspace, and only that workspace may send from it. The from-address is checked when you save it and again on every send.

Verifying a domain is a handful of CNAME records — a DKIM signing record and a return-path record — added at your DNS provider and set to DNS-only, not proxied. SendBeam re-checks them about every minute and moves the domain from Add DNS records through Verifying to Verified, usually within minutes. Repeat per workspace; on Starter you may verify 3 domains across the account, on Pro and Business as many as you have sites.

Subdomain or root?

Send newsletters from a subdomain (news.yourbrand.com) and keep the root domain for the mail your people write by hand. Reputation is tracked per domain, so a bad newsletter month does not affect the invoices and support replies that go out from @yourbrand.com. Transactional email from your app can go from a second subdomain if its volume or content differs a lot from the newsletter. You do not need a separate domain per purpose on the same site; you do need one per site.

DMARC, per domain

Because SendBeam signs with DKIM for your domain and aligns the return path so SPF passes too, your mail passes DMARC. Publish a policy for every sending domain — a _dmarc TXT record with v=DMARC1; p=quarantine or stricter and a rua= address — and read the reports for each domain separately. A per-site DMARC record is also how you find out that someone is forging one of your brands, which they will do to the brand with the most customers, not the one you check most often.

Shared or separate audiences, and why sharing is usually a consent problem

Here is where multi-site setups go wrong quietly. Someone subscribes to your cooking blog. You also run a gardening newsletter. It is tempting to treat those as one audience with two “interests”, and to write to the cooking subscriber about gardening because, after all, they gave you their address. They did not give it to the gardening site. Under GDPR and PECR, consent is specific: it covers the purpose the person was shown when they signed up, and “email from this website” is a different purpose from “email from this other website that happens to have the same owner”. The same logic applies under CAN-SPAM in spirit and under most sender policies in practice: people report as spam the email they do not remember asking for, and the second site’s reputation pays for it.

So the default is separate audiences per site, which a workspace-per-site structure gives you without effort. Each site has its own lists, its own double opt-in setting, its own suppression list and its own unsubscribe. If the same person subscribes to two of your sites, they are two contacts with two consent records and two unsubscribe links, and that is correct: leaving one newsletter is not leaving the other.

When sharing is legitimate

• Two sites, one brand. A shop and its blog under the same name, where the signup form on either says what the reader will receive from both. Then it is one workspace with two lists or two tags, not two workspaces, and the consent text is doing the work.
• An explicit cross-promotion. Send the cooking list one campaign that invites them to the gardening newsletter with a link to its own form. That is marketing you have consent for (email from the cooking site), and the gardening subscription that results has its own record. Do not copy the contacts across.
• A company-wide announcement (a privacy-policy change, an ownership change) is usually a service message, and can be sent from each workspace to its own audience. It is still not a reason to merge them.

The one thing that should be shared between sites is the knowledge of who has opted out — see no suppression sync below.

Contact-form notifications per site

Contact forms are the part of multi-site email nobody plans and everybody needs. Each site has a “get in touch” page, each posts somewhere, and after the third site the somewhere is a tangle of form services, PHP mailers and a Zapier account. Two things matter: the message should reach the right inbox with the right context, and a bug report should not turn the sender into a newsletter subscriber.

SendBeam treats a contact form as a form type, next to signup. The visitor’s message is emailed to the address you set, from that workspace’s verified sending address, with the visitor as Reply-To, so you answer by pressing reply. No contact is created and no automation fires; writing in is not subscribing. Per site you get:

• A destination per form — a workspace member’s address or any address on that workspace’s verified domains — so the shop’s messages go to support and the blog’s to you.
• A subject prefix per form, such as [Acme site], so filters in your inbox can sort by site.
• Protection per form: automated-submission checks, per-visitor rate limits and a daily cap, all on by default; plus an Allowed sites origin allow-list and Cloudflare Turnstile that you switch on for the forms on public pages.
• Honest failures: if the notification cannot be sent, the visitor sees an error rather than a false “sent”, so the page can offer a mailto: link.

Signup forms can notify you as well (Email me about new subscribers), which is a cheap way to notice the day a form starts receiving junk. Notifications appear in the Log tab under Reports for each workspace.

Automations per site

A welcome series, a lead-magnet delivery, a “you have been quiet” nudge: each site wants its own, and they should not be able to touch each other’s contacts. In a workspace-per-site structure that is automatic, since an automation only sees the contacts, tags, forms and templates of its own workspace. What you plan per site is the trigger and the first step:

• Newsletter welcome: List Joined on the newsletter list. On a double opt-in list it fires when the person confirms, not when they submit, so nobody unconfirmed gets a welcome.
• Lead magnet: Form Submitted on that form, then an immediate Send Email. The first step runs the moment the form is submitted, so the file arrives straight away.
• Purchase follow-up: Tag Added for a tag your checkout applies through the API; a Condition later in the sequence (tag does not contain refunded) acts as a gate.

Two cross-site cautions. First, the number of live automations is pooled on the account (1 on Free, 5 on Starter, unlimited on Pro and Business), so a fourth site’s welcome series may be the one that needs the upgrade. Second, importing a site’s existing audience fires Contact Created for every newly created subscribed contact, so pause that site’s welcome automation before the import or import with the default status set to Unsubscribed and confirm them properly afterwards.

The pricing maths of N sites

The decisive number in multi-site email is not the price per thousand contacts. It is whether the tool bills per site or per account. Platforms fall into three groups. Some are one list per account, so a second site means a second account and a second bill (Kit, EmailOctopus, Substack). Some allow several audiences or publications but price each one (Mailchimp, beehiiv, Buttondown, Brevo on its lower plans). A few pool everything into one account price (MailerLite). SendBeam is in the last group: the plan covers the account, and workspaces are free within its allowance.

Take three sites with 2,000 contacts each, sending four emails per contact per month. That is 6,000 contacts and 24,000 emails on the account, which fits SendBeam’s Pro plan at $29 a month. On the per-site platforms the same setup is three bills:

Source · each platform's pricing page · checked 2026-09-04 · monthly USD

Monthly USD, billed monthly, cheapest plan without platform branding, per-site prices multiplied by the number of sites. Pricing pages checked on 2026-09-04; Substack is omitted because it charges a share of paid revenue rather than a fee. Every figure here is produced by the same code as the cost calculator, so if a rival is cheaper at your size the calculator will say so.

Read the table honestly. At small sizes the free tiers of per-site tools can beat a paid pooled plan: five sites of 500 contacts each are free on several platforms because each site fits a free plan on its own account, while on SendBeam the workspace allowance (2 on Free, 5 on Starter) means five sites need Starter at $9. What you buy for that is one login, one set of suppressions per site that you can actually manage, your own domain on each site without a badge, and no re-shuffle when one site grows. As soon as any site outgrows its free tier the per-site bills start stacking, and that is when pooled pricing wins by a wide margin: in the three-site example above, the dearest per-site platform is $110 a month against $29.

Two more things the price ladder hides. Mailchimp charges for unsubscribed and cleaned contacts, so a per-site bill keeps growing after people leave. And email-priced plans (Brevo) look cheap until a newsletter site sends four issues a month to everyone; check the included volume, not only the contact cap. SendBeam’s plans cap both — Starter is 2,500 contacts and 15,000 emails a month across the account, Pro 10,000 and 60,000, Business 50,000 and 250,000 — and the calculator picks whichever cap binds first.

Mistakes that cost you the inbox

One shared “from” domain

Covered above, but it is the most common mistake so it earns its own heading. The variant to watch for is the shared tool domain: every site sending from the platform’s own address because nobody got round to DNS. SendBeam lets a new workspace send at once from its own authenticated shared address (ws-<id>@mail.sendbeam.io, from a separate pool on Free), which is fine for testing and a first campaign. Move each site to its own domain before it has a real audience; recipients recognise the domain, and the reputation you build belongs to your brand.

No suppression sync

Separate audiences per site are right. Forgetting that the same human can opt out of one site and be re-imported into another is how separate audiences become complaints. The rule: every list you import into any site goes through the suppression list first, and the suppression list is where you record every unsubscribe, bounce and complaint from the old platform before the first contact arrives. SendBeam keeps one suppression list per workspace, enforced everywhere an address could sneak back in: a CSV import brings a suppressed address in as unsubscribed whatever the file says, the API refuses it with 409, and the only way off is a fresh opt-in by the person themselves. You can import suppressions from the dashboard or with POST /api/v1/suppressions/import, and query one address at a time to check. When you migrate, keep a 30-day sync of late unsubscribes from the old platform, per site.

Forgetting double opt-in on the second site

The first site was set up carefully. The second was set up on a Friday afternoon by copying a form and pointing it at a new list, and the new list is single opt-in because that is the default in most tools. Six months later the second site has a bot-filled list and a bounce rate that pauses sending. Double opt-in is a list-level setting; switch it on when you create the list, and update the form’s thank-you message to say “check your inbox”. On SendBeam’s Free plan every list behaves as double opt-in, and confirmation emails go out at most once per address every ten minutes however often a bot hammers the form.

One API key for everything

An integration on the client’s site should not hold a key that can read your own newsletter. Make a key per workspace with only the permissions that integration needs (contacts:write for a checkout, campaigns:write for transactional sends), and revoke it when the integration is retired. Keys are shown once and stored hashed, so there is no “find it later”.

Reading only the account total

Pooled caps are a convenience, not a substitute for per-site attention. Check each workspace’s bounce and complaint rates: SendBeam warns admins when a workspace crosses the warning level and pauses it at the pause level, and a pause on one site is a warning about your list sources everywhere.

Moving N sites without losing consent

Migrating several sites is the same job several times, and the order matters more than the tool. For each site: suppressions first, then the sending domain, then the subscribers with their tags, fields and consent evidence, then a parallel run while forms and links are switched, then cutover with a 30-day unsubscribe sync from the old platform. Do not merge sites during a move, even if the old platform had them jumbled together; a move is the chance to give each its own workspace and its own records.

Consent evidence is the part people lose. Mailchimp and MailerLite export signup IPs and confirmation times; Kit exports the signup source but no IP; CSV exports from most platforms carry status and dates but rarely proof. Carry whatever exists into fields that travel with the contact (SendBeam stores consent_ip, consent_confirmed_at and consent_source as custom fields), and leave out contacts with no evidence at all rather than email them and hope. Nobody needs to re-confirm because you changed provider; they do need to have confirmed once.

You can do all of this yourself with the CSV importer, the suppression importer and the in-app importers for Mailchimp, MailerLite, Kit, Brevo and EmailOctopus, on any plan. Or hand it over: Move-in is included on Pro and Business and covers every workspace on the account in one request, two to five business days from scope to cutover, with a migration log per site.

Agencies with client newsletters

The agency case is multi-site email with an extra requirement: the client must be able to see, and eventually own, their own setup without seeing anyone else’s. Give each client a workspace named after the client, verify the client’s domain in it (the DNS token is used once, so you can ask the client to run that step), and invite the client’s marketing lead as a member or admin of that workspace only. Your own login belongs to every client workspace; theirs belongs to one. If the engagement ends, the export gives them everything the workspace owns as one JSON file, and removing your seat is a team change, not a data migration.

Two structural questions to settle in the contract. Who holds the account (and therefore the plan and the pooled caps)? If it is you, a client whose list balloons eats the pool; watch the Billing page and bill it through. And who owns the sending domain’s DNS? The client should, always: reputation attaches to their domain and should leave with them.

Publishers with several titles

A publisher with three titles has three audiences that overlap more than an agency’s clients do, and a stronger temptation to cross-mail them. Keep a workspace per title anyway. Each title has its own sending domain or subdomain, its own double opt-in list, its own welcome automation and its own suppression list, so a title that pivots to a new subject does not drag the others’ complaint rate with it. Cross-promote by campaign — a “from our sister title” issue with a link to the other title’s form — and watch the form’s Email me about new subscribers notifications to see whether the promotion worked. Segments by custom field (a region or interest captured on the form) let you tailor issues within a title without splitting it.

On pricing, publishers are where pooled plans matter most: a 6,000-subscriber flagship and two 800-subscriber spin-offs are 7,600 pooled contacts on one plan, where per-publication platforms would charge for the flagship and add a fee for each spin-off.

The checklist

1. One account. One workspace per site, named after the site.
2. One verified sending domain (or subdomain) per workspace, DNS-only records, DMARC published per domain.
3. Separate audiences per site; cross-promote by campaign, never by copying contacts.
4. A contact form per site with its own destination, subject prefix, allowed origins and Turnstile.
5. Double opt-in on every newsletter list, with a thank-you message that says so.
6. Suppressions imported first on every site, and a 30-day unsubscribe sync after any migration.
7. Welcome and lead-magnet automations per site, paused before any bulk import.
8. One API key per workspace, minimum permissions, revoked when retired.
9. Per-site bounce and complaint rates checked, not just the account total.
10. Pricing checked against the pooled caps that actually bind — contacts and emails — in the calculator.