Can confirmed opt-in be turned off in 5dayemail?

No. Every address confirms before it receives anything but the confirmation email, on every path onto a list — the hosted sign-up page, the embedded form and an imported list alike. There is no setting that changes this, and the rule is enforced by a database constraint rather than by application code, so no later feature can route around it.

Why does 5dayemail insist on confirmed opt-in?

Because every creator on the platform sends course mail from the same sending domain. Inbox providers judge a domain by everything sent from it, so one creator mailing a bought or stale list would damage delivery for every other creator. Confirmed opt-in is the single strongest protection for that shared reputation, which is why it is a property of the platform rather than a preference of each account.

What happens when I import an existing list into 5dayemail?

The import is a re-permission campaign, not a transfer. You say where the consent came from, every address enters as pending, and each one receives a single confirmation email and nothing else. Only the addresses that click join the course — so the list you end up with is the part of the old one that still wants to hear from you.

Why Confirmed Opt-In Is Not a Setting in 5dayemail

The textbook way to design a contested product decision is to make it a setting. Some customers want single opt-in because it grows a list faster; some want confirmed opt-in because it grows a cleaner one; so you add a toggle, default it sensibly, and let each account choose. In 5dayemail there is no toggle. An address that has not clicked its confirmation link receives exactly one message, ever — the confirmation itself — and nothing in the product can change that. Like Delivery Sheet's four decisions, it's one rule that contains the whole shape of the product.

Why a toggle would be the wrong kind of freedom

A setting is the right answer when the consequences of the choice land on the person choosing. This one doesn't work that way. Every creator on 5dayemail sends from the same course-sending domain, and inbox providers judge a domain by everything that leaves it. One creator who pastes in a bought list and mails it unconfirmed doesn't only hurt their own delivery — they spend reputation that belongs to everyone else on the platform.

So the toggle would not be offering each creator a choice about their own list. It would be offering each creator a choice about everybody's.

A setting is fine when the person who flips it pays for it. On a shared sending domain, the person who turns off confirmed opt-in is spending someone else's reputation — so the switch doesn't exist.

Enforced where it can't be argued with

There is a difference between a rule the application follows and a rule the system cannot break. The confirmed-opt-in rule lives in the database, as a constraint, rather than in a preference the code checks. That matters less today than it will in a year: a rule in application code holds until the next feature finds a path around it — an import screen, an API, a "just this once" for a large customer. A rule in the schema holds for all of those at once, including the ones nobody has thought of yet. It is the same reason a segregation-of-duties control belongs in the system and not in a policy document.

The record of consent gets the same treatment. The exact sentence a reader agreed to is stored with the date and the address — the wording they actually saw, not the wording the form has today.

What it costs, honestly

It costs sign-ups. Some people who type an address never click the link, and a creator watching the numbers will see "signed up" run ahead of "confirmed." The stats page shows both, on purpose, because hiding the gap would be the first step towards pretending it isn't there.

It also changes what an import is. Bringing an existing list into 5dayemail is a re-permission campaign rather than a transfer: every address arrives as pending and gets one confirmation email. For a creator with ten thousand stale addresses that is a painful number to watch shrink. It is also the true number — the part of the old list that still wants to hear from them.

The rules that follow from the same reason

Once the shared domain is the thing being protected, several other decisions stop being debatable:

One-click unsubscribe on every message, in the headers a mail client reads and as a visible link, honoured the moment it's pressed.
A sender name and a postal address before a course can be published — a course email without them is one no inbox should trust.
Sending volume ramps over an account's first three weeks rather than starting wide open.
No open tracking. Apple Mail fetches a tracking pixel whether or not anyone read anything, so the number isn't worth collecting — and a shared tracking domain is one more thing that can end up on a blocklist.

None of these has a switch either, and for the same reason.

The principle behind it

This is not letting the tool decide turned inside out: there, the product refuses to make a judgment that belongs to the human; here, the product refuses to hand over a decision whose cost falls on other people. Both come from asking who actually pays for a choice before deciding whose choice it is. It makes 5dayemail a worse fit for anyone who wants single opt-in — and saying who a product is not for is part of building it.