For most publications and many businesses, the email list is the most valuable asset they own: the one audience that does not depend on a search algorithm or a social platform. Where that list lives is therefore a strategic decision, not a technical one.
emDash sends email for sign-in links, invitations and account recovery, but it has no subscriber list or newsletter feature, which forces the question. We answered it with a deliberately small build that keeps the list inside the site. It is not a newsletter platform, and it is not trying to become one. It is a foundation: once the subscribers, their consent and the content all live in one place, many of the features that made WordPress plugins such as MailPoet, The Newsletter Plugin and FluentCRM popular become small, incremental additions rather than a second system to buy.
Why the list belongs in the platform
Most newsletter set-ups put the list in the email provider and connect the website to it. That is quick, and it hands the provider the asset. Changing provider later means exporting, reconciling and re-importing the list, usually while trying not to lose anyone's consent record. It also splits the audience in two: the website knows what people read, the provider knows who they are, and neither can act on both.
We inverted it. The list lives in emDash, in the site's own database, with each subscriber's status, the date they confirmed and where they signed up. The email provider holds a synchronised copy and does what it is good at: delivery, bounce handling and unsubscribe links.
| Concern | List held by the provider | List held in emDash |
|---|---|---|
| Switching provider | Export, reconcile and re-import | Point the site at the new service |
| Consent record | Lives with the vendor | Lives with you, next to your content |
| Who controls the letters | The provider's template editor | The site, alongside its design system |
| Joining reading and subscribing | Two systems, matched by hand | One database, ready to combine |
| Effort to build | Lowest | Moderate: a plugin and a sync |
What we built: a deliberately small foundation
The first version does only what a publication needs on day one, and does it carefully.
| Capability | What it does | Why it matters commercially |
|---|---|---|
| Double opt-in sign-up | A visitor enters an address, receives a confirmation email and confirms on a page with a button | Corporate security tools open links before people do; requiring a click keeps consent genuine and the list clean |
| Invisible spam protection | A challenge appears only when a visitor looks automated | No puzzle on every form, so fewer abandoned sign-ups |
| Confirmation and welcome letters | Built in the site's design, with their wording editable in the plugin settings | The first impression moves with the list, whichever provider sends it |
| Subscriber records | Each subscriber's status, confirmation date and sign-up source, with confirmed and unsubscribed counts in the admin | The asset and its consent trail sit where the content team works |
| Two-way unsubscribe sync | Unsubscribes made through the provider update the site's record | One source of truth for consent |
| Daily housekeeping | Unconfirmed sign-ups expire and are removed automatically | Personal data is not kept longer than it is needed |
Two rules kept the synchronisation safe. Every incoming notification is checked against the site's own sending domain first, because an email provider account often serves several websites and its notifications can cover all of them. And a notification may only update people already on the list; adding someone is always the site's decision.
What the foundation makes possible
The established WordPress plugins are a useful map of what readers and marketers have come to value. MailPoet built its following on sending new posts to subscribers automatically and on segmenting lists by behaviour. The Newsletter Plugin made automated newsletters, autoresponder series and a public archive available through modular add-ons. FluentCRM went further, turning the WordPress database into a self-hosted CRM with tags, segments, contact histories and visual automation funnels.
Each of those features rests on the same three ingredients: a list you control, content you publish, and events that tie the two together. emDash provides all three. Plugins can react when an entry is published, run on a schedule, keep their own indexed records, add pages to the admin and send email through the configured provider. That is why the features below are incremental additions to the foundation, not a new system.
| Feature | Proven in | How it would work on emDash | Business value |
|---|---|---|---|
| Post notifications | MailPoet, The Newsletter Plugin | A plugin listens for newly published articles and emails subscribers, immediately or in a batch | Every article reaches the people who asked for it, without anyone pressing send |
| Automated weekly digest | MailPoet, The Newsletter Plugin | A scheduled task assembles the week's published articles into an issue, skipping weeks with nothing new | A regular habit for readers at no editorial cost |
| Topic preferences | MailPoet segments, FluentCRM tags | Subscribers choose topics from the site's own categories, which already describe every article | Fewer unsubscribes, and more relevant email for each reader |
| Welcome series | The Newsletter Plugin autoresponder, MailPoet welcome emails | A short sequence of letters spaced over days, drawn from the site's best evergreen articles | New subscribers meet the cornerstone content while their interest is highest |
| A subscriber browser | All three | An admin page to search, filter and export subscribers, built on records the site already holds | The team can answer questions about the list without opening the provider |
| Engagement reporting | All three | The provider's open, click and bounce notifications, already arriving for unsubscribes, are stored against each subscriber | Know which topics and issues earn attention; spot a deliverability problem early |
| Re-engagement and list hygiene | MailPoet inactive subscribers | A scheduled task flags subscribers who have not opened in months, sends one check-in and pauses the rest | Better deliverability and lower sending costs |
| A single contact record | FluentCRM | Newsletter sign-ups, form enquiries and, later, member accounts joined into one profile with a timeline | Sales and editorial see the whole relationship, not three fragments |
| Event-triggered emails | FluentCRM funnels | A form submission, a download or a course enrolment starts a short, purpose-built sequence | Leads are followed up consistently and immediately |
| Sponsored placements | Common in publication newsletters | The site's existing advertising model supplies a sponsor slot for each issue, with disclosure handled once | A revenue line that grows with the list, not with page views |
Two features are already in place through the content model rather than the email plugin. The weekly issue is a structured entry in the CMS — a lead story, a set of items and an introduction — and published on the site's public archive, so a future email edition can come from the same source. And because the site has a built-in connection for AI agents, an editor can already ask an agent to draft the week's issue from what was published, then review and publish it.
What we would deliberately not build
The point of keeping the list in the platform is to own what differentiates the publication, not to reproduce everything a specialist product does. Some things are better bought.
High-volume delivery, IP reputation, authentication and bounce processing are a specialist's job. The provider stays, and stays replaceable.
The letters use the site's design system. A small set of well-made templates serves a publication better than an open canvas.
FluentCRM's visual funnels suit businesses with many journeys. A publication needs a few well-chosen sequences, built as code and reviewed like content.
How the WordPress options compare
For teams arriving from WordPress, the comparison is less about features than about where the list lives and how much of the stack you want to run.
| MailPoet | The Newsletter Plugin | FluentCRM | emDash Now's approach | |
|---|---|---|---|---|
| What it is | A newsletter and email-marketing plugin | A modular newsletter plugin with paid add-ons | A self-hosted CRM and marketing-automation plugin | A small plugin on the platform, extended as needed |
| Where the list lives | Your WordPress database | Your WordPress database | Your WordPress database | Your emDash database |
| Strengths | Post notifications, segmentation, WooCommerce emails, its own sending service | Automated newsletters, autoresponders, many delivery integrations, a public archive | Contact profiles, tags and segments, visual funnels, deep plugin integrations | Ownership and design control, with nothing to maintain beyond what is used |
| Free tier | Up to 1,000 subscribers, with MailPoet branding | A free core with paid add-ons | A free core with a Pro edition | No licence; delivery is paid to the provider |
| Runs on emDash | No | No | No | Yes |
All three are mature, well-supported products, and a WordPress site already running one well has no urgent reason to change. What they show is that list ownership — the principle MailPoet and FluentCRM share by storing subscribers in the site's own database — is the right default. emDash Now applies the same principle on a newer platform, starting smaller and adding features only as the audience earns them.
The recommendation, by where you sit
- Running a WordPress site that works. If your list lives in a newsletter plugin's database or a provider account, document where the consent records are before any platform decision. If you rely on FluentCRM-style automations, list them; they are the part of a move that needs planning.
- Commissioning a new site. Specify list ownership in the brief: the site holds the list and the consent record; the provider delivers. Then budget the first features as a roadmap — notifications, digest, preferences — rather than buying a suite on day one.
- Running an agency. The foundation is a repeatable deliverable, and each feature on the roadmap is a scoped, billable increment. List ownership becomes a client benefit you can show, not just describe. The wider build is described in what we learned running emDash in production.
