Branded transactional email and a client login that lands in the inbox.

Two surfaces, one system.

Every operating company hits the same two surfaces the week it gets its first real customer: transactional email that has to reach the inbox, and a branded login that has to be safe to hand a stranger. They feel like plumbing, so they get treated like plumbing, which is exactly why they fail in public. The deliverability and the credential discipline are the parts that are actually hard, and they are the parts a small team is most tempted to skip.

None of what follows needs a platform or a heavy dependency. It needs a few decisions made once, in the right place, and a willingness to treat the boring details as the work rather than the afterthought. What makes it one system instead of two chores is that the email and the login share a brand, share a guard, and share a single source for how everything looks.

Transactional email: the inbox is the spec.

A welcome message, a set-password link, a receipt, a lead delivery: these are one-to-one, expected, and the recipient wants them. The whole job is to make the mailbox provider agree that they are legitimate. That turns out to be less about content and more about a few headers and one hard guard.

Send transactional mail with tracking off.

The instinct is to track opens and rewrite every link, on everything. For transactional mail that instinct is backwards. A one-to-one expected message does not need an open pixel or rewritten links, and both hurt placement: they make a legitimate receipt look like a marketing blast to the filters. So the default for transactional sends is tracking off, links left alone. Broadcast and outreach mail opt back in explicitly, because there the engagement signal is worth the placement cost. Two streams, two defaults, decided once at the sender rather than argued per message.

Set the unsubscribe headers, even on mail nobody unsubscribes from.

Gmail and Apple Mail read the List-Unsubscribe header and its one-click companion List-Unsubscribe-Post: List-Unsubscribe=One-Click as a legitimacy signal, not just a courtesy. A per-recipient unsubscribe value, derived automatically from the recipient address, gives the mailbox provider a native unsubscribe control and scores the message as coming from someone who plays by the rules. The header costs nothing to add and it moves placement. The standards behind it are public and stable; the references are at the end of this piece.

The send guard that should have existed before the incident.

This is the pattern worth stealing. A seed run that generated demo data once fired on the order of a hundred and seventy emails to fabricated @demo.test recipients. Every one queue-expired, which is the exact abuse shape an email provider auto-flags, and the sending account went under an outbound hold. The fix is one guard that every send path shares:

• Fake-domain refusal. The sender unconditionally refuses obviously non-routable recipient domains: the reserved suffixes .test, .invalid, .example, .localhost, and the reserved example domains. There is no legitimate reason to deliver real mail to these, so the refusal is not a warning, it is a hard stop that fails loudly.
• Dry-run by default for data tooling. An environment flag puts the sender in build-the-record-but-never-send mode. Seed and demo generation turn it on by default, so building a fixture data set can never email a human.
• Live-send allowlist. Scripts that genuinely intend a real send target an explicit allowlist of real addresses unless an operator passes an explicit opt-in flag.

Put it at the sender, not in each caller, so signup, portal, delivery, and every one-off script inherit it. The lesson generalizes well past email: any tool that can take a destructive action against a live external service needs a guard that fails closed, lives at the chokepoint, and cannot be skipped by the next script someone writes in a hurry.

One brand, one source.

Website, dashboard, and email should pull their colors, fonts, and logo from a single source of design tokens, one tokens file feeding a CSS variable set, a Tailwind preset, and the email shell, rather than three hand-maintained copies that drift apart. Email is the hard target: table-based layout, because Outlook desktop never adopted flex or grid; every style inlined on the element, because clients strip <style> blocks; a 600px maximum width so phones do not scroll sideways; and one image served from a public URL, because inline attachments render unevenly across clients. The single token source is what keeps the welcome email and the login screen from looking like two different companies.

The client login: safe to hand a stranger.

The login is where a small team's shortcuts become a liability someone else carries. Three decisions cover most of the risk, and none of them requires a new dependency.

Never email a password.

The welcome email carries a single-use, expiring link, not a credential. The link holds a token shaped id.secret; the store persists only the id and a SHA-256 of the secret half, so a leaked store file cannot be replayed to set a password, because the attacker would still need the secret that only ever lived in the email. The token is single-use, marked consumed the moment it is spent, and short-lived in two flavors: a generous lifetime for the welcome set-password link, because a client may open the email days later, and a tight one for password reset. Lookup is by id, and the secret is compared in constant time.

Hash with what you already have.

No password-hashing dependency is required. The platform's standard-library scrypt does the job: a fresh random salt per password, stored as a self-describing record (algorithm, cost parameters, salt, hash) so a future cost bump is detectable per record, verified in constant time, with a sane minimum length floor and an upper bound to refuse oversized inputs. Plaintext is never persisted. The cost parameters we used are reasonable defaults, not a standard you must copy; the point is that the capability is already in the runtime, so reaching for a third-party library here is adding surface, not safety.

Stateless signed sessions, domain-separated.

The session is an HMAC-signed cookie with no server-side session store: a small payload (customer id, issued-at, expires-at), base64url-encoded, with an HMAC appended and checked in constant time. The detail that matters when one codebase serves more than one audience, here an operator-facing view and a customer-facing portal, is key domain separation. The portal's HMAC key is derived by mixing a fixed scope string into the base secret, so a token minted for one audience can never validate for the other even though they share a root secret. Lifetimes match behavior: a short window for an operator's working shift, a longer one for a customer who checks in occasionally.

The honest limits.

This is a small-budget substrate, not an enterprise identity platform. Stateless signed sessions cannot be revoked before they expire without an extra denylist, so the customer lifetime is kept modest rather than indefinite. A JSON-file credential store is fine for the first hundreds of accounts and wants a real database past that. None of the deliverability work guarantees the inbox; it removes the own-goals that guarantee the spam folder. And the send guard is a floor, not a substitute for getting the sending domain's SPF, DKIM, and DMARC aligned before the first real send. Knowing where the floor is matters as much as the floor itself.

What carries across companies.

Four pieces generalize past any one build: the transactional-versus-broadcast tracking split, the fail-closed send guard at the sender, the email-a-link-never-a-password credential flow, and the single design-token source feeding every surface. They are not a product. They are patterns the firm runs on its own deployments first, the way everything it builds has to earn its place by working on Rarefied Earth's own operation before it is ever offered to anyone else.

Sources and further reading.

How Rarefied Earth runs this.

These patterns came out of a real build, then were stripped of anything specific to the engagement and kept only as the reusable shape. That is the firm's standing rule for any capability it develops: it is the first user, the thing runs on Rarefied Earth's own operation before it is offered to a client, and it earns its place by working there first. The transactional sender, the send guard, the credential flow, and the shared token source are pieces of that operating substrate, not a product on a shelf. When one of them is solid enough to hand to a company that is not us, that is the day it becomes a module.

Related work.

This is one slice of the operating substrate the firm argues every company now needs. The field guide on why most company AI projects stall makes the case for the substrate as a whole, operating substrate for startups covers what to install in the first 90 days, and research once, harvest three ways explains the operating model that turns a build like this one into a published field guide.