How to choose

Choosing software for an email course: the decision, in order

Last reviewed 18 September 2026

Features and pricing change, and this page does not track them. Everything below is written as what to check and where to check it, rather than as what is true of a product today. Read the date above, then answer the questions in the product itself.

Choosing software for an email course turns on one property most sending tools were not built for: a clock that starts when each reader confirms, rather than a date you pick. Settle that first, then which doors onto your list require confirmation, then what an unsubscribe reaches, then whose domain the mail leaves on. The rest is preference, and preference can be changed on a Tuesday.

Almost everybody arrives at this decision already paying for something that sends email, and the real question is whether the course can live there rather than somewhere new. Usually it can. What settles it is rarely on a pricing page: it is four settings screens and one rehearsal with two addresses.

What the format requires, before any product is named

A finite daily course is a shape, and the shape asks for specific things. Not one message to everybody at once, but one fixed sequence per person, timed from the day that person confirmed, running for a stated number of days and then stopping. Almost everything worth knowing follows from that sentence, and almost none of it shows on a feature grid.

The eight requirements listed on the hub page are the whole list, and they read better as requirements of the format than as features to demand. A tool that meets six of them is not failing; it was built for a newsletter or a marketing sequence and it does that job. The question is whether the two it misses are two you need. Two of the eight are also hard to reverse: whether every door onto your list asks for confirmation, because consent is impossible to collect retroactively, and whether you can send from a domain you own.

The order to decide in, and why the order matters

Decide the clock first, because it is binary and a no ends the evaluation. If a tool schedules from a calendar date rather than from each reader’s own start, it sends newsletters, and a course built on it works exactly once.

Then the doors, then the unsubscribe, then the domain, then everything else. That order is not taste. It runs from the structural decisions, through the ones that are expensive to unwind, to the ones that are a setting. Templates, a visual builder, branching, tags, a landing page, a checkout, integrations with a shop or a webinar: all real, and all further down, because none of it is why a course fails.

The four decisions that come first, and where each answer actually lives
Decide	Where the answer lives	How to test it yourself
What starts the clock	The screen where a sequence is built, never the pricing page	Join with one address today and a second tomorrow; the second should get day one
Which doors need confirmation	Form, import and API settings, one at a time	Import a one-row spreadsheet and see whether anything asks it to confirm
What an unsubscribe reaches	List or audience settings, and the footer of the message itself	Unsubscribe on day three and watch what still arrives
Whose domain the mail leaves on	Account-level sending or domain settings	Look for the DNS records it asks you to add; none means a shared domain

What a feature grid hides, including this one

Every tool in this category says it handles sequences, retries and unsubscribes, and at the level a grid records, every one of those sentences is true. The differences live a layer down, in behaviour nobody publishes: what the scheduler counts a delay from, whether the same person can enter the same sequence twice, whether an unsubscribe belongs to a workflow or to a person, and what the sending code does when the mail provider accepts a message and then times out before saying so.

That last one is the honest limit of any page like this. Sent late is an inconvenience; sent twice is a complaint, and the shape that prevents it is a uniqueness rule held in the database rather than in a code path. No vendor publishes its schema, so both questions about it are asked in writing: is a duplicate prevented by the database or by the sending code, and what happened the last time your mail provider timed out mid-send? The first reply names a mechanism or describes a promise. The second is detailed from anybody who has lived through one.

The rehearsal that settles most of it in an afternoon

Every question above has an answer you can produce yourself on a trial account, with two addresses at two different mailbox providers and a course with real words in it. Read what arrives on a phone, which is where most of it is read.

In the order that finds problems earliest:

Join with the first address today and the second tomorrow. The second should receive day one. If it receives day two, the tool schedules from a date and you are finished.
Put the second address in a time zone several hours away before it joins, then look at the clock on day two. Arrival hour is described honestly by no interface.
Submit the form again from the first address after it has confirmed. A second copy of day one is a duplicate; a second confirmation request is not.
Import a one-row spreadsheet holding a third address you own, and see whether anything asks it to confirm.
Reply to day one, and find out where it landed and whose name was in the From line.
Unsubscribe from the second address on day three using the mail client’s own button rather than the footer link, then watch for days four and five, and for anything else the account sends.
Edit day four while the first address is sitting on day two, and see which version that address receives.

When the right answer is the tool you already pay for

Moving a list costs more than it looks. The addresses come out of anything. The consent record is harder, and the suppression list — everyone who unsubscribed, bounced hard or complained — is rarely beside the export and usually has to be asked for by name. Arriving somewhere new without it means a fresh reputation opening with a send to every person who already asked you to stop.

