About MacXTools - The Team Behind the Mac Email Tools

Our story

Why we build Mac email tools

MacXTools started in 2016 writing small utilities for macOS. The requests that kept coming back were never about the small stuff. They were from people holding a PST file on a Mac with no Outlook, or a mailbox on a server about to be shut off, or an OLM archive that no Mac application would read.

Those problems had good answers on Windows and almost none on the Mac. So that became the work, and every tool in the catalogue exists because somebody wrote in stuck.

The people we build for are IT administrators, migration consultants, legal and eDiscovery teams, plus anyone who has been handed a mail file and told to make it readable.

The open plan floor at the MacXTools office — Every tool is written, tested and supported from this one floor.

17 tools, 5 categories

5 File converters
5 Mailbox backup
3 Extractors
3 Repair tools
1 Secure erasure

Between them they read PST, OLM, MBOX, EML, MSG and PDF files. On the account side they sign into Gmail, Google Workspace, Office 365, Yahoo Mail and any IMAP server.

Meet the team

The people writing the code

Small enough that the person who answers your support email is usually the person who wrote the tool. The same people write the guides on this site.

Arjun Nair

Founder and engineering lead

Conversion engine architecture and what gets built next

Priya Venkatesan

File format engineer

PST, OLM and MBOX parsing internals

Divya Krishnan

Quality and release lead

Interface, accessibility and release testing

Inside MacXTools

Where the work happens

One floor in one building. Writing, review, testing and support all happen within earshot of each other, which is the only reason a small team can move this fast.

Developers working at desks on the MacXTools engineering floor — The engineering floor, where every release is written and profiled

A design review session with wireframes on a whiteboard — Interface review

A code review and training session at MacXTools — Code review

The MacXTools team in a product planning meeting — Planning, which is mostly arguing about what not to build

How we work

Four rules we do not bend

These are decisions, not features. They cost us something, which is how you know we mean them.

01

We test on files that are actually broken

Clean sample data proves nothing. Our test set is built from the corrupt, truncated and half migrated files people have sent us over the years, kept with permission and stripped of content.

02

We support old Macs longer than we need to

Plenty of the machines holding an important archive are not new. We keep older hardware on the shelf and keep testing against it, rather than dropping support the month Apple does.

03

Support is answered by the people who build

There is no ticket tier and no outsourced first line. If your file behaves strangely, the reply comes from somebody who can open the source code and look.

04

We say no when a tool is the wrong answer

Sometimes the honest reply is that your file is beyond repair, or that a free route exists. We would rather tell you that than sell you a licence you cannot use.

Behind those four, the mechanics never change. One universal binary covers Apple Silicon and Intel. Each release is code signed under our Apple Developer ID and cleared through Apple notarization. None of it goes near the App Store, because a tool that reads your mailbox needs file access the sandbox will not grant.

Come and see what we made

Seventeen tools for macOS, each with a trial you can run on your own file before deciding. What Mac users say about MacXTools is on record, unedited.

Browse all products Contact the team

The People Behind MacXTools