Email authentication · For the side-hustle stack
Four hustles. Four domains.
Every one has to authenticate.
Each side hustle on its own domain — the freelance work, the SaaS, the newsletter you send through Mailchimp or Beehiiv — must be authenticated per domain or it lands in spam, and Google and Yahoo now require SPF, DKIM, and DMARC from senders. Authorise each third-party service in the right domain's SPF, publish per-domain DKIM, and keep a DMARC policy watching — so every hustle's deliverability stays independent and nobody can spoof your newsletter to its subscribers.
The freelance domain replies straight from Folio, so it's signed and aligned. But the newsletter goes out through Beehiiv, the SaaS sends receipts through Stripe, and the launch list blasts through Mailchimp — each from a different domain, each a separate sender Gmail and Yahoo will now judge on its own.
If a hustle's third-party sender isn't authorised in that domain's SPF, with per-domain DKIM and a DMARC policy watching, it lands in spam — and one misconfigured list can't drag the others down, because each domain carries its own record set.
Folio binds each domain as a first-class identity, signs every reply with a per-domain DKIM key, and reads the DMARC reports back so you can see which hustle is authenticated and who's forging it.
Updated 22 June 2026 (2026-06-22)
Android app live on Google Play
I · Why the newsletter lands in spam
Each hustle is a separate sender in the eyes of Gmail.
Side-hustle email rarely all flows through one place. The freelance work replies from a real inbox; the newsletter is a Beehiiv or Mailchimp blast; the SaaS fires transactional receipts through Stripe or Postmark. Every one of those is a different service sending under a different domain — and a mailbox provider authenticates each domain on its own, not your reputation as a person.
As of February 2024, Google and Yahoo require bulk senders to publish SPF, DKIM, and a DMARC record, and to keep spam complaints low. A newsletter that authenticates today is fine; a newsletter you moved to a new domain last week, whose SPF still doesn't list the sending service, starts landing in Promotions, then Spam, then nowhere.
The trap is treating four domains like one setup. The freelance domain can be immaculate while the newsletter quietly fails DKIM alignment because you forgot to add the CNAME records the sending tool asked for. Deliverability is per-domain, per-sender — and so is the fix.
Gmail doesn't grade you. It grades each domain. The newsletter you forgot to authorise fails on its own — and takes your open rate down with it.
II · A week across the stack's deliverability
Three reports. One is bad news.
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?
8:02 AM
Beehiiv
noreply@longhand-letters.com
via longhand
Your Tuesday issue — 98.4% delivered
Issue No. 47 went to 3,212 subscribers. 98.4% delivered, 0.02% spam complaints, SPF and DKIM aligned on this domain. Inbox placement at Gmail held steady this week…
7:41 AM
Mailchimp
alerts@field-supply.co
via field-supply
Authentication issue — emails may be filtered
We detected that field-supply.co isn't authorising Mailchimp in its SPF record. Recent sends failed alignment at some providers and may be filtered to spam. Add our include and verify your CNAMEs…
yesterday
Subscriber
hello@longhand-letters.com
via longhand
Is this 'renew now' email really from you?
Got an email from 'Longhand Billing' asking me to renew a subscription I never paid for, with a link that looks off. The From address says longhand-letters.com but something feels wrong. Did you send this…
Jun 16
Stripe
receipts@inkjar.app
via inkjar
Receipts now signing as inkjar.app
Your custom sending domain is verified. Receipts now send from receipts@inkjar.app with DKIM signed by your domain and SPF aligned, instead of Stripe's shared domain. Customers see your name, not ours…
III · How each hustle gets authenticated
Every domain, its own authentication.
Bind each domain to Folio and point its MX at us, and that domain becomes a fully signed identity: per-domain DKIM, per-domain SPF, replies that align automatically. For the mail that leaves through Mailchimp, Beehiiv, or Stripe, you authorise that service in the right domain's SPF and publish its DKIM — and Folio's DMARC reporting tells you whether it worked.
- ·Per-domain DKIM, never a shared key. Every domain you bind gets its own RSA-2048 DKIM key and its own SPF posture, signed through Amazon SES. The newsletter domain and the SaaS domain authenticate independently — one failing alignment can't taint the other's reputation.
- ·Authorise each sender in the right domain. Beehiiv sends the newsletter, Stripe sends receipts, Mailchimp blasts the launch list. Add each service's include to that domain's SPF and publish the DKIM records it gives you. The SPF Record Builder helps you merge a new sender in without breaking the existing record or blowing the ten-lookup limit.
- ·DMARC reporting that names the failures. The Deliverability dashboard reads each domain's DMARC aggregate (rua) reports and tells two stories apart: a forger putting your From line on phishing mail, versus a real sender — a newsletter tool you forgot to authorise — that just needs adding to SPF. You fix one and reject the other.
- ·Flat price — the next domain is free to authenticate. Solo is $2.99/mo billed annually ($35.88/yr) for up to 3 domains and 1,000 sends a month; Studio takes you to 10 domains and 6,000 sends; Holding Co. is unlimited. Within your plan's cap, authenticating the next hustle's domain costs nothing.
IV · What the dashboard actually shows
Authentication you can see, per hustle.
Reputation is never proof of identity — a high pass rate doesn't certify a sender is who it claims, and no badge can. What the dashboard gives you is the evidence: which domain passes, which sender is failing, and when a clean window means you can finally tighten the policy.
- Per-domain pass-rate rollup
- Each bound domain shows its own seen / passed / failed counts and its published policy, so you can tell at a glance that the newsletter is at 99% while the freelance domain sits clean at 100%.
- Named failing sources
- A failing source is labelled as a forger using your From line, or as an unauthorised real sender — e.g. a newsletter tool you forgot to add to SPF. One you authorise; the other you let DMARC reject.
- Inbound anti-spoofing too
- Mail arriving at your hustles that fails authentication is filed to Spam on arrival, with every check explained plainly. Missing or temperror auth fails open, so a one-off DNS blip never buries a real letter.
- The policy ladder, walked safely
- Folio guides each domain from p=none to p=quarantine to p=reject — but only once a clean window proves your real mail aligns, so tightening the newsletter's policy never bounces the newsletter.
V · Common questions
Questions readers ask.
Why is my newsletter going to spam?
- Almost always because the domain it sends from isn't authenticating the sending tool. If Mailchimp or Beehiiv mails as you but your domain's SPF doesn't list their servers and their DKIM records aren't published, the mail fails alignment — and Gmail and Yahoo, which since February 2024 require SPF, DKIM, and DMARC from bulk senders, file it to spam. Add the tool to that domain's SPF, publish its DKIM CNAMEs, and verify it in Folio's Deliverability dashboard.
How do I authenticate Mailchimp or Beehiiv for my domain?
- Each service gives you DNS records to publish on the specific domain it sends under: an SPF include (or a confirmation your existing SPF covers them) and one or more DKIM CNAME records. Add the include to that domain's TXT SPF record, publish the CNAMEs, and let the tool verify. Folio's per-domain DKIM signs the mail you reply with directly; the third-party tool signs the mail it sends — both must align on the same From domain.
Do I need DMARC for a small side project?
- If it sends to anyone at Gmail or Yahoo in any volume, yes. DMARC is now table stakes for senders, and a side project is exactly the kind of domain a forger likes — small, unmonitored, trusted by a niche audience. Start at p=none to collect the aggregate reports, watch what's actually sending as you, and you'll see within days whether you're being spoofed. There's no minimum size below which spoofing stops mattering.
Can one hustle's email hurt another's deliverability?
- Not directly, and that's the point of keeping them on separate domains with separate authentication. Each domain carries its own DKIM key, its own SPF, and its own sending reputation in SES, so a misconfigured newsletter list failing alignment can't drag down the freelance domain's inbox placement. The risk is only shared if you route multiple hustles through one unauthenticated domain — which is exactly what you avoid by authenticating each one.
What are the new Gmail and Yahoo sender rules?
- Since February 2024, both require senders — especially bulk senders above roughly 5,000 messages a day — to publish SPF and DKIM, have a DMARC record (at least p=none), keep spam complaint rates low, and offer one-click unsubscribe on marketing mail. The practical upshot: every domain you send a newsletter or transactional mail from needs all three records aligned, or delivery degrades. Folio's dashboard verifies each domain meets the bar.
How do I add a sending service to SPF without breaking it?
- Merge the new service's include into your existing single SPF TXT record — never publish a second SPF record, which invalidates both — and watch the DNS-lookup count, since SPF permits at most ten and each include consumes some. Folio's SPF Record Builder takes your current record plus the new sender and produces one valid, flattened-where-needed record that stays under the limit. Then confirm alignment in the Deliverability dashboard.
VI · Adjacent readers
Other shapes of the same problem.
VII · Sources & further reading
Where the claims come from.
- RFC 7489 — DMARCthe policy ladder (p=none → quarantine → reject) and aggregate (rua) reporting per domain
- RFC 7208 — SPFapproved-sender records, the single-record rule, and the ten-lookup limit when adding a service
- RFC 6376 — DKIM Signaturesper-domain cryptographic signing that each hustle's sender must align to its From domain
- Google — Email sender guidelinesthe 2024 requirement that senders publish SPF, DKIM, and DMARC or face filtering
Open the first letter
Stop letting the newsletter fall into spam.
Start free, no card — the first 100 sends and the first domain are free. Bind your busiest hustle's domain, point its MX at Folio, authorise its sending service in SPF, and watch the DMARC reports confirm it's landing. Add the rest as each one starts to matter. Solo is $2.99/mo billed annually ($35.88/yr), or $3.50/mo, for up to 3 domains.
Updated 22 June 2026 (2026-06-22)