If Storage Settings shows a "Mail" category that keeps growing and you're not sure why, the answer is almost always attachments. Apple Mail keeps a local copy of every message you've downloaded, plus a search index, under ~/Library/Mail, organised into one subfolder per account. Every PDF a colleague sent you in 2021, every video a relative forwarded, every screenshot from a support thread — if Mail downloaded it, it's sitting on your disk right now, whether or not you ever opened it again. On an account you've used for a few years, this routinely adds up to several gigabytes, and on an account that receives a lot of media it can be much more. The fix is straightforward, but it needs to happen inside Mail itself, not by poking around in the folder directly.

Where the space actually goes

Open ~/Library/Mail in Finder (you may need Go → Go to Folder since Library is hidden by default) and you'll see a folder per account, named after an internal identifier rather than your email address. Inside each one, Mail keeps the message bodies, a local attachment store, and an Envelope Index — the SQLite database that Mail uses to know what belongs where. None of this is meant to be read or edited by hand. It's an internal format that changes between macOS versions, and Mail expects to be the only thing that writes to it.

You can safely check how large the whole thing has grown with a single command:

du -sh ~/Library/Mail

If that number is bigger than you expected, attachments are almost certainly the reason. Mail doesn't compress or dedupe them, and by default it downloads attachments automatically as messages arrive, so the total only ever goes up unless you intervene.

IMAP versus POP: why the safe answer is different

This distinction matters more than most guides let on.

If your account is IMAP (which covers Gmail, iCloud Mail, Outlook.com, and most modern providers), the message and its attachment still exist on the mail server after you delete the local copy. Mail re-downloads the message body and attachment on demand the next time you open it, as long as you have a network connection. Deleting the local cache for an IMAP account is low-risk: worst case, opening an old message later takes a few seconds longer while it re-fetches.

If your account is POP, be more careful. POP was designed around the idea that the client downloads mail and the server copy is often deleted afterwards, depending on how the account is configured. If the server copy is gone, the file sitting in ~/Library/Mail may be the only copy of that attachment that exists anywhere. Before you delete anything from a POP account, check your account settings to see whether messages are retained on the server, and if you're not sure, treat every attachment as irreplaceable until proven otherwise.

The right way to remove a large attachment

Don't go into ~/Library/Mail and start deleting files or folders. The Envelope Index tracks exactly what's supposed to be there, and removing a file underneath it can leave Mail with a broken reference — a message that shows an attachment icon Mail can no longer open, or worse, indexing problems that make search unreliable. Recovering from that usually means rebuilding the mailbox from scratch.

Instead, work from within Mail:

  1. Use Mail's search to find large attachments — search by sender or subject if you remember roughly what you're looking for, since Mail doesn't have a built-in "sort by attachment size" view.
  2. Open the message, and if you want to keep the file, drag the attachment to a folder on disk (or File → Save Attachments) before doing anything else.
  3. With the file saved wherever you actually want it, you can either delete the whole message (if you don't need the email itself) or, in recent versions of Mail, remove just the attachment while keeping the message text.
  4. Empty Mail's own Trash mailbox afterwards — deleting a message moves it to Trash first, and it still occupies space in ~/Library/Mail until that's emptied.

This keeps Mail's internal bookkeeping consistent, because Mail is the one making the change, not you working around it.

Stopping it from re-accumulating

Removing old attachments once buys you space today, but if Mail keeps downloading everything automatically, you'll be back here in a year. Check Mail → Settings → Accounts, select an account, and look at its Download Attachments setting. Depending on your macOS version this is phrased as a choice between downloading attachments automatically or only when you open them. Setting it to download on demand means large files stay on the server until you actually need to view or save them, which is usually the better default for an account you use mostly for text.

This setting is per-account, so if you have a personal account you rarely touch and a work account you're in constantly, it's worth checking both rather than assuming one setting covers everything.

What a storage tool can and can't tell you here

~/Library/Mail is a protected location on modern macOS — reading inside it requires Full Disk Access, which is a deliberate barrier Apple put in place because it's exactly the kind of folder that shouldn't be casually scanned by arbitrary software. Any storage tool that shows you a size for "Mail" without that permission is either asking macOS's Storage Settings for the number, or it simply can't see inside and should say so honestly rather than reporting zero.

Conclusion

The pattern here isn't unique to Mail. Anywhere an app keeps its own database alongside the files it manages, the safe move is to make changes through the app, not around it. ~/Library/Mail will keep growing as long as you keep receiving attachments, and that's fine — the cost of storage is real but manageable once you know where to look and which button actually frees it.

We built VolumeLens because we needed a storage map that tells you the truth about what it can and can't see, including protected folders like ~/Library/Mail. Rather than guessing or silently reporting zero, it labels folders macOS refused to let it read, so you know when a number is incomplete instead of assuming it's accurate. You can see exactly how that works, and everything else it maps on your Mac, on the features page.