Shopify Email Automation: A Practical Setup Guide

Shopify email automation, in the strict sense, means building the triggered flow inside Shopify’s own tools — its native email app and, where email’s own trigger list falls short, Shopify Flow — instead of a dedicated email service provider. Two of the most common native automations, welcome series and abandoned checkout recovery, are covered elsewhere on this blog; this guide covers the rest of the native toolkit: the setup mechanics every automation shares, two automations most stores never get around to building, and the point where native tooling stops being enough.

What is Shopify email automation, and which native tools build it?

Shopify email automation is a triggered email sequence — order placed, checkout started, customer created — built and sent from inside Shopify’s own admin, rather than from a separate email platform. Two native tools do the work. Shopify’s own email app builds and sends the emails themselves, using a trigger, a send-after delay and an audience segment. Shopify Flow builds the wider workflow logic — tagging, notifying, routing — around store events that email’s own trigger list doesn’t cover.

The exact names of both tools, and which triggers or actions each exposes, have changed as Shopify has updated the platform. Rather than take this article’s names as current, open your own admin — under Settings and under Marketing or Apps — and confirm what’s there today before building around a name or menu path from any article, including this one.

What do you need before you build a native automation?

Three things, decided before you open the automation builder.

A verified sending domain. Every native automation sends as the account, and an unauthenticated domain hurts deliverability for every automation you build afterward, not just the first one. Domain authentication is the step most teams skip, covered in full under “What is the step most teams get wrong?”

A defined audience. Know which customers should receive the automation before naming a trigger — “customers who’ve bought once but not twice” is a segment, not a trigger, and Shopify’s automations need both.

A decision about overlap. If you already run a Shopify Flow workflow or another automation touching the same customers — the kind covered in our guide to Shopify Plus flows — decide now whether this new automation’s audience should exclude anyone already caught by that workflow, rather than discovering the overlap after two emails land in one inbox on the same day.

Authenticate your sending domain before you build anything

Under your store’s domain and notification settings, add and verify your sending domain so automated email goes out from your own domain, with the DNS authentication records that domain provides, instead of a shared address. This is a one-time setup step, not a per-automation one — every automation you build afterward inherits it.

An unauthenticated sending domain doesn’t stop automations from sending — it changes how receiving mail servers treat what you send. Without domain authentication, a receiving server has less basis to confirm the email actually came from you, which is exactly the kind of signal spam filtering weighs. A store that builds five automations on an unauthenticated domain has built five automations with a deliverability handicap, not one.

Choose the automation trigger

Open the automation builder and pick the single event that starts the flow. Shopify’s current trigger list generally covers points across the customer and order lifecycle — an order placed, a checkout started, a customer account created, among others — and the exact list is worth checking directly in the builder rather than assumed from memory, since Shopify adds and restructures triggers over time.

Pick the trigger that matches the point in the journey you actually mean, not the closest available option. A post-purchase automation triggered on “order placed” fires before fulfilment; one meant to follow delivery needs a later trigger or a delay long enough to approximate it, since native tooling doesn’t always expose a delivery-confirmation trigger directly.

Set the send-after delay

Every native automation has a delay setting — how long after the trigger the email actually sends. The builder’s own current options are the source of truth here; treat any specific delay value you see in an article, including this one, as illustrative rather than a current setting you should copy.

The judgement that matters more than the exact number: the delay has to be long enough that the triggering action has actually completed. A review-request automation sent immediately after “order placed” asks for a review of a product the customer hasn’t received yet. A win-back automation with too short a gap looks less like a nudge and more like a store that doesn’t track its own customer’s purchase history.

Define the audience with a segment

Shopify’s segment tooling lets you filter customers by fields such as order count, total spent, tags, and marketing consent, combined with AND/OR logic through Shopify’s own segment query syntax for anything beyond a single condition. A guided picker handles simple filters without writing the syntax directly; combining several conditions — “has ordered exactly once AND is subscribed to marketing AND was created more than a set number of days ago” — is where the query syntax becomes worth learning.

Segments aren’t static once saved. A customer moves in and out of a segment as their order history, tags or consent status change, and an automation triggers off that membership — which means the segment definition, not just the trigger, decides who actually receives the email. Re-check the segment after any change to how you tag or categorise customers elsewhere in the store; a tag renamed for an unrelated reason can silently empty an automation’s audience.

Turn the automation on and confirm it’s live

Publish the automation, then create or simulate a qualifying event — a real test order, a test customer matching the segment — and confirm the email actually arrives, rather than trusting that a saved, published automation is a working one. This matters more than it sounds: an automation can be published with a segment that matches zero customers, a trigger pointed at the wrong event, or a template referencing a discount code that was deleted after the automation was built, and none of those failures show up as an error in the builder.

How do you build a post-purchase review-request automation?

Trigger: order placed or, if your account’s trigger list supports it, a fulfilment or delivery event — pick whichever puts the send after the customer has actually had the product in hand. Delay: long enough for typical delivery and a few days of use; the right gap depends on your shipping times and product category, and is worth setting deliberately rather than accepting a default. Audience: customers who’ve completed an order and are subscribed to marketing, excluding customers already flagged for a return or a support ticket on that order, if your data lets you filter on that.

The setting worth double-checking here is the exclusion, not the trigger. A review request sent to a customer mid-return is a data-quality problem the customer sees before you do.

How do you build a win-back automation for repeat customers?

