Email authentication for Shopify operators

Each store authenticates on its own.
One bad batch can't poison the rest.

Email authentication for Shopify operators means publishing SPF, DKIM, and DMARC on each store domain — now required by Google and Yahoo for bulk senders — so every store authenticates independently and one store's bad batch can't poison another's reputation. Folio gives each bound store its own RSA-2048 DKIM key and SES sending reputation, then reads every store's DMARC reports in one dashboard.

Every Shopify store you run sends two streams of mail: transactional confirmations from Shopify, and marketing flows from Klaviyo or Mailchimp — all of it leaving on that store's own domain. As of February 2024, Google and Yahoo require bulk senders to publish SPF, DKIM, and DMARC or watch that mail land in spam, or bounce outright.

Folio binds each store domain as its own authenticated identity: its own RSA-2048 DKIM key, its own SPF record, its own SES sending reputation. A bad send on the candle store can't drag the kitchenware store into the spam folder — and a Deliverability dashboard reads each store's DMARC reports so you can see who's still able to forge you.

Updated 22 June 2026 (2026-06-22)

Start free — no cardSee the price

Android app live on Google Play

I · The problem with one shared sending reputation

Five stores, one reputation to lose.

When every store forwards to one personal Gmail and replies go out from that same @gmail.com, all five storefronts share a single DKIM key, a single SPF record, and a single bounce pool. Reputation is pooled. A clumsy Klaviyo blast on the candle store — too many cold addresses, a spike of spam complaints — degrades the very reputation your kitchenware order confirmations depend on. The stores cannot fail independently because, to a receiving server, they are not independent.

The bulk-sender rules made this sharper. Since February 2024, Google and Yahoo require anyone sending in volume to publish SPF, DKIM, and a DMARC record, keep spam complaints under 0.3%, and pass authentication that aligns with the From domain. Mail that doesn't is filed to spam or rejected at the door. Each store has to clear that bar on its own From domain — a shared aggregate signature won't align with five different storefronts.

The cottage workaround — Gmail 'Send mail as' for each store, or one Google Workspace per store at $7/mo — gives you addresses but not separation. Five Workspaces is $420 a year and still leaves you squinting at five admin consoles trying to work out which store's DMARC policy is stuck at p=none. Authentication is per domain; the tooling should be too.

Shopify gave each store its own domain. Google now demands each domain authenticate on its own. A shared reputation does the opposite — it ties every store's deliverability to the worst-behaving send on any of them.

II · A morning of authentication signals

What the reports are trying to tell 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 per-store authentication should work

Each store, its own cryptographic identity.

Bind each Shopify store's custom domain into Folio and point its MX at us. Each domain provisions with its own RSA-2048 DKIM key, its own SPF record, and its own SES sending reputation — so authentication for the candle store is mathematically separate from the kitchenware store. Mail that arrives failing authentication is filed to Spam on arrival, with every check explained in plain English.

  • ·
    Per-store DKIM key. Each bound store domain gets its own RSA-2048 DKIM key at provisioning. Order confirmations and reply mail sign with that store's key — never a shared aggregate signature that won't align with five different From domains.
  • ·
    Reputation that can't bleed across stores. Each store domain has its own SES sending reputation pool. A spike of spam complaints on one store's marketing flow cannot drag another store's transactional mail into the spam folder.
  • ·
    Inbound spoof defence, explained. Mail that fails authentication is filed to Spam on arrival, with every check spelled out in plain English. Missing or temporarily-unreachable auth fails open, so a real sender with a flaky DNS lookup isn't punished.
  • ·
    Flat price, every store. Studio is $12/mo billed annually ($144/yr) for up to 10 bound domains and 6,000 sends a month; Holding Co. lifts the cap to unlimited. Adding the next storefront's authentication is $0 — not $7/mo forever.

IV · Reading the DMARC reports per store

The reports, read for every store.

Every mailbox provider already mails back a daily DMARC aggregate (rua) report saying who sent as your store and whether it passed. The catch is it arrives as raw XML, one file per provider, per store, every day. The Deliverability dashboard at /deliverability reads them all and rolls them into one view.

