New — IMAP client access

Plug modern email into legacy software that only speaks IMAP

Your 15-year-old helpdesk doesn't know what a webhook is. That's fine. Point it at imap.mailhooks.dev:993 and it starts receiving mail through the same infrastructure as the rest of your stack.

The thing nobody wants to rewrite

Every serious company has one: the internal tool, open-source helpdesk, or vendor product whose email-import code predates webhooks — and "we'll migrate it later" turned into five years.

Ticketing and helpdesk

osTicket, Request Tracker, Mantis, old Jira Service Desk, Spiceworks

Internal scripts

Python imaplib workers, PHP imap_open() cron jobs, Java Mail apps, Power Automate flows

Compliance and archiving

Barracuda, Proofpoint, Global Relay, custom e-discovery pipelines that ingest via IMAP

Vendor products

Legacy CRMs, DMS like Alfresco or OpenKM, ERPs with "email-to-case" polling, scan-to-mail devices

Before Mailhooks vs after

Before

Rewrite the legacy tool

  • Vendor ticket, internal refactor project, or "let's just migrate everything" JIRA epic
  • Add HTTP receiver, TLS termination, signature validation, retry handling
  • Rebuild SPF/DKIM/DMARC verification logic the old code already has
  • Host and maintain the new endpoint for years alongside the legacy one
After

Change three config fields

  • Host: imap.mailhooks.dev
  • Username: *@yourdomain.com
  • Password: Your Mailhooks API key
  • Modern SPF/DKIM/DMARC, S3 attachments, retention, and search — behind the same IMAP port the legacy tool already knows

Three-line change for Python

If your tool is a Python script using imaplib, this is the diff. That's it.

 - HOST = "mail.example.com"
 + HOST = "imap.mailhooks.dev"
   PORT = 993

 - USER = "[email protected]"
 + USER = "*@yourdomain.com"

 - PASSWORD = os.environ["IMAP_PASSWORD"]
 + PASSWORD = os.environ["MAILHOOKS_API_KEY"]

   with imaplib.IMAP4_SSL(HOST, PORT) as mail:
       mail.login(USER, PASSWORD)
       # ... rest of the script is unchanged

Worked examples for Thunderbird, Node.js, and raw openssl s_client are in the setup guide.

What you get behind the IMAP port

Modern auth checks

SPF, DKIM, and DMARC verification runs on every incoming message. Results are attached to the email metadata.

Per-tool API keys

Mint a dedicated IMAP-only key per downstream system. Rotate without coordinating with the vendor. Keep HTTP API access completely separate.

Retention and search

Your retention policy applies as normal. The same inbox is reachable from IMAP, the HTTP API, the dashboard, and webhooks — one source of truth.

Likely questions

Can I use the same API key for both HTTP and IMAP?

Yes — tick both scopes when creating the key. You can also mint a pure IMAP key that has no HTTP API access at all, which is the least-privilege default we recommend for machine credentials sitting inside legacy software.

Does IMAP support outbound email?

No. Mailhooks is inbound-only. If your legacy tool also needs to send email, keep pointing it at your existing SMTP provider (SendGrid, Postmark, SES, whatever) — Mailhooks only handles the receive side.

What about folders, Sent, Drafts, Trash?

We expose only INBOX. Most "auto-poll an IMAP inbox" tools only look at INBOX anyway. In Thunderbird or Apple Mail, set the special folders to "None" so the client doesn't try to auto-create them.

Is there IDLE / push support?

Not yet. Clients poll. In practice every legacy tool we've tested already runs on a poll schedule so this is rarely the blocker people expect.

How does this compare to pointing the tool at real IMAP?

See IMAP vs Webhooks for the broader tradeoff. The short version: if you were going to pay for hosted IMAP anyway, Mailhooks gives you the same surface plus a modern HTTP API, real-time SSE, webhooks, and full tenant isolation — you pick which delivery methods to use per tool.

Your legacy tool, still running, still happy

No rewrite. No vendor ticket. Just a three-line config change and a better inbox behind it.