So the default is to stay, and the case for moving rests on one of the two hard-to-reverse questions rather than on a feature you would enjoy. A tool that starts the clock on confirmation, asks for it on every door, honours an unsubscribe across the account and will let you send from your own domain has put no ceiling on anything. One that schedules only from dates has put a ceiling on the list rather than on the course.

What to check, and why each one matters

Does the first lesson go out when the reader confirms, and is every later delay counted from that moment?
It is the property most sending tools were not built for. A delay counted from the previous send also drifts: three waits of a day after a late-night confirmation put the rest of the week near midnight.
What happens when an address already inside the course signs up a second time?
People submit forms twice. Where the second submission counts as a new entry, that reader gets two day threes a few days apart and nothing reports it.
Which doors ask for confirmation and which let an address straight through: form, import, manual add, API, integration?
A service can require confirmation on its own form and take an unconfirmed address through five other doors. Consent that was never collected is the one thing on this list you can never collect later.
When somebody unsubscribes, what stops: this course, this list, or everything the account would send them?
In many builders an unsubscribe belongs to a workflow rather than to a person, so leaving the course leaves the rest running, and somebody who left on Tuesday reports spam on Wednesday.
What arrives on the day after the last lesson, and who decided that?
A finite course always has a day six, and the tool has a default: silence, a note saying it is over, or a door into something else. An unchosen silence wastes the day the reader just finished.
If you fix a broken link on day three this afternoon, who sees the fix: everybody, or only tomorrow’s arrivals?
Some tools push an edit to everyone; some hold each person to the sequence as it stood when they entered. Both surprise people, and which one you have decides how a correction is made.
Is sending from a domain you own possible at all, and what has to be added to DNS for it?
A shared domain needs no records and no warm-up, at the cost of a reputation shared with every other customer and a complaint rate you never see: mailbox providers report it per domain.
What comes out on the way out: the addresses alone, or the consent wording, the timestamps and the suppression list too?
Every tool exports addresses. The consent record answers a complaint two years later, and the suppression list stops your first send somewhere new from reaching everybody who already left.

Common questions

What should I decide first when choosing email course software?

Decide what starts the clock. A course sends a fixed sequence to each person timed from the day they confirmed, so a tool that schedules from a calendar date sends newsletters instead, and a course built on it works once for the people already on the list. Test it by joining with one address today and a second tomorrow: the second should receive day one.

Can I run an email course in the tool I already use?

Usually yes, and usually you should. Moving a list is expensive: the addresses export from anything, but the consent record is harder and the suppression list is rarely beside it. The case for moving has to rest on one of the two hard-to-reverse questions, which are whether every door onto the list asks for confirmation and whether sending from a domain you own is possible at all.

Do I need software built specifically for email courses?

No. A general tool that starts each sequence from the reader’s own confirmation does the job, and it also sends the announcement a narrow tool has no way to send. A narrow tool earns its place when the course is the whole publication rather than one thing among several. The trade is between a tool that does two jobs adequately and one that does a single job properly.

How do I test email course software before I pay for it?

Open a trial, put a real course behind it, and use two addresses at two different mailbox providers. Join a day apart and check that the later one receives day one. Set one address to a distant time zone and check the arrival hour. Submit the form twice from one address. Import a spreadsheet and see whether anything asks for confirmation. Unsubscribe on day three with the mail client’s own button.

What should I ask a vendor that a settings screen will not answer?

Two things, in writing. Whether a duplicate send is prevented by the database or by the sending code, and what happened the last time their mail provider timed out mid-send. The first reply either names a mechanism in one sentence or describes a promise. The second is detailed from anybody who has lived through one, and vague from anybody who has not.

Feature grids converge and behaviour does not. Two addresses a day apart, one real course and one afternoon tell you more about a tool than any table of ticks, and the table was written by somebody who never joined the list twice. Decide the clock, then the doors, then the unsubscribe, then the domain.

Sources

Elsewhere on this site

The rest of this site comes at the same subject from other directions: guides on the format itself, a tool for one job each, a page for each kind of work, and what to check when choosing software.

Guide
Email course software: the four kinds, and what separates them
Guide
Email deliverability for small senders: authentication and reputation
Free tool
Email course outline generator
By the work you do
Email courses, by the work you do

Thinking of writing one of these?

5dayemail hosts a five-to-ten day email course: you write it once, and everyone who joins your list gets one email a day, in order, starting from the day they confirm.

Accounts are opened a few at a time rather than by signing up. Leave your address and you will be written to when the next ones open.

One message, when there is room. No course emails, no newsletter, and the address is not passed on. Ask and it is deleted; what is kept, and for how long, is in the privacy policy.