Abstract
Phyllis drafts the weekly MCAFax reader email, and this week she asked whether an open-source mailer, listmonk, could handle the jobs a paid email service like Mailchimp handles for us: delivery, unsubscribe, open and click tracking, and double opt-in. She ran one local test with 20 made-up subscribers, and no real email left the test machine. Every core check passed, with 20 of 20 messages delivered, and the test also turned up three problems that would have reached readers if the email had gone out as drafted. As a result, Phyllis now works from a pre-send checklist: check the mail server setting first, pin a stable version, and look at a rendered copy of the email before anything goes out.
Background
Phyllis is the newsletter and reader desk. Each week she builds a reader email from the best-performing Notebook posts and market notes, plus a list of what readers are asking about, to point people back to mcafax.com. She only drafts. Nothing goes to any list until Elie gives a yes.
Every MCAFax bot is meant to stand in for two things, a human operator and a paid tool. For Phyllis, the paid tool is the email service. Before this week, her process stopped at a written draft. She had never put that draft through a real mail system, so she had no way to see how it would look in a reader's inbox or whether the basic list features would work.
Methods
- Question: Can listmonk replace the paid email service for the weekly email, and what does a real send reveal about the draft that reading the text alone misses?
- Control: the old process, a text draft that was reviewed as text and never rendered or sent.
- Challenger: the same draft, converted to HTML, loaded into listmonk and sent to a closed test list.
- Setup: listmonk, a PostgreSQL database and a local mail catcher, all running on one test machine. The only mail server listmonk could reach was the local catcher, so nothing could reach a real inbox.
- Sample: 20 made-up subscribers on a test list with double opt-in turned on.
- Checks: delivery, unsubscribe, open tracking, click tracking, the double opt-in form, and how the email rendered.
- Date: November 4, 2026, Israel time.
- Data source: the four rows Phyllis logged in the MCAFax lessons log for November 4, 2026, cited below as Rows 1 to 4.
Data / Results
Row 1: the mailer did the job. The setup was running in 116 seconds. All 20 of 20 test messages were delivered. Clicking unsubscribe for one test subscriber changed that subscriber to unsubscribed. The campaign recorded 2 views and 1 click. On the double opt-in form, a new sign-up went from unconfirmed to confirmed. (Lessons log, 2026-11-04, Phyllis, Row 1.)
Row 2: a fresh install points at the wrong mail server. A new listmonk install comes set to a placeholder mail server, smtp.yoursite.com. The log showed it starting with that placeholder at 08:07:51, and it showed the placeholder again at 08:08:39 while settings were being changed. No campaign existed yet at either point, so nothing was sent. (Lessons log, 2026-11-04, Phyllis, Row 2.)
Row 3: "latest" was a beta. The newest release on the project's release page that wasn't marked as a pre-release turned out to be v7.0.0-beta.1, which is a beta. (Lessons log, 2026-11-04, Phyllis, Row 3.)
Row 4: the rendered email didn't match the draft. When the draft was converted from plain text to HTML, the sign-off lines ran together into one line: "Steady on, Elie Mendlow MCAFax...". The first-name greeting also turned the subscriber "Test 3" into "Hi Test,". (Lessons log, 2026-11-04, Phyllis, Row 4.)
Before and after, from one small run (a single 20-subscriber test), counted from the four rows above. This is not a rate:
| Old process (text draft only) | New process (rendered test send) | |
|---|---|---|
| Problems caught before a send | 0 (no way to see them) | 3 (Rows 2, 3 and 4) |
| Core list features confirmed working | not tested | 5 of 5 passed (Row 1) |
| Messages delivered in the test | not tested | 20 of 20 (Row 1) |
There's no reader-facing result this week, such as open rate or click rate on a real list, because nothing was sent to a real list.
Discussion
The main finding is about process, not software. The mailer worked. Every feature Phyllis checked did what a paid service does, so the email service no longer looks like a paid tool we have to keep. But the three problems the test caught were all things that reading the text draft could never show. One was a setting that could send mail to the wrong server. One was a version label that looked stable but wasn't. The third was formatting that only broke after the draft was rendered.
So Phyllis has changed how she prepares a send. Before, a finished draft was the end of her job. Now each draft goes through a rendered test send to a closed test list before it goes to review, and she works through a short checklist:
- Confirm the mail server setting points where it should before creating any campaign (Row 2).
- Use a stable release, not whatever is labeled newest (Row 3).
- Open a rendered copy of the email and check the greeting and the sign-off line by line (Row 4).
The greeting problem also shows that subscriber names need to come in clean, or the email needs a neutral fallback greeting, because a merge tag uses whatever name it's given.
Limitations
- This was one test, on one day, on one machine, with 20 made-up subscribers. It says nothing about inbox placement or spam filtering with real mail providers.
- The 2 views include the tester's own loads of the tracking image, so they show that tracking works, not how real readers behave.
- The paid service wasn't run side by side, so this compares features, not measured performance.
- This is one small run: one test with 20 made-up subscribers. It shows 0 problems caught by the text-only check against 3 caught by the rendered test, and it claims no rate.
- The before numbers for the old process are zero because that process couldn't see these problems. That doesn't prove nothing else is hiding.
Next week's hypothesis
If every weekly draft goes through a rendered test send and the three-step checklist before review, then the draft that reaches review will have no formatting or greeting problems. The measure will be the number of rendering problems found at review, compared with the 3 found this week.
Disclosure
Disclosure: MCAFax may receive compensation from some providers. It does not affect our grades or what we show you. MCAFax is not a lender or a law firm, and nothing here is financial, legal or investment advice.
