Why are my proposals landing in clients' spam folders?

Almost always a sender-authentication failure. If your proposal isn't signed with a DKIM key for the sending domain (RFC 6376) and aligned to that domain's SPF record (RFC 7208), the receiving server can't verify it's really from you and files it to Junk. It's worse if you send from a domain whose reputation has been bruised by other, rougher mail. Folio signs each bound domain with its own key and aligns it to its own SPF, so the client's server can verify the proposal and deliver it to the inbox.

How do I authenticate my consulting domain?

Point the domain's MX record at Folio. From there it gets its own RSA-2048 DKIM key, its own SPF record, and its own SES sending reputation automatically — you publish the records Folio gives you and outbound mail is signed and aligned without further setup. You can confirm the result on the free /tools/domain-health check, and watch it hold over time in the Deliverability dashboard.

Can my product's marketing email hurt my consulting domain's deliverability?

Only if they share sending identity — the same SPF record, DKIM key, or sending IP. Marketing mail is bulk, colder, and complaint-prone, so it carries more reputation risk; when the consulting domain rides the same envelope, one bad blast can softfail your next invoice. Folio keeps them separate: each domain has its own DKIM key, SPF record, and SES reputation, so the product's volume has no path to the consulting domain's standing.

How do I stop someone spoofing my domain to my clients?

Publish DMARC and move your policy off p=none. A forger can put your From line on a fake invoice, but a receiver that honors your DMARC policy will quarantine or reject it once the policy is actually at p=quarantine or p=reject. Folio's Deliverability dashboard reads your aggregate (rua) reports, names the forging source, and tells you when a clean window means it's safe to tighten — so the spoofed invoice never reaches your client's inbox.

Do I need DMARC if I only send a few client emails?

Yes — low volume doesn't make you un-spoofable. DMARC's job isn't only deliverability; it's the feedback loop that shows you who is sending as your domain, including forgers, and the policy that lets receivers reject them. A consultant emailing a handful of clients is exactly the target a wire-fraud spoof goes after, because each email moves real money. The visibility matters even at one message a week.

When should I set p=reject?

When a clean window proves your legitimate mail aligns — effectively every reported message passing DMARC — and the only remaining failures are forgers, not your own misconfigured senders. Tighten too early and you risk bouncing your own proposals; that's why the Deliverability dashboard walks you up the ladder (p=none to collect data, then p=quarantine, then p=reject) and marks the domain ready only once it's actually safe. Reputation, to be clear, is not proof of identity — a high pass rate tells you alignment is holding, not that a given message is trustworthy.

Email authentication for consultants

The proposal has to
land — not bounce to spam.

Consultants run client work on one domain and a product on another. Each needs its own authenticated identity — Folio gives every bound domain its own RSA-2048 DKIM key, SPF record, and SES sending reputation, so a product marketing blast can't drag the consulting domain into spam. Per-domain DMARC visibility proves the domain is locked against anyone spoofing your firm to your own clients.

You bill on one domain and run a product on another. A statement of work to a client's procurement team and a launch blast to a product list are not the same kind of mail, and the receiving servers know it. When the two share sending reputation, the aggressive one drags down the careful one — and a signed proposal ends up in Junk next to the casino offers.

Folio gives each bound domain its own DKIM key, its own SPF record, and its own SES sending reputation. The consulting domain authenticates as itself; the product domain authenticates as itself. Neither can spend the other's credibility.

Updated 22 June 2026 (2026-06-22)

Start free — no card See the price

Android app live on Google Play

I · The problem with two domains, one reputation

A proposal in Junk reads as amateur hour.

A consultant's deliverability is part of the deliverable. The proposal, the invoice, the change order, the monthly statement — each one has to arrive in the client's primary inbox to do its job. Landing in spam doesn't just delay a deal; it quietly says that the firm sending it can't run its own email. Procurement notices.

The hidden risk is the product side. Marketing mail is sent in bulk, to colder lists, with more complaints and bounces — inherently rougher on reputation. If the consulting domain and the product domain share an SPF record, a DKIM key, or a sending IP, one over-eager newsletter can sour the reputation that a careful proposal depends on. The blast on the product domain becomes the reason the invoice on the consulting domain gets filtered.

And there's a third party in the room: whoever decides to spoof you. Your From line on a fake invoice, mailed to your own client, is a fraud you find out about only when the client calls — unless the domain is locked and you're watching the reports.

The consulting domain's reputation is an asset you've spent years building. The product's marketing mail should not be allowed to spend it.

II · The week deliverability went wrong

Three letters. Two domains. One spoofer.

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?

THU 18 JUN · 2:14 PM·The Correspondence4 letters

2:09 PM
Mailer-Daemon
postmaster@northstar-bio.com
via consulting
Delivered to Spam — "SOW v4 + June invoice"
Your message was placed in the recipient's Spam folder. Reason: failed sender authentication (SPF softfail). The proposal you spent the morning on is sitting where nobody will look…
11:52 AM
K. Ramirez · Client
cigan@advisory.partners
via consulting
Is this invoice from you? Looks off.
Got an invoice from your firm asking us to wire to a new account number. The wording is slightly wrong and the From address is yours but the reply-to isn't. Wanted to check before paying…
9:30 AM
Folio · Deliverability
reports@advisory.partners
via consulting
DMARC report — 1 forging source, named
Aggregate reports for advisory.partners: 99% pass. One source failing as you — 203.0.113.51, not one of your senders. A forger using your From line. Your policy is still p=none…
yesterday
Stripe
billing@clipship.app
via product
Product newsletter sent — 4,200 recipients
Your June release note went out to the product list. 38 bounces, 2 complaints. Sent from the product domain's own key — your consulting reputation was never touched…