Portfolio rollup
One masthead reads every bound store's DMARC reports: total domains, messages across the window, a volume-weighted portfolio pass rate, and a count of stores that need attention. Six brands, one pass-rate column — not six DMARC tools and six logins.
Per-store breakdown
Each store shows messages seen, passed, and failed, plus its published policy. The dashboard distinguishes a forger using your From line from a real sender — your Klaviyo or Mailchimp IP — you simply forgot to authorize. One you reject; the other you fix SPF for.
The p=reject ladder
A store is marked clean only once a full window proves its real mail aligns. Then the dashboard walks the policy up the ladder — p=none to collect data, p=quarantine, then p=reject — so you tighten only when legitimate sends won't get caught.
Honest about reputation
A good pass rate proves a store's mail is authenticating — it is not proof any single message is authentic. Authentication tells a receiver the mail wasn't forged in transit; it never promises the human behind it is who they claim. The dashboard never sells you a 'trusted' badge that pretends otherwise.

V · Common questions

Questions readers ask.

Do I need DMARC for my Shopify store?

Yes — if your store sends in volume. Since February 2024, Google and Yahoo require bulk senders to publish a DMARC record (alongside SPF and DKIM) or have their mail filtered to spam or rejected. Even below the bulk threshold, a published DMARC policy is what lets receivers reject mail that forges your store's From address. Folio provisions each bound store domain with DMARC reporting and reads the resulting reports for you at /deliverability.

Why is my Shopify email going to spam?

Almost always an authentication gap. The most common cause is a marketing platform — Klaviyo, Mailchimp — sending on an IP that isn't listed in your store domain's SPF record, so the mail fails alignment and gets filed to spam. The second is a DMARC policy stuck at p=none while a forger spoofs your address and erodes the domain's reputation. The Deliverability dashboard names the exact failing IPs so you can tell which it is.

How do I authenticate Klaviyo or Mailchimp for my store domain?

Each platform asks you to add its sending domain to your store domain's DNS — a CNAME for its DKIM key and an include in your SPF record — so its mail aligns with your From address. Once that's published, Klaviyo or Mailchimp mail passes DMARC as your store. Folio's per-store SPF and the DMARC reports it reads will show you exactly when that sender starts passing — and flag it as 'a real sender you forgot to authorize' rather than a forger if it isn't aligned yet.

Will one store's bad sending hurt my other stores?

Not on Folio. Each bound store domain gets its own RSA-2048 DKIM key and its own SES sending reputation pool, so a spike of spam complaints on one store's marketing flow can't drag another store's transactional mail into the spam folder. The danger only exists when every store shares one reputation — one Gmail, one DKIM key, one bounce pool — which is exactly the setup per-store authentication is meant to break.

What are the Google and Yahoo bulk sender rules?

As of February 2024, senders mailing roughly 5,000+ messages a day to Gmail or Yahoo must: authenticate with SPF and DKIM, publish a DMARC record (at least p=none with alignment), keep spam complaint rates below 0.3%, and offer one-click unsubscribe on marketing mail. Mail that doesn't comply is filed to spam or rejected. Each Shopify store sends from its own domain, so each store must clear the bar on its own From domain — a shared signature won't align across five storefronts.

How do I move my store domain to p=reject safely?

Tighten the policy only once a full reporting window proves your real mail aligns — every legitimate send (Shopify, Klaviyo, Mailchimp) passing DMARC, and the only failures being outside forgers rather than your own misconfigured senders. The Deliverability dashboard watches that window, marks the store clean when it's ready, and walks the policy up the ladder — p=none to p=quarantine to p=reject — so the only mail you start rejecting is the forgeries, never your own order confirmations.

VI · Adjacent readers

Other shapes of the same problem.

VII · Sources & further reading

Where the claims come from.

Open the first letter

Bind one store. Watch it authenticate on its own.

Start free, no card. Bind your highest-volume store's custom domain first, publish its DKIM and a one-line rua= record, and watch the DMARC reports you were never reading turn into a single answer: can this store still be spoofed? Add the other stores once the model proves out. A hundred sends and the first domain are free.

Start free — no cardRead the manual

Updated 22 June 2026 (2026-06-22)