Trigger: a segment-membership change rather than a single order event — the automation should fire when a customer crosses from “recently active” into “lapsed,” which native segment tooling can express as a condition on time since last order. Delay: none needed beyond the segment condition itself, since the trigger is the crossing, not a fixed clock from a known event. Audience: customers with at least one completed order, subscribed to marketing, whose most recent order crossed your chosen lapsed threshold.

A win-back automation is the one most stores build latest, if at all, because it depends on a segment condition rather than a single obvious trigger — and it’s also one of the automations where the case for automating at all is strongest: Klaviyo reports that 41% of email revenue across more than 183,000 brands on its platform comes from automated flows rather than one-off campaigns (vendor-reported), and a win-back automation is exactly the kind of always-on flow that figure describes — running without a marketer deciding, campaign by campaign, which lapsed customers to re-approach this week.

How do you connect Shopify Flow to a back-in-stock notification?

Native email automations trigger off customer and order events, not inventory events — so a back-in-stock notification generally runs through Shopify Flow rather than through the email automation builder directly. Trigger: an inventory quantity change on the product. Condition: quantity crosses from zero to a positive number. Action: this is where the native path narrows — Flow’s own email action is generally built for internal notifications rather than a branded customer-facing send, so the action that reaches the customer is usually either a connected marketing app’s back-in-stock feature, or a manually triggered send through the native email tool once your team is notified.

Back-in-stock notifications are a clean example of where native tooling’s pieces don’t fully connect. Flow can see the inventory event and knows a customer is waiting; whether it can email that customer directly without a connected app depends on your Flow account’s current action list, which is worth checking in the action picker before assuming the connection exists.

What is the step most teams get wrong?

The step most teams get wrong is building automations before authenticating a sending domain, and then debugging deliverability automation by automation instead of fixing it once, upstream. It shows up as: an automation that “used to work” and now lands mostly in spam, or an automation that tests fine to a personal inbox but underperforms in aggregate — both symptoms of an authentication problem, not a content or trigger problem, and both get chased in the wrong place if the domain setting is never checked.

Audience overlap is a second, equally common version of the same mistake: two automations, each built correctly in isolation, whose segments both match the same lapsed, marketing-subscribed customer. Neither automation is wrong on its own. The customer getting two unrelated emails in the same week is the actual failure, and it’s invisible from inside either automation’s own settings — you only catch it by reviewing segment definitions side by side.

How do you verify a native automation actually works?

Test each automation against a real or deliberately created qualifying event before trusting it — a genuine test order for a post-purchase automation, a test customer manually moved into a lapsed segment for a win-back automation, a real inventory change for a Flow-driven back-in-stock notification. Confirm the email arrives, renders correctly, and reaches the inbox rather than spam, using an inbox outside your own organisation’s mail domain if you can, since internal mail servers sometimes treat your own sends more favourably than a stranger’s inbox would.

Re-test after any change to the trigger, the segment definition, or a connected app — not only at initial setup. An automation that worked at launch can go quiet months later because a tag it filters on was renamed for an unrelated reason, and nothing in the builder surfaces that as an error.

Where does Shopify’s native email tooling stop, and a dedicated ESP become worth it?

Native tooling handles a single-trigger, single-path automation well: one event, one delay, one audience, one email. It has no built-in way to branch that same flow based on what the customer does next — whether they open, click, or don’t — and no built-in way to run a multi-step sequence that changes its own next email based on behaviour partway through. Those two capabilities, conditional branching and multi-step behavioural sequencing, are the core feature of a dedicated ESP such as Klaviyo, and they’re the clearest signal a flow has outgrown what native tooling can express.

The branching gap shows up again in reporting and channel reach. Native attribution generally covers sends, opens, clicks and some order attribution; a dedicated ESP’s flow-level, cross-channel revenue reporting is typically deeper. Native tooling’s SMS capability is built around transactional order and shipping notifications rather than a full SMS marketing automation builder. None of that makes native tooling wrong for a store that hasn’t hit those limits — it makes it the wrong tool once a flow genuinely needs to branch, once SMS needs to be a real second channel rather than a shipping update, or once flow-level revenue reporting is a requirement rather than a nice-to-have. For most $3M–$30M brands, the honest test is whether the automations you actually want to run — not a hypothetical future one — need branching logic native tooling doesn’t have; our guide to Shopify newsletter tools covers the campaign side of the same native-versus-ESP question.

Who should stay on native tooling, and who should move to a dedicated ESP?

A brand running a small number of straightforward automations — a post-purchase thank-you, a simple win-back, notifications tied cleanly to Shopify’s own events — with no need to branch a flow on customer behaviour and no SMS marketing programme, is well served by native tooling, and adding a paid ESP on top of that adds cost and setup work for capability that goes unused. A brand whose lifecycle programme has outgrown a single path per trigger — where the next email in a sequence should depend on whether the last one was opened, where SMS needs to run as a coordinated second channel, or where flow-level revenue attribution drives real decisions — has outgrown what native tooling was built to do.

Getting to that second state without either overbuilding a native setup that was never meant to carry it, or under-configuring a new ESP migration and losing the automations that already worked, is a lifecycle-flows problem: matching the automation logic to the platform that can actually express it, correctly, the first time. Pointerflow’s lifecycle flows work does exactly this for Shopify Plus and enterprise-subscription brands, and our flow revenue calculator is a starting point for sizing what a fuller automation programme is actually worth to your store before you commit to rebuilding it.