III · How the deliverability holds

Each domain authenticates as itself.

Point each domain's MX at Folio and it gets its own authenticated identity. The consulting domain signs with the consulting domain's RSA-2048 DKIM key, aligns to its own SPF record, and builds its own SES sending reputation. The product domain does the same, separately. The proposal lands because the client's server can verify it's genuinely from your firm — and the product's marketing volume has no path to drag that down.

·
Per-domain DKIM, generated automatically. Each bound domain gets its own RSA-2048 DKIM key. The consulting domain and the product domain sign with different keys, so their reputations are decoupled at the protocol layer — RFC 6376, not a shared secret.
·
Per-domain SPF and SES reputation. Each domain has its own approved-sender record and its own sending reputation with Amazon SES. A bounce-heavy product blast can't softfail your next proposal, because they don't share an envelope identity.
·
Reply-From that stays aligned. A letter that arrives at the consulting address replies from the consulting address, signed by the consulting key. The From you authenticated is the From the client's server checks — no misalignment that lands you in Junk.
·
DMARC visibility, per domain. Aggregate (rua) reports for each domain are read for you, so you can see — and prove to a client — that the domain is locked against anyone impersonating your firm to your own clients.

IV · What keeps the proposal out of spam

Authentication you can show a client.

Deliverability isn't a setting you flip once. It's per-domain authentication that holds under load and a feedback loop that tells you when something's wrong. These are the pieces Folio handles.

Per-domain DKIM + SPF: Each bound domain signs with its own RSA-2048 DKIM key (RFC 6376) and aligns to its own SPF record (RFC 7208). A client checking headers on your proposal sees a properly authenticated message from your firm — never a shared @gmail.com sender.
Inbound anti-spoofing: Mail arriving at your domain that fails authentication is filed to Spam on arrival, with every check explained in plain language. Missing or temporarily-broken auth fails open, so a real client whose server is having a bad day never gets silently dropped.
DMARC dashboard, per domain: At /deliverability: a pass-rate rollup, per-domain seen/passed/failed counts, your published policy, and named failing sources — a forger using your From line reads differently from a real sender you forgot to authorize.
The policy ladder, guided: The dashboard walks you from p=none to p=quarantine to p=reject, marking the domain ready only once a clean window proves your real mail aligns — so you tighten without bouncing your own invoices.

V · Common questions

Questions readers ask.

Why are my proposals landing in clients' spam folders?: Almost always a sender-authentication failure. If your proposal isn't signed with a DKIM key for the sending domain (RFC 6376) and aligned to that domain's SPF record (RFC 7208), the receiving server can't verify it's really from you and files it to Junk. It's worse if you send from a domain whose reputation has been bruised by other, rougher mail. Folio signs each bound domain with its own key and aligns it to its own SPF, so the client's server can verify the proposal and deliver it to the inbox.
How do I authenticate my consulting domain?: Point the domain's MX record at Folio. From there it gets its own RSA-2048 DKIM key, its own SPF record, and its own SES sending reputation automatically — you publish the records Folio gives you and outbound mail is signed and aligned without further setup. You can confirm the result on the free /tools/domain-health check, and watch it hold over time in the Deliverability dashboard.
Can my product's marketing email hurt my consulting domain's deliverability?: Only if they share sending identity — the same SPF record, DKIM key, or sending IP. Marketing mail is bulk, colder, and complaint-prone, so it carries more reputation risk; when the consulting domain rides the same envelope, one bad blast can softfail your next invoice. Folio keeps them separate: each domain has its own DKIM key, SPF record, and SES reputation, so the product's volume has no path to the consulting domain's standing.
How do I stop someone spoofing my domain to my clients?: Publish DMARC and move your policy off p=none. A forger can put your From line on a fake invoice, but a receiver that honors your DMARC policy will quarantine or reject it once the policy is actually at p=quarantine or p=reject. Folio's Deliverability dashboard reads your aggregate (rua) reports, names the forging source, and tells you when a clean window means it's safe to tighten — so the spoofed invoice never reaches your client's inbox.
Do I need DMARC if I only send a few client emails?: Yes — low volume doesn't make you un-spoofable. DMARC's job isn't only deliverability; it's the feedback loop that shows you who is sending as your domain, including forgers, and the policy that lets receivers reject them. A consultant emailing a handful of clients is exactly the target a wire-fraud spoof goes after, because each email moves real money. The visibility matters even at one message a week.
When should I set p=reject?: When a clean window proves your legitimate mail aligns — effectively every reported message passing DMARC — and the only remaining failures are forgers, not your own misconfigured senders. Tighten too early and you risk bouncing your own proposals; that's why the Deliverability dashboard walks you up the ladder (p=none to collect data, then p=quarantine, then p=reject) and marks the domain ready only once it's actually safe. Reputation, to be clear, is not proof of identity — a high pass rate tells you alignment is holding, not that a given message is trustworthy.

VI · Adjacent readers

Where the claims come from.

Open the first letter

Make the proposal land — and lock the domain.

Start free, no card. Bind your consulting domain, point the MX, and send one proposal. Check the headers: signed by your own key, aligned to your own SPF, authenticated as your firm. Then publish the rua line and watch the reports tell you the one thing that matters — can anyone still spoof you to your clients?

Start free — no card Read the manual