When we set out to build MailFlow we had a choice: integrate with Google's Gmail API and Microsoft's Graph API, or send and receive over the protocols that have been working since 1982. We picked the protocols. Here's why.
The CASA tax
To use restricted Gmail scopes — anything that touches the inbox like gmail.modify or gmail.readonly — Google requires every app to pass a yearly CASA security assessment. The cheapest tier is around $500. The more thorough tier ranges to $2,500 or more. Plus engineering time. Plus penetration testing. Plus annual re-verification.
And until you pass it, you are capped at 100 unverified test users. Forever. That is the wall every new outreach SaaS hits at exactly the wrong moment — when it starts to find product-market fit.
The 100-user cliff
We talked to half a dozen founders running outreach tools at $30k–$300k MRR. Every single one of them either paid the CASA fee, planned to pay it within months, or had user growth artificially throttled by it. None of them said it was money well spent. It was simply the toll booth they were forced to walk through.
What you actually need from an inbox
Cold email outreach needs four things from an email account:
- Send a message (with proper Message-ID, threading headers, signed DKIM).
- Receive replies and bounces.
- Search the inbox for specific messages (warmup needs to find the message it just sent so it can move it from spam to inbox).
- Move and flag messages (warmup again — IMAP MOVE, IMAP STORE +FLAGS).
All four of those operations have been part of the SMTP and IMAP RFCs for decades. The Gmail API exists to wrap them in a Google-flavored coat. The wrapping is convenient if you build a Gmail-only consumer product. For an outreach tool that needs to support Gmail, Workspace, Outlook, Microsoft 365, Zoho, Yahoo, Proton, FastMail and twenty self-hosted setups, the wrapping is just lock-in.
The App Password path
Every consumer-grade mail provider that supports 2-step verification supports App Passwords. The user creates one in their account settings, pastes it into MailFlow, and we store it encrypted with AES-256-GCM. From there, all sending happens over SMTP and all inbox operations happen over IMAP. The same code path works for Gmail and self-hosted Postfix and ProtonMail Bridge.
The user can revoke the App Password at any time, in their own provider's dashboard, without ever touching MailFlow. There's no OAuth refresh token to rotate. No Google verification to renew. No cap on how many of them we can serve.
What we lose
Not much, honestly:
- Gmail Push Notifications — we approximate this with persistent IMAP IDLE connections, which deliver new mail in 0–60 seconds.
- Programmatic Gmail filter management — niche feature, low demand. Easily replaced by a manual filter in the user's Gmail.
- Some advanced metadata like
X-Gm-MsgId— replaceable with standardMessage-IDthreading.
What we gain
- $0 in CASA fees, forever.
- No 100-user cap.
- One implementation that works for any RFC-compliant mail server.
- The user retains full control of their own credentials.
- Faster onboarding — a 60-second setup beats a multi-screen OAuth consent flow.
The IMAP IDLE bet
The trickiest piece operationally is keeping persistent IMAP IDLE connections alive at scale. At 10,000 connected accounts you are sitting on 10,000 long-lived TCP sockets. You need per-process connection pools, exponential backoff on reconnect, periodic NOOP health checks and 29-minute IDLE refreshes per RFC 2177. Worth it.
If you're building anything that talks to user mailboxes, ask yourself: are you wrapping a decades-old protocol with a vendor SDK, or just speaking the protocol directly? In our experience the second path scales further with less infrastructure and zero permission drama.