The email stack for client projects: one service instead of three

You hand over a website or a shop and the question comes, every time: “What about email?”. Behind it are three different services to set up, maintain and explain to the client. This guide lays out what is actually needed and how to make it simpler.

The three services you set up for every client

1. Mailboxes on the domain. hello@, orders@, personal mailboxes for the owner and the team. They often end up on a per-user service whose cost grows with every new person.

2. Newsletters. Signup forms on the site, lists, seasonal campaigns. Another tool, with its own editor, its own lists and its own consent rules.

3. Transactional email. Order confirmations, password resets, site notifications. A third service, with an API key wired into the CMS or backend.

Each one makes sense on its own. Multiplied by every client, they become a small recurring project.

The problems that keep coming back

• Three DNS setups for the same domain, and the risk of a second SPF record that breaks everything.
• Three invoices and renewals to track, often billed to the agency and passed on to the client.
• Three sets of credentials to hand over when the client wants autonomy, or to recover when they switch suppliers.
• Mixed reputation: if the newsletter draws complaints, order receipts can suffer too.
• Fragmented support: when “an email didn’t arrive”, you first have to work out which of the three services to look at.

Keep transactional and marketing apart

Transactional email must not fail: if an order confirmation doesn’t arrive, your client’s customer picks up the phone. Newsletters, by nature, attract more unsubscribes and spam reports.

So keep them apart:

• separate sending streams for transactional and marketing mail, so one reputation doesn’t drag down the other;
• a subdomain for campaigns (for example news.client.com), with the main domain reserved for operational mail;
• one-click unsubscribe (RFC 8058) in newsletters, now expected by the big mailbox providers from bulk senders;
• webhooks for bounces and complaints, so problem addresses leave your lists automatically.

One workspace per client

The model Nilomail is built around is simple: one workspace per client, managed from your account.

Each workspace includes:

• mailboxes and a shared inbox on the client’s domain, priced per domain, with users included in the plan;
• newsletters: lists, segments, signup forms, double opt-in and a consent log;
• transactional email via REST API or SMTP relay, with scoped API keys, webhooks and a log of every message.

Domains, team and sending reputation stay separate from one client to the next. When a client wants autonomy, you invite them to their workspace; when they ask “why didn’t this email arrive?”, there is one place to look.

Technical checklist for a new client

1. Domain: add the client’s domain and a subdomain for campaigns.
2. DNS: MX, a single SPF record, DKIM for domain and subdomain, DMARC starting at p=none.
3. Senders: verify the sending addresses (noreply@, news@) with the right display name and reply-to.
4. Transactional: create an API key with send-only permissions and add it to the CMS or backend.
5. Webhooks: register an endpoint for deliveries, bounces and complaints.
6. Newsletters: a signup form with double opt-in and consent text, a postal address in the footer, one-click unsubscribe.
7. Team: invite the client and their staff to the workspace with the right roles.
8. Verify: send a test of each kind (mailbox, transactional, test campaign) and check SPF, DKIM and DMARC in the headers.