Receiving email

Read your inbox over IMAP

MailKite is webhook-first — inbound mail is parsed and POSTed to your endpoint as clean JSON, so most apps never need a mailbox. But sometimes you want to point a standard mail client — Apple Mail, Thunderbird, a phone — or your agent's IMAP library at an address and just read what landed. IMAP is that compatibility layer: the same inbox, reachable by any client, without giving up the webhook.

Connection details

Drop these into any mail client's IMAP settings. Your password is a scoped IMAP app-password (mk_imap_…) — not your API key — that you create in the dashboard and can revoke anytime.

Host	`imap.mailkite.dev`
Port	`993` (implicit TLS / IMAPS)
Encryption	SSL/TLS, required. There is no plaintext 143 — the connection is encrypted from the first byte.
Username	Your email address on a verified domain (e.g. `you@yourdomain.com`). Any username authenticates — we key on the app-password.
Password	An IMAP app-password (`mk_imap_…`) — create one under Settings → IMAP in the dashboard.
Folders	`INBOX` (mail you received) and `Sent` (mail you sent through MailKite).

Create an app-password

In the dashboard, open Settings → IMAP and click New app-password. Give it a label (e.g. "Thunderbird on my laptop"), and copy the secret — it's shown once. Paste it as the password in your mail client. Each client gets its own app-password, so you can revoke one without touching the others, and you'll see each one's last-used time.

Who can use it

IMAP is available on domains that retain inbound mail:

Verified domains — the domain must pass inbound (MX) DNS verification; that's the same gate as receiving webhooks.
Not zero-retention — passthrough (zero-retention) domains store nothing, so there's no mailbox to read. IMAP is off for them by design.
Encrypted domains — IMAP serves the encrypted message and your mail client decrypts it with your private key (PGP/MIME or S/MIME). This is rolling out; encrypted-domain IMAP isn't live for every client yet.

Set up a mail client

Thunderbird — Account Settings → Account Actions → Add Mail Account. Enter your name and your you@yourdomain.com address; for the password use your app-password. When it offers config, set IMAP, server imap.mailkite.dev, port 993, SSL/TLS, and "Normal password" authentication.

Apple Mail (macOS/iOS) — Add Account → Other Mail Account. Use your address and the app-password; when asked, set the Incoming Mail Server to imap.mailkite.dev. Mail fills in IMAPS (993) automatically.

Read an agent's inbox in code

The AI-agent ecosystem already speaks IMAP. Give an agent its own inbox and let it pull and search history — or let a human supervise that inbox from a normal mail client. Here's the read loop with Python's standard imaplib:

read unseen mail · Python imaplib

import imaplib, email

M = imaplib.IMAP4_SSL("imap.mailkite.dev", 993)
M.login("agent@yourdomain.com", "mk_imap_…")  # your IMAP app-password
M.select("INBOX")

typ, data = M.search(None, "UNSEEN")
for num in data[0].split():
    typ, raw = M.fetch(num, "(RFC822)")
    msg = email.message_from_bytes(raw[0][1])
    print(msg["From"], "—", msg["Subject"])
M.logout()

What works today

v1 is read-focused. You can list, open, search, and flag mail (read / unread / flagged), and those flags persist across clients. A few things to know:

Two folders. INBOX is everything you received; Sent is everything you sent through MailKite. There are no custom folders yet.
Read-mostly. Reading, searching, and flagging work; moving, deleting, and uploading messages are not enabled yet (a client trying to delete won't break — the change just doesn't stick).
New mail. Clients refresh on reconnect or refresh; live push (IDLE) is limited in v1.
Webhooks stay primary. IMAP is a read window onto the same mail — it doesn't replace the webhook, retries, or the Messages API.

Test the connection

Confirm reachability and your app-password from a terminal:

test with openssl s_client

openssl s_client -connect imap.mailkite.dev:993 -crlf
# then, at the prompt:
a LOGIN you@yourdomain.com mk_imap_your_app_password
a SELECT INBOX
a LOGOUT

IMAP or webhooks?

Reach for IMAP when…	Reach for webhooks + the API when…
A human needs to read or supervise an inbox in a normal mail client	You're building something that should react to mail the moment it lands
A legacy app or an agent's IMAP library expects a mailbox to poll	You want clean JSON — body, headers, attachments — pushed to your endpoint
You want portability — point any standard client at your address	You want retries, signatures, idempotency, and typed responses

Same inbox, same account: use webhooks for automation and IMAP for the human (or the agent) — or both at once. Nothing to migrate.

Troubleshooting

Authentication failed — the password must be an mk_imap_… app-password (not your API key). Create or revoke them under Settings → IMAP.
No mailbox / login rejected — the domain must be MX-verified and not on zero-retention. Passthrough domains store nothing to read.
Can't connect — use port 993 with SSL/TLS. There is no plaintext (143) port.

Prefer to react to mail instead of poll it? Inbound webhooks are MailKite's core — IMAP just gives the same inbox a second, standard front door.