The current MCP ecosystem skews toward two flavors: hosted SaaS bridges that proxy your credentials through a vendor, or first-party-only servers that lock you to whatever provider built them (Gmail-only, Outlook-only). If you want Claude Code to talk to your inbox without handing your password to a middleman, your options are narrower than they should be.
This piece is about what changes if you go self-hosted, what "self-hosted" actually means in this context, and what's realistic to expect from a server that promises "any IMAP provider."
What "self-hosted" means here
Self-hosted, in the MCP-for-email context, comes down to:
- Your IMAP and SMTP credentials live on a machine you control (laptop, home server, VPS — your choice)
- The MCP server reads those credentials from a local
.env, opens TLS connections directly to your mail provider, and serves tool calls to Claude Code over stdio or HTTP - No third party sees the credentials, the messages, or even the metadata of what tools are being called
The contrast is with hosted bridges, where you OAuth into a SaaS that then connects to your provider on your behalf. Hosted bridges are easier to set up. They're also one breach away from a credential dump.
For most personal use, the convenience tradeoff is fine. For a custom domain where Claude is going to draft replies that go out under your name, I'd want the credentials to never leave my machine. That's a values call, not a security recommendation. Make it deliberately.
"Any IMAP provider" — what's actually true
IMAP is a 1986 protocol that's been ported to every mail server in existence. SMTP is even older. In theory, an MCP server that speaks IMAP and SMTP works with every provider.
In practice, "any IMAP provider" runs into three classes of compatibility issues.
Class 1: authentication
Most providers gave up on plain passwords years ago. To connect via IMAP today you typically need either OAuth2 (which is annoying to set up in a self-hosted context, especially for shared apps) or an app password (which is just a long random string the provider gives you specifically for IMAP/SMTP).
The providers that make app passwords easy:
- Gmail (enable 2FA, then
myaccount.google.com/apppasswords) - Fastmail (settings → privacy & security → app passwords)
- iCloud (sign-in and security → app-specific passwords)
- Outlook 365 (Microsoft security portal)
- Hostinger and most custom-domain providers (account settings → mail passwords)
The providers that don't:
- Proton Mail: their security model is end-to-end encrypted, so direct IMAP isn't available. You need Proton Bridge, which runs locally and exposes a bridge IMAP/SMTP server at
127.0.0.1. Once Bridge is running, the MCP server treats it like any other provider. - Yahoo: app passwords still work but require enabling "less secure apps," and the IMAP server has occasionally been flaky in my testing.
Class 2: server idiosyncrasies
Even when authentication works, IMAP servers diverge on the boring details. Gmail's "All Mail" folder shows up as [Gmail]/All Mail with a bracket. Outlook 365 uses Sent Items (capital S, space). Fastmail uses Sent. Proton via Bridge uses Sent lowercase in some versions.
A good MCP server normalizes this with a folder mapping layer so that when Claude asks for "sent items," the server knows which folder name to use for which account.
Class 3: rate limits
Gmail's IMAP rate limits are aggressive. Fetching a hundred large attachments in a tight loop will trip them within minutes. The server has to back off and retry. If it doesn't, you'll spend more time debugging "why does this fail intermittently" than actually using the thing.
What I tested
I'm the maker of mcp-email, so the matrix below is the one I've personally validated. Treat it as a non-exhaustive list of providers known to work with a self-hosted MCP server that speaks plain IMAP + SMTP.
| Provider | Auth | IMAP host | SMTP host | Notes |
|---|---|---|---|---|
| Gmail | app password | imap.gmail.com:993 |
smtp.gmail.com:465 |
enable 2FA first |
| Fastmail | app password | imap.fastmail.com:993 |
smtp.fastmail.com:465 |
clean implementation, no surprises |
| Proton via Bridge | Bridge password | 127.0.0.1:1143 |
127.0.0.1:1025 |
needs Bridge running |
| iCloud | app password | imap.mail.me.com:993 |
smtp.mail.me.com:587 |
DKIM signing on by default |
| Outlook 365 | app password | outlook.office365.com:993 |
smtp.office365.com:587 |
sent folder named Sent Items |
| Hostinger | mailbox password | imap.hostinger.com:993 |
smtp.hostinger.com:465 |
what I use for hello@oneshotforge.com |
| Yahoo | app password | imap.mail.yahoo.com:993 |
smtp.mail.yahoo.com:465 |
enable "less secure apps" |
| Zoho | app password | imap.zoho.com:993 |
smtp.zoho.com:465 |
clean |
| Generic IMAP | depends | depends | depends | works if the server is RFC-compliant |
A working mcp-email setup with all of these in parallel is what "multi-account" means in practice. One .env file, one server instance, and Claude's tool calls route to the right backend based on the account argument.
Why this matters for your stack
If you're going to give Claude inbox access at all, the question is whether you're comfortable with the credential model. There are three real options:
- OAuth into a hosted SaaS bridge. Convenient, fast to set up, vendor sees your inbox. Fine for personal email if you trust the vendor.
- OAuth with a self-hosted server you trust. Best security, hardest to set up. Useful if you're integrating into a company stack with compliance constraints.
- App passwords plus a self-hosted server. Middle ground. App passwords are revokable, scoped to mail only, and never leave your machine. This is what I use.
Most people I've talked to land on option 3 not because they thought through the threat model but because app passwords are simple to revoke and the tooling just works. Reasonable default either way.
Deliverability is the other half
Reading mail is easy. Sending mail that doesn't land in spam is hard.
The three records that matter are SPF (which IPs are allowed to send for your domain), DKIM (the cryptographic signature on outgoing mail), and DMARC (what receivers should do when SPF or DKIM fail).
Most providers configure these automatically for their default *@gmail.com-style addresses. If you're using a custom domain, you need to add the records yourself, and the order matters: SPF first, DKIM after Hostinger/Mailgun/whoever generates the key, DMARC last (start with p=none to monitor, move to p=quarantine once SPF and DKIM pass consistently).
mail-tester.com will tell you exactly which records are passing and which are missing. I aim for 10/10 before letting the server send anything important. hello@oneshotforge.com scores 10/10 on Hostinger's stack as of this writing.
Closing
Self-hosted MCP for email is a small puzzle (credentials, server, deliverability) that takes about an hour to assemble. After that, it disappears into the background and Claude Code just has inbox access the same way it has filesystem access.
If you want to skip the build phase, mcp-email does this exact assembly out of the box with the matrix above pre-validated.
mcp-email is distributed as a paid product. After checkout on https://shop.oneshotforge.com/l/mcp-email you get the full TypeScript source code, the Docker compose setup, the per-provider config docs, and a perpetual commercial license. The whole thing fits in a single zip. The README walks you through your first .mcp.json entry in Claude Code.