DMARC & SPF for multiple LLCs

One LLC's spam problem should never land on another's invoices.

For multiple LLCs, give each entity its own DMARC record, SPF record, and DKIM key on its own domain — never a shared sending posture. That keeps every LLC's reputation isolated (one entity's spam trouble can't sink another's mail) and makes each entity's authentication independently auditable. Folio provisions a per-domain RSA-2048 DKIM key, per-entity SPF, isolated SES reputation, and reads each domain's DMARC reports separately.

Each LLC is its own legal entity. Separate EIN, separate books, separate bank account, separate line on the IRS's ledger. Its email should be just as separate — its own DKIM key, its own SPF record, its own DMARC policy, its own sending reputation — so a blocklisting on one entity can't drag down the deliverability of the next.

Folio is bring-your-own-domain email for one operator running many identities. Point each LLC's domain's MX at Folio and every entity gets its own RSA-2048 DKIM key at provisioning, its own per-domain SPF, its own isolated Amazon SES sending reputation, and a Deliverability dashboard that reads each domain's DMARC aggregate reports independently.

Updated 22 June 2026 (2026-06-22)

Start free — no cardSee the price

Android app live on Google Play

I · Why one shared sending posture is a liability

Pool the reputation, and one bad list poisons all of them.

The convenient setup is to route every LLC through one sending identity — one SPF record, one DKIM key, one envelope domain — and rewrite the From line per brand. It works until it doesn't. The day the rental LLC's tenant-notice blast trips a spam trap, the reputation hit lands on the same IP and the same signing key that your consulting LLC's invoices ride on. Now the bakery's order confirmations are in spam too, and you can't tell which entity caused it.

There is no corporate veil at the protocol level when the protocol can't tell the entities apart. A receiver evaluating a message sees one DKIM domain, one SPF result, one reputation — not three businesses that happen to share an operator. DMARC alignment, which is supposed to bind a message to the entity that owns it, collapses into a single bucket.

What you want is the opposite: each LLC cryptographically and reputationally on its own, so a problem stays contained to the entity that caused it, and an auditor tracing a disputed invoice can see exactly which entity signed it.

An auditor should be able to verify each entity's email authentication on its own — not untangle three LLCs sharing one signature.

II · A week of reports, one reader

Three DMARC postures, read for you.

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 each entity stays isolated

Per-LLC authentication, one dashboard.

Every LLC's domain becomes a first-class sender with its own cryptography and its own reputation. Bind the domain, point its MX at Folio, and the per-entity isolation is automatic — you only sit in one reading surface to watch all of it.

  • ·
    Per-domain DKIM, generated at bind. Each LLC's domain gets its own RSA-2048 DKIM key at provisioning. The DKIM-Signature on every outbound message names that entity's domain — never an aggregate. An auditor can verify which LLC signed a given email cryptographically.
  • ·
    Per-entity SPF and isolated reputation. Each domain gets its own SPF record and its own Amazon SES sending reputation. A blocklisting or spam-trap hit on one LLC's list cannot leak onto another LLC's deliverability — the reputations never touch.
  • ·
    Per-domain DMARC, read for you. The Deliverability dashboard parses each domain's DMARC aggregate (rua) reports separately: per-entity seen, passed, and failed counts, the published policy, and the named sources failing as that entity — a forger versus a real sender you forgot to authorize.
  • ·
    Inbound anti-spoofing, per identity. Mail arriving for any of your entities that fails authentication is filed to Spam on arrival, with every check explained in plain English. Missing or temperror auth fails open, so legitimate mail from a misconfigured sender is never silently dropped.

IV · What your CPA and auditor will check

Each entity's auth, independently verifiable.

When an auditor or CPA reviews the email trail for one LLC, they should be able to evaluate that entity in isolation — its keys, its policy, its reputation — without the other entities clouding the picture. These are the answers.

Per-entity DKIM key
Each LLC's domain has its own RSA-2048 DKIM key. A disputed message can be traced to the exact entity that signed it via the DKIM-Signature d= domain — never a shared identity.
Per-domain DMARC record
Each domain publishes its own DMARC policy and reports to its own rua= address. One entity's posture and pass rate are auditable without reference to any other LLC.
Isolated SES reputation
Sending reputation is per domain. An auditor checking one entity's deliverability sees only that entity's history — a problem on another LLC never enters the record.
Reputation is not identity
A high pass rate or a 'clean' status proves alignment, not authorship. Folio never claims a trusted badge guarantees a message is genuine — only that it authenticated against the entity's published records.

V · Common questions

Questions readers ask.

Do I need a separate DMARC record for each LLC?

Yes. DMARC is published per domain, at _dmarc., so each LLC's domain needs its own record with its own policy and its own rua= reporting address. Sharing one record across entities is not possible — each domain is evaluated on its own. Folio gives each bound domain its own DMARC posture and reads each one's aggregate reports independently, so you can run cobalt-properties-llc.com at p=reject while northstar-consulting-llc.com is still gathering data at p=none.

Can one LLC's spam complaints hurt another LLC's email?

Only if they share a sending reputation. When two LLCs send through the same IP, the same DKIM key, and the same envelope domain, a blocklisting or spam-trap hit on one drags down the other — that is the exact failure to avoid. Folio gives each domain its own Amazon SES sending reputation, its own DKIM key, and its own SPF, so the reputations never touch. A problem on one entity stays contained to that entity.

How do I set up SPF for multiple business domains?

Each domain needs its own SPF TXT record listing the servers authorized to send for that domain — you cannot point several domains at one shared record and expect alignment. With Folio, each bound domain gets a per-domain SPF record covering its own sending, so every LLC authorizes only its own mail. Our free SPF record generator at /tools/spf-record-generator builds a correct record per domain, one entity at a time.

How do I prove each entity's email is authenticated for an audit?

Three artifacts, all per-entity: the domain's published DMARC and SPF records (anyone can query them), the DKIM-Signature header on the entity's outbound mail (its d= names that LLC's domain explicitly), and the per-domain DMARC aggregate reports showing pass rates over time. Folio surfaces all three per domain in the Deliverability dashboard, so an auditor can verify one LLC's authentication without untangling it from the others.

Why is my LLC's invoice email going to spam?

Usually one of two things, and the DMARC reports tell them apart. Either a real sender you forgot to authorize is failing SPF or DKIM alignment for that domain — fixable by adding it to SPF — or a forger is using your From line and your policy is too weak to stop it. Folio's dashboard names the failing source and labels which kind it is, so you fix the right problem instead of guessing. Folio's inbound side also files mail that fails authentication to Spam on arrival, with every check explained in plain English.

When is it safe to set p=reject on each domain?

Per domain, when that entity has passed DMARC on effectively every reported message across a full window and the only remaining failures are forgers — not your own misconfigured senders. Folio walks each domain up the ladder independently: p=none to collect data, then p=quarantine, then p=reject, and marks a domain clean only once a clean window proves its real mail aligns. One LLC reaching p=reject says nothing about the readiness of the next; each is evaluated on its own evidence.

VI · Adjacent readers

Other shapes of the same problem.

VII · Sources & further reading

Where the claims come from.

Open the first letter

Three LLCs. Three postures. One reader.

Start free — no card. Bind your first LLC's domain (the first domain is free), point its MX at Folio, publish a one-line rua= record, and watch its DMARC reports turn into a single answer: can the world still spoof this entity? Add the other LLCs once the model proves out.

Start free — no cardRead the manual

Updated 22 June 2026 (2026-06-22)