Apple Mail Extensions vs Old Plugins: What Still Works

If you are asking whether old Apple Mail plugins still work on macOS, the short answer is no. The Mail bundle system that hosted them — plugins installed into ~/Library/Mail/Bundles and enabled through a compatibility check that most third-party bundles patched around — is not something a modern macOS release trusts anymore. A plugin that worked on macOS Sierra probably survived High Sierra, was on borrowed time by Mojave, and quietly stopped loading somewhere between Catalina and Monterey. If a favourite plugin disappeared after an OS upgrade, that is why.

Apple did not just remove plugins. It replaced the mechanism with MailKit, a framework introduced in macOS 12 Monterey in 2021 that hosts a narrow set of sandboxed extensions in place of unsanctioned bundles. This post is a head-to-head between those two architectures — the old Mail bundle world and the current MailKit extensions — so you can tell which era a tool you remember belongs to, why it silently stopped working, and what is actually installable in 2026.

The verdict up front#

MailKit extensions are what still works. If you install anything that claims to extend Apple Mail on macOS Sonoma or Sequoia today, it is either a MailKit extension shipped inside a regular app, or it is a workflow that lives outside Mail entirely — a Shortcut, an AppleScript, a Rule, a separate mail client. There is no third path that is both sanctioned and general-purpose.

MailKit extensions are also deliberately narrower than what old bundles could do. The framework exposes four extension points and no more: compose extensions that validate or modify a message before it sends, content blocker extensions that filter remote content in incoming mail, message action extensions that add categorisation actions, and message security extensions for signing and encryption. Anything a plugin used to do outside those four buckets — rewriting the sidebar, adding a tag column, modifying the message list, unified inbox behaviour, snoozing, send-later — is not something a MailKit extension is allowed to build.

For readers who arrive here from 'why did my Apple Mail plugin stop working?' the useful frame is this. The plugin did not break — Apple removed the loading path. The functionality it provided is either now available as a MailKit extension inside a different, notarized app, or it is not available at all in Apple Mail and never will be. In the second case, the honest option is to stop trying to bolt it back onto Apple Mail and either use a different client or automate around Mail from outside.

At-a-glance: MailKit extensions vs old Mail bundles#

One row per architecture. The dimensions below are what actually decides whether a tool you want still exists in a form you can install.

Where MailKit extensions win#

The MailKit era is narrower, and every honest article about it has to say why the narrowness is the point.

They survive macOS upgrades. The single biggest reason old bundles disappeared is not that they were badly written — it is that Apple bumped the plugin compatibility UUID in every Mail release, and most bundle authors either did not have the resources to keep patching or gave up when Apple started actively hardening against the workarounds. A MailKit extension is built against a supported SDK. It keeps working across macOS releases the same way any other Mac app does, without an author scrambling on release day.

They cannot break your mail. A Mail bundle ran inside the Mail process. If it crashed, Mail crashed. If it corrupted state, the state it corrupted was your live mailbox. A MailKit extension runs in its own sandboxed process, receives only the specific pieces of message data the API hands it, and cannot reach into the Mail application's internals. This is the trade for the narrower feature set — and for anyone who lost a mailbox to a bundle-caused crash on Sierra, it is not a small trade.

They are distributable the normal way. A MailKit extension ships inside a regular Mac app. That app can be sold on the Mac App Store or as a notarized direct download; it can offer a trial, take payment, push updates through the same mechanism as any other app. Bundles never had any of that infrastructure — they were shareware installed by dragging a file into a folder, and the update story was 'check the developer's blog every few months to see whether they had a chance to patch for the new OS'.

They match how the rest of the system now works. Safari extensions, Photos extensions, Finder extensions, Share extensions — everything on macOS uses the same sandbox-plus-container-app pattern now. Mail was the last hold-out, and until MailKit shipped there was no way for Apple to reconcile 'we take security seriously' with 'we allow arbitrary code injection into an app that reads all your mail'. MailKit is that reconciliation.

Where old Mail bundles won (and no longer do)#

The bundle era is over, but a fair comparison names the things it did that MailKit does not. This section is a memorial, not a recommendation — none of this comes back.

General-purpose UI modification. A bundle could add a column to the message list, put tags in the sidebar, replace the toolbar, change how the thread pane rendered, or overlay a snooze button on every message. MailKit exposes none of this. If a tool you loved changed the Mail interface itself — MailTags-style tagging, a sidebar redesign, a custom quick reply pane — the MailKit era has no home for it.

Deep integration with Mail's data model. A bundle could reach into the Mail app's Objective-C internals and hook methods on message send, message receive, mailbox open. This let plugins do things like write a header for every outgoing message, log conversation state to a database, or trigger a script when a specific mailbox got new mail. MailKit gives you narrow, structured hooks — a compose extension sees a specific outgoing message; a message action extension sees the messages the user has selected — and nothing more.

Unified inbox and cross-account features. Apple Mail's unified inbox is what Apple Mail's unified inbox is; a bundle could improve or replace it. MailKit cannot. If you remember a plugin that gave you a better cross-account search or a smarter unified view, that plugin's category no longer exists inside Apple Mail — the honest replacement is a different client, not an extension.

Free installation of arbitrary code, which is the point. Everything above is also true of every macOS app that got locked out of injecting into another app's process. The bundle era was not stable; it just felt stable for a few years. The reason each macOS release used to break your favourite bundles is that Apple was fixing what should not have been possible in the first place, and MailKit shipping in 2021 was the last step in closing it.

Why your specific plugin stopped working#

Because the loading path is gone, the reason is almost always one of these four. Match your case to a row.

How to enable a MailKit extension on Mac#

Assuming the vendor ships a MailKit-based app and you have installed it, the extension does not turn itself on automatically. There are two places macOS lets you enable it — either works and both toggle the same setting.

1. 1

   Open the container app at least once

   Launch the app that contains the extension. macOS does not register a MailKit extension with Mail until the app has been opened and the system has recognised it. If you have never opened the app, the extension will not appear in Mail's settings at all.

2. 2

   Open Mail and go to Settings > Extensions

   In Apple Mail on macOS Ventura or later, choose Mail > Settings from the menu bar, then click the Extensions tab. Every MailKit extension the system knows about is listed here. Tick the box next to the extension you want to enable and, if applicable, tick the individual extension types (Compose, Content Blocker, Message Action, Message Security) it offers.

3. 3

   Or use System Settings > General > Login Items & Extensions

   The same list is available under System Settings > General > Login Items & Extensions > Mail Extensions on macOS Sequoia (or Extensions > Mail Extensions on Sonoma). Enabling from either place has the same effect; you do not need to do both.

4. 4

   Restart Mail if the extension does not appear

   If the extension is installed and enabled but its features never show up, quit Mail entirely (Cmd-Q, not just close the window) and reopen it. Mail loads extensions on launch, and a running instance will not pick up a newly enabled one.

5. 5

   Confirm the extension type actually does what you expect

   A Message Action extension shows up as a new option in the message action menu. A Compose extension runs at send time. A Content Blocker filters remote resources in incoming mail. A Message Security extension operates on signed and encrypted messages. If you enabled the extension and nothing visible happens, check that you are looking in the right place for its category.

Pricing model — verify at the vendor at write time#

Neither MailKit extensions nor old Mail bundles are products; they are distribution mechanisms. What matters for a reader deciding whether to install something is the packaging shape of the specific app the extension ships inside. That shape is set by each vendor and moves without notice, so verify on the vendor's own page before you commit.

Who each is genuinely for#

Because there is no meaningful choice between the two architectures — the bundle era ended in 2021, and MailKit is what remains — the real decision is between installing a MailKit extension, working around Apple Mail from outside, or picking a different client entirely.

A third option, honestly: give up on extending Apple Mail#

For a large share of readers who arrive here from 'why did my Apple Mail plugin stop working?', the truthful answer is not on the extension list. The old plugin did something that MailKit does not permit — sidebar redesign, cross-account rules, snooze, unified inbox improvements, agentic drafting — and the honest option is to stop trying to bolt a replacement onto Apple Mail and either automate around it from outside, or use a different mail client whose native feature set covers the thing you wanted the plugin for.

AI Emaily is the third option in that shape. It is not a MailKit extension and it does not attach to Apple Mail; it is a separate mail client that connects your iCloud, Gmail, Microsoft 365 and IMAP accounts in one inbox, with an AI agent that triages and drafts in Copilot mode — every send goes through an approve-before-send step, with undo and an audit log. Voice comes from a user-set Personal Context brain and per-client profiles, not from scanning your archive. We build AI Emaily. Where this is the wrong pick: if you specifically want to stay in Apple Mail for its Siri, Shortcuts, Focus and Mail Privacy Protection integration, no third-party client — ours included — will match those, and a MailKit extension is the only sanctioned way to add to Mail itself. See our pricing shape (a 7-day free trial on Pro and Autopilot, card required, $0 if cancelled before day 7 — no permanent free tier) at aiemaily.com/pricing.

The other honest third option: keep Apple Mail for iCloud and add a different client for the accounts and jobs Mail plus MailKit cannot cover. Two clients on the same account will double-notify — turn off notifications in the one that is not your primary. This hybrid pattern is common in 2026 and it is the shape a lot of Mac users have settled on precisely because the general-purpose plugin era is not coming back.