Mailspring: a GPL-licensed Electron mail client with a C++ sync engine

What Mailspring actually is

Mailspring is a mail client for macOS, Windows and Linux, maintained by one of the original authors of Nylas Mail. The relationship is direct rather than nominal: the README describes it as a new version of Nylas Mail, sharing lineage and a plugin ecosystem while replacing the internals.

The defining technical decision is that the project is split across two languages and two repositories. The interface is TypeScript running on Electron with React, in the main repository. The sync engine is C++ and C, built on Mailcore2, in a separate Mailspring-Sync repository. The Electron app spawns the sync engine as a child process, which runs locally on your machine.

That split exists for a stated reason: performance. The README claims the new engine uses roughly half the RAM and CPU of Nylas Mail, and that it idles with almost no CPU wakes, which the author connects to battery life on a laptop. The idle behaviour is the part that matters most for a background process that runs all day, and it is a direct consequence of moving IMAP handling out of a JavaScript runtime into compiled code.

One development-environment detail saves a lot of setup: when you configure a dev environment, Mailspring uses the latest sync engine binary already shipped for your platform, so you do not need to clone the sync sources or resolve its compile-time dependencies. Contributors who want to work on the engine itself clone the second repository.

The scale is worth putting in context. At 17,844 stars and 1,040 forks, this is one of the more widely used open source mail clients, with only 24 open issues on the repository.

Features, and the line between free and Pro

The free client includes Unified Inbox, Snooze, Send Later, Mail Rules and Templates. Those are the features people tend to cite when they recommend the app, and Unified Inbox in particular is the one that changes how you work if you have several accounts.

Mailspring Pro is a monthly subscription and adds link tracking, read receipts, mailbox analytics, and contact and company profiles. This is the part of the project where the open source positioning needs reading carefully, so here is what the README states plainly: all of these features run in the client, and Mailspring does not send your email credentials to the cloud.

That is a meaningful distinction and it is unusual for this category. Link tracking in a hosted mail product normally means the vendor's server records the open and clicks on its infrastructure, which requires seeing your mail. Here the tracking happens locally, which is why the Pro tier can exist without a server holding credentials. If you are the kind of person who reads a privacy claim and wants to know the mechanism, this is the mechanism.

Compiled builds are distributed from the project's own download page for macOS and Windows, and for Linux as deb, rpm and snap packages. The snap packaging means there is an official channel on Linux rather than only community builds.

Plugins and themes: the actual extension model

Mailspring is described in the README as built on a plugin architecture and designed to be easy to extend, and the repository backs that up with separate documentation. `PLUGIN_SYSTEM_ARCHITECTURE.md` describes how the plugin system is put together, and the docs are published as a book via `book.json`, which is what the Getting Started guide renders from.

Three contribution paths are offered, in the order the README lists them: build a plugin, build a theme, or send a pull request to the core. For plugins there is a starter repository, and the Getting Started guide promises a first working plugin in five minutes, which is the kind of claim worth testing rather than repeating.

The plugin store is announced as coming soon, and the README is upfront that this is not done yet: for now, users sideload plugins by downloading them and copying them into place. That is a real limitation on discovery, though it does not affect the plugin API itself. If you are writing a plugin for your own use, sideloading is a non-issue.

Themes are CSS. The README notes that the interface is styled using CSS, which makes themes easy to modify, and points at a separate theme starter repository. There is also a documented path for porting an existing Nylas theme, with the practical caveat that you will probably need to import Mailspring base variables. That is the sort of detail that saves an afternoon.

Localization is supported from version 1.5.0 onward, with a dedicated `LOCALIZATION.md` guide for contributors who want to help translate.

Reading 1.25.0 as a map of the sync engine's hard parts

Version 1.25.0 shipped on 2026-09-19 and is worth reading as a document about what is genuinely difficult in an IMAP client, because most of the bug fixes concern protocol edge cases rather than user-visible features.

The most serious entry: initial sync was silently dropping messages on servers that advertise CONDSTORE and QRESYNC, which includes FastMail, Dovecot and Zoho. Only the first 1024 messages of each 5000-message chunk were being ingested. That is a data-loss bug in the plainest sense, present in the client many people use daily, and it is the kind of failure that is invisible because the messages are simply absent rather than erroring.

