Email authentication for a holding-company-of-one

Every brand signed.
The whole house, one rollup.

A holding-company-of-one is one operator running a parent entity plus several brands, each mailing from its own domain. Folio authenticates every domain separately — its own RSA-2048 DKIM key, SPF, and SES reputation — then reads all their DMARC reports into a single portfolio pass-rate rollup. You see every brand's authentication health, and exactly who is spoofing any of them, from one dashboard.

You run the parent entity and several brands beneath it — an agency, a Shopify store, a small SaaS, the LLC that holds the IP. Each one mails from its own domain, which means each one can be forged from its own domain. The question is whether you'd ever notice.

Folio gives every domain its own RSA-2048 DKIM key and its own sending reputation, then reads the DMARC reports back from all of them into a single pass-rate view. One operator. One dashboard. No brand falling through the cracks.

Updated 22 June 2026 (2026-06-22)

Start free — no cardSee the price

Android app live on Google Play

I · The problem with authenticating a portfolio alone

Six domains is six blind spots.

Authentication is per-domain by design. Each brand under your holdco publishes its own SPF record, signs with its own DKIM key, and declares its own DMARC policy. That isolation is correct — a forger spoofing the agency shouldn't implicate the parent — but it means the visibility is fragmented too. Every provider that receives mail claiming to be one of your brands mails back a daily DMARC aggregate report, in raw XML, per provider, per domain.

For one operator running half a dozen brands, that's a dozen unreadable attachments a day across six From lines. So they pile up unread. The brand whose policy never moved off p=none stays spoofable, the SaaS sending password resets from an unauthorized IP keeps failing alignment, and the only place this is visible — those reports — is the one place nobody is looking.

The standard answer is a separate DMARC tool per domain: six logins, six dashboards, six bills, six chances to forget one exists. The actual requirement is simpler — every brand isolated where it should be (keys, reputation, policy), consolidated where it helps (one rollup, one reader, one glance at whether the whole house is still spoofable).

A holding company keeps its entities separate on purpose. Their authentication should be just as separate — and just as visible, all in one view.

II · A Monday reading the reports

Four brands, one pass-rate rollup.

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 the authentication consolidates

Isolated where it counts. Pooled where it helps.

Each domain you bind is authenticated on its own terms — its own key, its own reputation, its own policy. Then every domain's DMARC reports flow into one place. You read the whole portfolio's authentication health from a single masthead instead of one DMARC tool per brand.

  • ·
    Per-domain DKIM, automatic at provisioning. Every bound domain gets its own RSA-2048 DKIM key the moment you bind it, plus its own SPF record pointing at Amazon SES and its own SES sending reputation. The agency's bounce problem can't bleed onto the parent. Replies go out signed by the right brand's key — reply-From is per domain.
  • ·
    One pass-rate rollup across the whole house. The Deliverability dashboard (at /deliverability) reads each domain's DMARC aggregate reports and rolls them into a single view: total domains, messages across the window, a portfolio pass rate, and a count of domains that need attention. The brand stuck at p=none can't hide.
  • ·
    Named failing sources, per brand. The dashboard tells a forger using your From line apart from a real sender you forgot to authorize — the first you reject, the second you fix. You see exactly who is spoofing any of your brands, by IP and hostname, without opening a single XML file.
  • ·
    Inbound anti-spoofing too. Mail arriving at any of your brands that fails authentication is filed to Spam on arrival, with every check explained in plain English. Missing or temperror auth fails open, so a forger is caught without a legitimate sender's transient hiccup landing in the wrong folder.

IV · What holds up under a portfolio audit

Honest about what a pass rate proves.

When you're accountable for the authentication posture of an entire portfolio, these are the load-bearing facts — including the one most tools won't say out loud.

Per-domain isolation
Each brand has its own DKIM key, SPF record, SES reputation, and DMARC policy. A subsidiary's deliverability problem is contained to that subsidiary — it cannot drag down the parent's pass rate.
One rollup, every domain
The /deliverability view aggregates per-domain seen/passed/failed counts and published policy into a single portfolio pass rate. Bind a new brand and it joins the rollup — no new console.
The ladder, walked safely
Folio marks a domain clean only when a full window proves real mail aligns, then guides it p=none → p=quarantine → p=reject. You tighten one brand at a time, never guessing.
Reputation is not identity
A high pass rate proves your mail is aligning — not that any given message is genuine. Folio shows no "trusted" badge that claims to guarantee authenticity. Authentication narrows who can forge you; it does not certify a sender.

V · Common questions

Questions readers ask.

How do I monitor DMARC across all my brands at once?

Publish a one-line rua= record on each domain pointing at Folio. The Deliverability dashboard (/deliverability) parses every provider's daily aggregate report for every bound domain and rolls them into one masthead: total domains, messages across the window, a portfolio pass rate, and a count of domains that need attention. You read the whole portfolio's authentication health in one place instead of logging into a separate DMARC tool per brand.

Should each brand under my holdco have its own DKIM?

Yes, and Folio does this automatically. Each domain gets its own RSA-2048 DKIM key the moment you bind it, plus its own SPF record and its own SES sending reputation. Per-brand keys are what keep authentication isolated — an auditor or a receiver can tell exactly which brand signed a message, and a key compromise or reputation problem on one brand never implicates the parent.

Can a subsidiary's email problems hurt the parent's reputation?

No. Sending reputation in Amazon SES is tracked per domain, so a bounce spike or a complaint problem on one subsidiary's list stays contained to that subsidiary. Its DMARC pass rate dips in the rollup as its own row — the parent's row and pass rate are unaffected. The portfolio view simply flags that one brand needs a look.

How do I see who's spoofing any of my brands?

The Deliverability dashboard names failing sources by IP and hostname for each domain, and distinguishes a forger using your From line from a real sender you forgot to authorize. The first you reject by tightening policy; the second you fix by correcting SPF. You get this for every bound brand without opening a single XML report.

How many domains can one Folio account authenticate?

It depends on the plan. Solo authenticates up to 3 domains at $2.99/mo billed annually ($35.88/yr), or $3.50/mo, with 1,000 sends/mo. Studio covers up to 10 domains at $12/mo billed annually ($144/yr), or $15/mo, with 6,000 sends/mo. Holding Co. authenticates unlimited domains and adds onboarding plus priority support — built for the operator holding the whole portfolio. Folio is single-operator: one reader, one bill, every brand.

How do I roll every brand up to p=reject safely?

One brand at a time, only once its mail is proven aligned. Folio marks a domain clean when a full window shows real mail passing and the only failures are forgers rather than your own misconfigured senders. Then it walks the policy up the ladder — p=none to collect data, p=quarantine, then p=reject — so you tighten without bouncing a legitimate newsletter. The rollup shows at a glance which brands are still at p=none and which are ready to move.

VI · Adjacent readers

Other shapes of the same problem.

VII · Sources & further reading

Where the claims come from.

Open the first letter

One operator. Every brand, accounted for.

Start free, no card — the first domain is free. Bind the parent entity, publish a one-line rua= record, and watch a brand's DMARC reports turn from unreadable XML into a pass rate. Add each brand beneath it and they all roll up into one view, so the whole house's spoofability is visible at a glance.

Start free — no cardRead the manual

Updated 22 June 2026 (2026-06-22)