Email authentication for solo founders

Don't let the experiment
burn the flagship.

Give the side project its own domain with its own DKIM key and let it send through a separate SES reputation from the main company's. Because mailbox providers score the signing domain, a noisy experiment or cold-outreach batch can't drag the flagship into spam. Folio binds each domain as its own sender and reads both domains' DMARC reports, so a stealth project's spoofers surface before launch.

Your main company spent two years earning its way out of the spam folder. The side project you're testing this month has no reputation at all — and the first thing it does is send cold outreach. On shared infrastructure, that's the same envelope: one noisy experiment, and the flagship's inbox placement goes with it.

Folio gives every domain its own DKIM key and its own SES sending reputation, so the experiment can be as scrappy as it needs to be without the main company paying for it. And it reads the DMARC reports for both — so the stealth project isn't being spoofed before it has a single customer.

Updated 22 June 2026 (2026-06-22)

Start free — no cardSee the price

Android app live on Google Play

I · Why shared reputation is the trap

One sender score for two very different senders.

Mailbox providers don't score you as a person. They score the domain that signed the message and the IP that sent it. Run the main company and the side experiment through the same authenticated sender, and the receiver has no way to tell the careful, two-year-old newsletter apart from the first batch of cold invites that goes out under the same key.

So the side project's complaint rate becomes the main company's complaint rate. A spam-trap hit on the experiment is a spam-trap hit on the flagship. The very thing you'd want isolated — the reputation of mail nobody asked for — is fused to the reputation you can least afford to lose.

The usual workaround is a second domain on a second provider: Resend for the experiment, Workspace for the company. Now you've split the reputation but also split everything else — two DNS setups, two DKIM rotations, two DMARC inboxes full of XML, two places a spoofed From line can go unnoticed. The boundary is real, but so is the overhead, and the visibility is worse, not better.

A side project should be allowed to fail. It should not be allowed to take the main company's deliverability down with it.

II · A week of one founder's mail

Two reputations. One reading view.

Not a screenshot — a live render in the same editorial design system the app uses. Each row's stripe is the domain the letter was sent to. Hover (or read quickly, by eye): which self is each one addressed to?

III · How Folio keeps the boundary

A separate key, a separate reputation, per domain.

Every domain you bind to Folio is its own sender. Its own RSA-2048 DKIM key, its own per-domain SPF, its own SES sending reputation, and its own automatic reply-From. The experiment and the flagship never share the thing a mailbox provider scores — so a noisy launch on one can't move the other's inbox placement. One reading surface, one sign-in; the isolation is in the infrastructure, not in your attention.

  • ·
    Per-domain DKIM, per-domain reputation. Each bound domain signs with its own key, so receivers evaluate it on its own record. A complaint storm on the experiment's domain never lands on the flagship's score.
  • ·
    Reply-From follows the domain. A reply to a cold-outreach thread on try-driftwood.com goes out as try-driftwood.com — signed by that domain's key, not the company's. You never accidentally send the experiment's mail under the flagship's reputation.
  • ·
    DMARC visibility before launch. The Deliverability dashboard reads each domain's aggregate (rua) reports, so a stealth project being spoofed shows up the day it starts — not after a customer forwards you the fake.
  • ·
    Three domains, one flat price. Solo — $2.99/mo billed annually ($35.88/yr), or $3.50/mo — covers main, experiment, and stealth, up to 3 domains and 1,000 sends a month. Studio takes you to 10 domains and 6,000 sends; Holding Co. is unlimited domains with onboarding and priority support.

IV · What protects each domain

The pieces that keep one domain's noise off another.

These are the mechanisms doing the isolating — and the ones giving you the visibility to tighten policy safely. Reputation is not proof of identity; a clean pass rate tells you mail aligned, not that any given sender is who they claim. Authentication and reputation are different questions, and Folio keeps them separate.

Per-domain DKIM
Each bound domain gets its own RSA-2048 signing key (per RFC 6376). Receivers verify and score the signing domain, so reputation is scoped to the domain — never pooled across your projects.
Per-domain SES reputation
Separate sending reputation per domain means a bounce or complaint spike on the experiment is contained. The flagship's hard-won sender score is never collateral.
Inbound anti-spoofing
Mail that fails authentication is filed to Spam on arrival, with every check explained plainly. Missing or temperror auth fails open, so a transient DNS hiccup doesn't bury legitimate mail.
DMARC the moment you bind
The dashboard reads rua reports per domain — pass-rate rollup, named failing sources, published policy — so a stealth domain's forgers surface before launch, not after.

V · Common questions

Questions readers ask.

Will my side project's cold email hurt my main company's deliverability?

Not if they're on separate domains with separate signing keys. Mailbox providers score the domain that signed the message (per RFC 6376) and the IP that sent it — not you as a person. Folio gives each bound domain its own DKIM key and its own SES sending reputation, so a complaint or bounce spike from the experiment's cold outreach is contained to the experiment's domain. The flagship's sender score is evaluated on its own record and stays untouched.

Should each project have its own DKIM key?

Yes — that's the whole isolation mechanism. A shared key means a shared reputation: receivers can't tell the careful newsletter apart from the experimental blast if both are signed by the same domain. Folio issues a distinct RSA-2048 DKIM key per bound domain, alongside per-domain SPF and a per-domain SES sending principal, so each project's authentication and reputation are genuinely its own. One key per project is the difference between a contained failure and a portfolio-wide one.

How do I keep a stealth project's domain from being spoofed?

Publish a DMARC record with a rua= address pointing at Folio the day you register the domain. Folio reads the aggregate reports and shows you, per domain, which IPs are sending as you and whether they pass authentication — so a forger using your From line surfaces before you have a single customer to be embarrassed in front of. Then walk the policy up from p=none to p=reject once a clean window proves your own mail aligns, and receivers honoring DMARC will reject the forgeries.

Why is my startup's email going to spam?

Usually one of two things: the domain isn't authenticating (SPF, DKIM, and DMARC not aligned, so receivers can't verify it), or it's sharing reputation with a noisier sender. A new domain also simply has no reputation yet and has to earn it with consistent, low-complaint mail. Honesty matters here: passing authentication is not a trust badge and won't by itself rescue placement — it's the floor. Folio's domain-health tool shows which of these is your problem before you guess.

How do I authenticate a new domain before launch?

Point the domain's MX at Folio and bind it. Folio provisions a per-domain DKIM key and SPF record for you; you publish a DMARC record (start at p=none) with a rua= reporting address so the dashboard can read who's sending as you. Run a few test sends — the free tier includes 100 sends and the first domain free — confirm they align in the reports, and you have a domain that authenticates from its first real message rather than learning the hard way after launch.

When should I move a domain to p=reject?

Once a full reporting window shows effectively every legitimate message passing DMARC alignment, and the only remaining failures are forgers rather than your own senders you forgot to authorize. The dashboard distinguishes the two — a real sender failing SPF is a fix-it, not a reject-it — and marks a domain clean when it's ready. Then climb the ladder p=none → p=quarantine → p=reject, so the only mail you ever start rejecting is mail you didn't send.

VI · Adjacent readers

Other shapes of the same problem.

VII · Sources & further reading

Where the claims come from.

Open the first letter

Authenticate the experiment before it touches the flagship.

Bind the experiment's domain and the main company's domain. Each gets its own DKIM key and its own sending reputation; publish one rua= line and watch both domains' DMARC reports turn into a single answer — can either of these be spoofed? First domain free, 100 sends to test it. Start free — no card.

Start free — no cardRead the manual

Updated 22 June 2026 (2026-06-22)