The second entry is related and worse in one respect: QRESYNC VANISHED handling could unlink an entire folder's messages, or drop expunges permanently, on CONDSTORE plus QRESYNC servers. VANISHED is how QRESYNC tells a client which messages were removed server-side, so mishandling it corrupts the client's view of mailbox state rather than just skipping a download.

The release also notes that it carries several security patches for security vulnerabilities and is recommended for all users, credited to a researcher at ENKI WhiteHat for the investigation and reporting.

Put together, these entries describe the difficulty of next-gen IMAP extensions. CONDSTORE and QRESYNC let a client sync incrementally instead of re-downloading everything, and they are what let a client stay idle, which is the performance property the whole architecture was built to achieve. The trade is that the extensions are finicky, and a client that implements them badly loses mail while looking perfectly healthy to the user.

Platform requirements and the Chromium floor

Version 1.24.0 raised the macOS requirement to macOS 13 Ventura or later, and the stated reason is worth noting because it says something about the cost of the Electron choice: Chromium dropped support for macOS 12, so Mailspring had to follow. Windows and Linux requirements are unchanged.

The same release brought a Linux-specific change that will bite people mid-upgrade: the Flatpak version now uses the Portal for secret storage, and accounts may need re-authenticating after the upgrade. And 1.24.1 fixed accounts being lost entirely on Linux when the KWallet secret name changed, with Mailspring now falling back to the previous secret storage key and re-saving credentials.

That pair of Linux bugs is the clearest argument in the whole changelog for reading release notes before upgrading a mail client. Losing credentials is different from losing messages, because it is annoying rather than silent, which is the best of the failure modes. But it is a reminder that credential storage is one of the areas where a cross-platform client has the most platform-specific surface to get wrong.

Two other fixes from 1.24.0 show the same pattern of defending against bad network conditions: Mailspring now falls back to legacy TLS settings when a handshake is rejected and surfaces a suggestion when it does, and it recovers on Windows from GPU-related renderer crashes that occur before the window loads by relaunching with hardware acceleration disabled. Neither is glamorous. Both are the cost of shipping an Electron app to people whose machines it was never tested on.

Building it, and where to look in the tree

Development needs Node 16.17 or newer and npm 8 or newer, declared in `package.json`, and the install-and-run sequence is three commands. On an Apple Silicon Mac you set the architecture first:

export npm_config_arch=x64 # If you are on an M1 / Apple Silicon Mac
npm install
npm start

Command line parameters go after a double hyphen, which is npm's way of forwarding arguments to the underlying process:

npm start -- --help

Producing a distributable build is a single command, `npm run-script build`, which wraps `@electron/packager` and is declared in the root `package.json` alongside `better-sqlite3` for local storage and `moment` for date handling.

The repository also carries the files you would expect from a project with this many contributors. There is `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` on Contributor Covenant 2.0, `SECURITY.md`, `CLAUDE.md` and a `CHANGELOG.md`. A `playwright/` directory is there for end-to-end tests, `playwright` being the browser automation framework, and there are `.eslintrc` and `.prettierrc` files defining lint and formatting rules. `mailsync` is present as a directory, though `.gitmodules` indicates some of the tree is managed as submodules, which is worth knowing before you go looking for files that appear to be missing.

The test setup is worth noting for anyone planning to contribute to the sync engine. JavaScript unit tests run under Jasmine, based on the `jasmine` and `proxyquire` dependencies, and the Playwright directory covers the UI end to end. That split matches the two-repository structure, where engine changes get tested in the Mailspring-Sync repository instead.

Editorial conclusion

Mailspring is a good fit if you want an email client that looks like a modern consumer app, runs on all three desktop platforms, and can be extended with your own plugins. The sync engine rewrite is the substantive engineering story here, and it is the reason the client idles quietly rather than waking your CPU every few seconds.

The trade-offs are equally clear. Electron means a real memory footprint compared with a native client. The paid tier exists, and while the README states that link tracking, read receipts and mailbox analytics all run locally rather than sending credentials to a server, buying a subscription is what funds a GPL project maintained largely by one person. And the sync engine has produced a genuinely bad class of bug, as the 1.25.0 notes show, where messages were silently dropped on servers advertising CONDSTORE and QRESYNC. Install the current version, which fixes that, and treat feature releases as things to read rather than skip.

To build from source you need Node 16.17 or newer and npm 8 or newer, then `npm install` followed by `npm start`. For themes, the CSS is plain and the starter repository is the fastest way in.

Frequently asked questions

Official sources

1. Foundry376/Mailspring on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases