MailTrackerBlocker: a Mail plugin that names the tracker instead of hiding the image
Email tracker, read receipt and spy pixel blocker plugin for macOS Mail (10.11-13.x)
At a glance
- What is it?
- MailTrackerBlocker is a BSD-3 mailbundle plugin for macOS Mail that intercepts remote images in incoming messages, identifies which vendor they came from, and lets you view the rest of the message with images on. Its hard boundary is the plugin system itself, which Apple removed in macOS Sonoma.
- Who is it for?
- MailTrackerBlocker fits someone on macOS 12 or 13 who still runs Apple Mail, wants to keep remote images switched on for a normal looking inbox, and wants to know which company is watching. It does not fit anyone on macOS 14 or later, because the legacy Mail plugin path the project depends on was dropped there, and it does not fit a user who has already moved to Apple Mail's built-in privacy proxy and is content to lose remote images entirely.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 41 days ago.
- What is it written in?
- Mainly Objective-C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A mailbundle that sits between Mail and the remote image
MailTrackerBlocker is a plugin for Apple Mail, packaged as a `mailbundle`, and it is written in Objective-C. The problem it addresses is specific: marketing email embeds remote images, and each fetch tells the sender that the message was opened, and often from where.
Apple's own answer has been to turn off remote content, which works but leaves the inbox looking broken. MailTrackerBlocker takes the opposite approach. It blocks and identifies the tracking pixels, then lets you re-enable remote content for the images that are safe, so you get a normal looking inbox plus a list of who was blocked. The plugin adds a button to the Mail toolbar, and tapping it shows what was blocked.
The identification side is worth understanding, because it is where the project draws on other work. The credits list a spy pixel tracker block list used in HEY from @dhh, a Simplify Gmail blocklist from @leggett, the original UI design and icon from @raybrownco, and the open source GPGMail plugin from the GPGTools Team, which MailTrackerBlocker is based on. SpamSieve's Mail knowledgebase and troubleshooting manuals are credited for the troubleshooting material. So the matching logic is a curated list of known tracker hosts rather than a heuristic, and it inherits the shape of a blocklist that already had to be maintained for the web.
The repository layout supports that reading. There are `MailHeaders/`, `Source/`, `Resources/`, `Packaging/`, `Unit Tests/`, an `unsign` helper directory, a `Makefile`, an Xcode project and a `Version.config` file.
Mail Privacy Protection changes what blocking means
The project's own FAQ is candid that MailTrackerBlocker and Apple's Mail Privacy Protection are not equivalent, and that the interaction has a subtlety worth understanding before you rely on either one.
Apple's Mail Privacy Protection routes remote images through a proxy. The project's answer to the question of whether the two work together says yes, in some network environments, for example a VPN, where Mail Privacy Protection does not work, MailTrackerBlocker will still block and identify trackers if you choose to load remote content. In other words, on a network where Apple's proxy is not doing its job, this plugin is the fallback.
The warning that follows is the important part. Apple's proxy still fetches the tracker image, and it triggers the tracker after an unknown period of time. If you open a message without MailTrackerBlocker, the proxy fetches the tracking image and triggers the tracker at that moment, still telling the tracker your exact opening time. So MailTrackerBlocker's value in that setup is that it stops the image at your machine, at open time, rather than letting it go out later via a proxy.
What the documentation does not describe is a list of what the plugin considers a tracker, how the list is updated, or how matches are reported beyond the blocked-items panel. The block list sources are credited but the maintenance process for them is not documented in the repository README.
The plugin also handles read receipts, which is a separate mechanism from pixel images. The project description lists email trackers, read receipts and spy pixels together as the three things it addresses.
Enabling the plugin after every update is a documented step
Installation is simple, and then the first-run step is the part that trips people up.
The plugin installs either from the releases page as `MailTrackerBlocker.pkg`, or through Homebrew Cask:
$ brew install mailtrackerblockerAfter installation you enable it in Mail, and the documented route depends on your macOS release. On macOS 10.14 and 10.15 you open Mail and go to `Preferences > General > Manage Plug-ins... > check "MailTrackerBlocker.mailbundle" > Apply and Restart Mail`. The documentation notes in the same step that you will need to do this again for each update, which is the single most common source of confusion for people who upgrade the plugin and then find it stopped working.
On macOS 12 and 13 there is no plug-in management step in the instructions. You tap the toolbar button to see what was blocked, and optionally re-enable images from the Mail menu bar under Settings > Privacy by disabling "Block All Remote Content". On macOS 10.11, 10.12, 10.13 and 11 the equivalent re-enable path is under Settings > Viewing, re-enabling "Load remote content in messages". The wording of the setting changed between macOS versions, which is a small but real trap: you will be looking for a differently named toggle depending on your release.
The two troubleshooting entries are also honest about causes outside the plugin. A "Incompatible Plug-ins Disabled" message is typically caused by a Mac migration or a restore from backup, and the fix is to delete Mail's private plug-ins directory, which is regenerated automatically. A slow Mail is stated not to be related to MailTrackerBlocker at all, and the suggested fix is a complete Mailbox Rebuild to force Mail to regenerate its indexes.
The version ceiling is set by Apple, not by the project
The requirement is macOS El Capitan 10.11 through Ventura 13, and the project links to an explanation of why newer versions are not supported. The reason is the removal of legacy Mail plug-ins in macOS Sonoma. Apple dropped the plug-in path that a mailbundle depends on, and there is no way for a plugin to survive that change.
This is worth stating plainly because it changes how you should read the release dates. The tagged versions are 0.8.10 "Salt and Pepper" on 2026-02-11, 0.8.9 "Bread and Butter" on 2025-07-12, and 0.8.6 "Two or More" on 2024-10-26. The last push was on 2026-09-12, so the code is still being worked on, but the addressable platform has not moved forward in years, and the plugin cannot move with it.
That is a different maintenance profile from a typical project. There is no upstream API to keep pace with because the API it depends on was withdrawn, so work on this repository can only go as far as maintaining the 10.11 to 13 line. A user on a current macOS cannot adopt this at all, and a user who upgrades their Mac will eventually lose it.
The practical consequence for anyone evaluating it now is that the useful question is not how often the project is updated but whether your machine is still inside the supported window.
Building from source needs signing identities and a Makefile detour
Building is a Make plus Xcode workflow, and it has one wrinkle that trips up contributors.
The clone step uses a recursive clone, which matters for the `unsign` helper that the Makefile builds:
git clone https://github.com/apparition47/MailTrackerBlocker.git --recursive
cd MailTrackerBlockerThe Makefile builds a binary, a `pkg` and signs them if signing is configured. The `all` target runs `clean`, the `unsigntool` step and the packaging step:
make all
open build/ReleaseSigning is controlled by two variables at the top of the Makefile, `DEVID` for the `Developer ID Installer` certificate used to sign the pkg and `APPID` for the `Developer ID Application` certificate used to sign the plugin binary on macOS 11 and up. The documentation tells you to edit the `Makefile` to use your own identity, and you can comment out the top lines to disable signing entirely. The `unsigntool` target builds the `unsign` helper for `x86_64` and codesigns it with `--options=runtime` when `APPID` is set.
The `pack` target is where the install locations come from. `pkgbuild` installs into `/Library/Application Support/com.onefatgiraffe/mailtrackerblocker` with the identifier `com.onefatgiraffe.mailtrackerblocker`, and `productbuild` turns the unsigned pkg into a signed one with `productsign` when a `DEVID` is present.
The Xcode route needs Full Disk Access for Xcode, because the mailbundle has to be installed into `/Library/Mail/Bundles`. There is also a warning worth repeating: building automatically installs a copy into that directory, so an existing installation from the public pkg installer has to be removed first because of permissions.
Uninstalling means four kinds of leftover state
The uninstall instructions are detailed enough to be worth reading before you install, because they show how many kinds of state the plugin leaves behind.
Homebrew handles the cask case in one step:
$ brew uninstall mailtrackerblockerA manual pkg install leaves five separate categories of residue, and the documented removal covers all of them:
osascript -e "quit app \"Mail\""
# plugin files
sudo rm -r /Library/Mail/Bundles/MailTrackerBlocker.mailbundle
sudo rm -r /Library/Application\ Support/com.onefatgiraffe/mailtrackerblocker
sudo pkgutil --forget com.onefatgiraffe.mailtrackerblocker
# user-generated settings
rm -r ~/Library/Containers/com.apple.mail/Data/Library/Application\ Support/com.onefatgiraffe.mailtrackerblocker
defaults delete com.apple.mail _mtb_IsAutoUpdateCheckAllowed
defaults delete com.apple.mail _mtb_IsFirstStartup
defaults delete com.apple.mail _mtb_LastUpdateCheckDateThe bundle in `/Library/Mail/Bundles`, the support directory in `/Library/Application Support`, the pkg receipt known to `pkgutil`, the per-user container data under `~/Library/Containers/com.apple.mail/Data`, and three Mail defaults keys named with the `_mtb_` prefix all have to go.
Those three defaults keys are the only sign of an update check in the plugin, which implies the plugin can phone home to look for a newer version, and the key name `_mtb_IsAutoUpdateCheckAllowed` suggests that behaviour is user-controllable. The README does not describe where the update check goes or how it is configured, and the project homepage is a separate GitHub Pages site rather than a documented endpoint, so the details are not in the repository.
On licensing, the project is BSD-3-Clause, with the README stating BSD-3 and a `LICENSE` file in the repository. That is a permissive licence with no copyleft obligation, which is a licensing observation rather than legal advice, and the `LICENSE` file governs.
Editorial conclusion
MailTrackerBlocker fits someone on macOS 12 or 13 who still runs Apple Mail, wants to keep remote images switched on for a normal looking inbox, and wants to know which company is watching. It does not fit anyone on macOS 14 or later, because the legacy Mail plugin path the project depends on was dropped there, and it does not fit a user who has already moved to Apple Mail's built-in privacy proxy and is content to lose remote images entirely. Verify first that your macOS version is within the supported 10.11 to 13 range, that Mail's plug-in management screen accepts `MailTrackerBlocker.mailbundle` after an update, and that the blocked-item list shows the trackers you expect on a message you can verify from another client.
Frequently asked questions
Which macOS versions does MailTrackerBlocker support?
The project requires macOS El Capitan 10.11 through Ventura 13 with Apple Mail. The upper bound exists because macOS Sonoma dropped support for legacy Mail plug-ins, which is what a mailbundle depends on.
How do I install MailTrackerBlocker with Homebrew?
Run `brew install mailtrackerblocker`, which installs it as a Homebrew Cask. The plugin can also be installed directly from the `MailTrackerBlocker.pkg` file on the repository releases page.
Do I have to enable the MailTrackerBlocker plug-in again after every update?
On macOS 10.14 and 10.15 the documented steps include checking `MailTrackerBlocker.mailbundle` in Mail's plug-in management screen and applying, and the documentation notes you will need to do this again for each update.
Does MailTrackerBlocker work alongside Mail Privacy Protection?
The project states it works in some network environments, for example over a VPN, where Mail Privacy Protection is not working, as long as you choose to load remote content. It also warns that Apple's proxy still fetches tracker images and triggers them after an unknown delay.
How do I remove MailTrackerBlocker completely on macOS?
Uninstall the cask with `brew uninstall mailtrackerblocker`, or for a manual pkg install remove the bundle, the support directory, the pkg receipt, the per-user container directory and the `_mtb_` Mail defaults keys, as listed in the uninstall commands in the documentation.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/apparition47-mailtrackerblocker)Was this useful?