# MailKite

> Inbound-first email for developers: receive email as a webhook, send with one API, skip the mail server entirely. Unlimited free domains, graceful overage, human support, and (roadmap) open-source webmail.

## Start here

- [Docs](https://mailkite.dev/docs): Quickstart, SDKs, the REST API, webhooks, and MCP.
- [API reference](https://mailkite.dev/api): Every endpoint by group — request/response shapes with fetchable JSON Schemas.
- [Better Auth email](https://mailkite.dev/docs/auth/better-auth): Send Better Auth's magic links, OTPs, verification, password resets and org invites via `npm i @mailkite/better-auth` — a real Better Auth plugin, no schema and no migration.
- [Better Auth inbox](https://mailkite.dev/docs/auth/better-auth-inbox): Give a Better Auth app a real mailbox via `npm i @mailkite/better-auth-inbox` — receive email as signature-verified webhooks, then list, read and reply through session-scoped endpoints, per user or per organization. Every other Better Auth email surface is outbound; no auth library offers this.
- [Receive email as a webhook](https://mailkite.dev/#receive): Inbound email parsed to clean JSON, POSTed to your endpoint.
- [Send with one API](https://mailkite.dev/#send): Transactional send over REST, SDK, or SMTP relay.
- [For AI agents](https://mailkite.dev/agents): Give an agent its own inbox — sign-ups, 2FA, replies — wired via MCP.
- [Pricing](https://mailkite.dev/pricing): Unlimited free domains; graceful overage, never a hard cut.
- [Alternatives](https://mailkite.dev/alternatives): Side-by-side vs Amazon SES, SendGrid, Mailgun, Cloudflare Email, AgentMail.
- [Tools directory](https://mailkite.dev/tools): Curated email & agent tools — platforms, inbound, MCP, deliverability, testing, OSS servers.
- [Integrations](https://mailkite.dev/integrations): MailKite works with everything — SDKs, frameworks, MCP clients, and SMTP-ready platforms.
- [Email tools & platforms](https://mailkite.dev/email-tools): Software email connects to — Shopify, WordPress, Salesforce, Zendesk, Laravel, Slack, Stripe.

## Field notes (blog)

- [23 open source email servers for Linux, sorted by the job each one does](https://mailkite.dev/blog/open-source-email-servers-linux/): Most "best open source mail server" lists put a full-stack Docker bundle and a single SMTP daemon in the same ranked table, as if you'd choose between them. You wouldn't. This is 23 Linux mail projects grouped by the slot they fill in the mail path, with licenses, languages, and activity verified on 2026-08-05, plus the part every roundup skips: what self-hosting still costs you after the install script says done.
- [Mautic email deliverability: replace SMTP with the Symfony Mailer DSN transport](https://mailkite.dev/blog/mautic-email-mailkite-symfony-transport/): Mautic 5 runs on Symfony Mailer, not SwiftMailer — which means it can take a native mailkite+api:// DSN instead of generic SMTP. This tutorial covers the install, the DSN config, and why campaign-send errors are more useful than an SMTP rejection code.
- [One DSN, three PHP ecosystems: MailKite's Symfony Mailer transport](https://mailkite.dev/blog/symfony-mailer-transport/): mailkite/symfony-mailer resolves a mailkite+api:// DSN into a first-party Symfony Mailer transport — which means Mautic, PrestaShop, Drupal, and any plain Symfony app all get it from one package, with honest errors instead of a generic SMTP rejection.
- [MailKite now ships a native mailer for six more frameworks](https://mailkite.dev/blog/mailkite-native-mailers-six-frameworks/): MailKite shipped native mail integrations for Spring Boot, ASP.NET Core, Next.js, NestJS, Flask, and FastAPI in one day — three new packages, two verified starters with no new code, and two real bugs found in already-published packages along the way.
- [Email to Slack: threading, Block Kit limits, and the duplicate-post trap](https://mailkite.dev/blog/inbound-email-to-slack/): Slack's own email-to-channel needs a paid plan, pins every message to one fixed channel, and can't thread. Wiring inbound email to Slack yourself is about 50 lines — but three things bite once real mail arrives: Slack rejects any header block over 150 characters, webhook retries post the same email twice, and Incoming Webhooks never return a message ts, so an email thread can never become a Slack thread. Here's the handler that survives all three, and the return path that lets your team reply to the customer from inside the Slack thread.
- [MailKite Server: our SMTP + IMAP edges are now open source](https://mailkite.dev/blog/mailkite-server-open-source/): The Haraka-based MX and submission edges and the IMAP server that power MailKite are now AGPL on GitHub — self-host the whole stack, point our hosted MX at your box, or connect the same web console to MailKite Cloud.
- [The Unfair Advantage of Using Agents for Email](https://mailkite.dev/blog/unfair-advantage-agent-email/): AI agents can send email. Most can't receive it. Here's what happens when you give an agent its own inbox — the Lethal Trifecta of security risks (untrusted content × sensitive data × external communication), how scoped access and reply tokens solve it, and how MailKite, which we build, wires it together.
- [Build software that heals itself in the agentic era](https://mailkite.dev/blog/self-healing-software-agentic-era/): An AI agent can write the fix now; the hard part is architecting your software so letting one patch production isn't reckless. Here's a design pattern for self-healing systems: never crash, turn every failure into a structured anonymous signature, and let an agent close the loop behind a sandbox and adversarial gates. Our open-source MIME parser is the worked example; the pattern applies far beyond it.
- [Drupal email that works: replace PHP mail() with proper SMTP](https://mailkite.dev/blog/drupal-smtp-mailkite-email/): Drupal uses PHP's mail() function by default — the same broken path that sinks WordPress email in spam. This tutorial shows how to install the SMTP Authentication module, configure it for MailKite's SMTP relay, and route all Drupal site email through your DKIM-signed domain. Password resets, contact forms, content notifications — all deliverable.
- [HubSpot transactional email: route it through your own domain with MailKite](https://mailkite.dev/blog/hubspot-transactional-email-domain/): HubSpot's transactional email uses its own SMTP infrastructure — your emails come from HubSpot's domain, not yours. This tutorial shows how to switch to MailKite's SMTP relay so every transactional email is DKIM-signed from your domain, with full deliverability control and CRM activity logging for inbound replies.
- [Laravel email configuration: two lines that determine inbox or spam](https://mailkite.dev/blog/laravel-smtp-mailkite-configuration/): Laravel's mail config is two environment variables. But those two lines determine whether your transactional email lands in the inbox or spam folder. This tutorial shows how to configure Laravel to send through MailKite's SMTP relay: .env setup, Mailable classes, queue configuration, and inbound webhook handling.
- [Build email automation in n8n that actually works](https://mailkite.dev/blog/n8n-email-automation-webhook/): n8n's built-in email nodes use basic SMTP or IMAP polling — slow, unreliable, and no structured data. This tutorial shows how to connect n8n to MailKite for both sending (SMTP node with DKIM signing) and receiving (webhook trigger with clean JSON payload), so your email automation workflows fire in seconds, not minutes.
- [Salesforce email relay: send from your own domain with MailKite](https://mailkite.dev/blog/salesforce-email-relay-custom-domain/): Salesforce's default email relay sends from its own infrastructure — your customers see Salesforce's DKIM signature, not yours. This tutorial shows how to configure Salesforce's Email Relay to use MailKite's SMTP server, so every outbound email is DKIM-signed from your domain, plus how to receive inbound email as Salesforce Cases.
- [Take control of Shopify email: send order notifications from your own domain](https://mailkite.dev/blog/shopify-email-own-domain-deliverability/): Shopify owns your transactional email. You can't change the SMTP settings, you can't sign with your own DKIM key, and your order confirmations come from shopify.com. This tutorial shows how to send Shopify order emails through MailKite's SMTP relay — DKIM-signed from your domain, with full deliverability control.
- [WooCommerce order emails: fix deliverability with MailKite SMTP](https://mailkite.dev/blog/woocommerce-order-emails-deliverability/): WooCommerce sends 12+ email types through WordPress's wp_mail() — and most store owners have no idea they're going to spam. This tutorial shows how to route every WooCommerce email through MailKite's SMTP relay: order confirmations, shipping notifications, refund emails, all DKIM-signed from your own domain.
- [Fix WordPress email deliverability: replace PHP mail() with MailKite SMTP](https://mailkite.dev/blog/wordpress-email-deliverability-fix-php-mail/): WordPress uses PHP mail() by default — and most of it goes straight to spam. This tutorial shows how to route WordPress email through MailKite's SMTP relay in 10 minutes: password resets, contact form notifications, WooCommerce order emails, all DKIM-signed from your own domain.
- [Zendesk email from your own brand, not Zendesk's](https://mailkite.dev/blog/zendesk-support-email-custom-domain/): Zendesk sends support emails from its own mail servers — your customers see Zendesk's DKIM signature, not yours. This tutorial shows how to route Zendesk outbound through MailKite's SMTP relay, so every ticket notification, auto-reply, and agent response comes from your DKIM-signed domain. Plus: receive inbound replies and add them to tickets automatically.
- [Turn inbound email into Zapier workflows — no code, no polling](https://mailkite.dev/blog/zapier-inbound-email-webhook-workflows/): Zapier's email triggers poll an inbox over IMAP — slow, flaky, and broken for high-volume. MailKite pushes inbound email to a Zapier webhook as clean JSON the moment it arrives. This tutorial shows how to set up the webhook trigger, connect it to 5,000+ apps, and build email automation that actually works in real time.
- [Email parser API: parse inbound email to JSON with a webhook](https://mailkite.dev/blog/email-parser-api/): An email parser API that turns inbound email into structured JSON — no templates, no IMAP, no MIME parsing. Point your MX at MailKite and get a signed webhook with the full message payload.
- [You can't prompt your way out of prompt injection](https://mailkite.dev/blog/agent-inbox-security-by-design/): You can't out-write prompt injection with a better system prompt. The fix is architectural: assume the inbox agent is already hijacked and bound what a fooled agent can do. How MailKite's inbox agent is ACL-gated by design, RLS versus a single app-layer choke point, and the limit ACLs can't cover: you can't authenticate who sent an email.
- [You can't ship an API key in a one-click deploy template](https://mailkite.dev/blog/deploy-template-api-key-problem/): A one-click deploy template that shows account data has a problem no tutorial mentions: it lives on a public URL, so it can't hold a shared API key without handing every visitor the whole account. Here's how we shipped an inbound-email inbox to the Railway marketplace as one deploy: the OAuth self-registration that replaces the key, one core that runs on six hosts, and a Connect button that wires the webhook for you.
- [Parse inbound email to JSON in Node.js](https://mailkite.dev/blog/parse-inbound-email-to-json-node/): Receive email as a webhook in Node.js: set up MailKite, verify the HMAC signature, parse the JSON payload, and handle attachments. Complete tutorial with working Express code.
- [Receive email as a webhook in Python](https://mailkite.dev/blog/receive-email-in-python/): Build a Python webhook handler that receives inbound email from MailKite: Flask setup, HMAC signature verification, JSON payload parsing, and attachment handling. Complete tutorial.
- [The AgentMail alternative for AI agents](https://mailkite.dev/blog/agentmail-for-ai-agents/): AgentMail is a purpose-built, well-funded email provider for AI agents: create an inbox over an API, receive by webhook, WebSocket, or poll, and let the agent read verification codes and reply. MailKite (which we build) gives an agent its own inbox too, on a domain you own with no per-inbox cap, as one capability of general email infrastructure. For developers deciding between a dedicated agent-inbox tool and an email platform that also gives agents inboxes.
- [The Amazon SES alternative for AI agents](https://mailkite.dev/blog/amazon-ses-for-ai-agents/): Amazon SES can send and receive, but it hands an autonomous agent a human-reviewed sandbox before it can email anyone and raw MIME in an S3 bucket before it can read a reply. MailKite (which we build) gives the agent a real inbox: inbound arrives as parsed JSON and a receive→think→reply loop runs with no pipeline to operate. For developers wiring an agent to email.
- [The Brevo alternative for AI agents](https://mailkite.dev/blog/brevo-for-ai-agents/): Brevo (formerly Sendinblue) is a marketing platform with a transactional API, and it can receive: Inbound Parsing POSTs email as an items[] array. But there's no normalized SPF/DKIM/DMARC verdict and no agent loop, so you rebuild both. MailKite (which we build) hands an autonomous agent a real inbox as one parsed email.received event with an auth block and a receive→reply loop.
- [The Cloudflare Email Routing alternative for AI agents](https://mailkite.dev/blog/cloudflare-email-routing-for-ai-agents/): Cloudflare Email Routing is free inbound forwarding and Email Workers hand your agent the raw MIME stream: great plumbing if you're all-in on Cloudflare and happy to parse MIME, derive trust, and wire the reply constraints yourself. MailKite (which we build) hands an agent parsed JSON with an auth verdict and a receive→reply loop in a few lines. For anyone giving an autonomous agent its own inbox.
- [The Elastic Email alternative for AI agents](https://mailkite.dev/blog/elastic-email-for-ai-agents/): Elastic Email is one of the cheapest ways to send, and it can receive: Inbound Routing points your MX at it and POSTs parsed fields to a URL. But the payload is form params with no SPF/DKIM/DMARC verdict, it's gated behind the paid Pro plan, and there's no agent loop. MailKite (which we build) hands an autonomous agent a real inbox as one signed email.received event with an auth block and a receive→reply loop.
- [Email inboxes for AI agents: the complete guide](https://mailkite.dev/blog/email-inbox-for-ai-agents-guide/): Why an autonomous agent needs a real inbox — to receive verification codes, hold email threads, and act as a participant instead of a script. The two architectures (bring-your-own loop vs. managed runs), an honest look at AgentMail, InboxAPI, Atomic Mail, and Postmark, and how MailKite gives every agent a real address on a domain you control, free.
- [Email to webhook: the complete guide to receiving email as JSON](https://mailkite.dev/blog/email-to-webhook-the-complete-guide/): Point your domain's MX at MailKite and every message becomes a signed JSON POST to your endpoint — no mail server, no IMAP polling, no MIME parsing. The full payload shape, signature verification, working receivers in Node, Python, Go, and PHP, and how it compares to SendGrid Inbound Parse, Mailgun Routes, and Postmark.
- [Email as an agent tool: MCP, the SDK, or your own webhook](https://mailkite.dev/blog/email-as-an-agent-tool-mcp-sdk-webhook/): There are three ways to give an agent email, and they answer different questions. Install the MCP server and the model sends and reads mail as tool calls it decides to make. Hand it the SDK and email is deterministic code your agent runs. Point a signed webhook at it and the agent receives mail the moment it arrives. This is when to use each — with runnable code for all three, and how to mix them. For developers wiring an agent to email with MailKite.
- [The Gmail API alternative for AI agents](https://mailkite.dev/blog/gmail-api-for-ai-agents/): A Gmail account plus the Gmail API is the go-to 'give my agent an inbox' hack: free, familiar, and fine for one human-supervised assistant. Productionize an autonomous agent on it and you inherit OAuth restricted-scope review, Pub/Sub watch renewals, and base64url MIME. MailKite (which we build) gives the agent its own scoped address and parsed JSON push. For developers wiring an autonomous email agent.
- [The Loops alternative for AI agents](https://mailkite.dev/blog/loops-for-ai-agents/): Loops is a genuinely nice product-email tool for SaaS: a visual editor, lifecycle loops, and free transactional sends. But it's send-only — it gives an autonomous agent no inbox, so the agent can't read the verification code or the reply it's waiting on. MailKite (which we build) gives the agent a real address that arrives as parsed JSON with a receive→reply loop. For developers wiring an agent that has to read its own mail.
- [The MailerSend alternative for AI agents](https://mailkite.dev/blog/mailersend-for-ai-agents/): MailerSend (by MailerLite) is a developer-friendly transactional service, and its Inbound Routing genuinely receives mail as parsed JSON. For an autonomous agent the gaps are narrower than usual: you compose the trust decision yourself from spf_check and dkim_check (no DMARC, no spam verdict), and there's no built-in agent loop. MailKite, which we build, hands you a normalized auth verdict and a receive→reply loop on a domain you own. For developers giving an agent its own inbox.
- [The Mailgun alternative for AI agents](https://mailkite.dev/blog/mailgun-for-ai-agents/): Mailgun does receive inbound, but through Routes — a filter-expression rule engine you author and maintain — and the message lands as application/x-www-form-urlencoded fields you decode and verify yourself, not clean JSON. MailKite (which we build) gives an agent a real scoped inbox that arrives as parsed JSON with a receive→reply loop. For developers wiring an autonomous agent to email.
- [The Mailjet alternative for AI agents](https://mailkite.dev/blog/mailjet-for-ai-agents/): Mailjet (a Sinch company) can receive inbound mail through its Parse API, but you create the parseroute by hand, map its own field names, and there's no single trust verdict for the body. MailKite (which we build) gives an agent a real inbox: parsed JSON with an spf/dkim/dmarc block and a receive→reply loop. For developers wiring an autonomous email agent.
- [The Mailchimp Transactional (Mandrill) alternative for AI agents](https://mailkite.dev/blog/mandrill-for-ai-agents/): Mandrill can receive email, but it's gated behind a paid Mailchimp marketing plan and hands you inbound as a batched mandrill_events array with no auth verdict and no agent loop. MailKite (which we build) gives an agent a real scoped inbox delivered as one parsed JSON event with a receive→reply loop. For developers wiring an autonomous agent to an inbox.
- [The Microsoft Graph (Outlook) alternative for AI agents](https://mailkite.dev/blog/microsoft-graph-for-ai-agents/): Microsoft Graph gives an agent a real Outlook mailbox, at the cost of an Entra app registration, admin-consented (tenant-wide) mail permissions, and push subscriptions that expire and need renewing. MailKite (which we build) gives the agent its own scoped address on a domain you control and pushes parsed JSON to a receive→reply loop. For builders wiring an autonomous email agent.
- [The Nylas alternative for AI agents](https://mailkite.dev/blog/nylas-for-ai-agents/): Nylas connects an agent to a human's existing Gmail or Outlook over OAuth, which is the right tool when the agent must act inside a real person's mailbox. Production means your own verified OAuth app, a CASA security review, token refresh, and a reply that goes out as the connected human. MailKite (which we build) gives the agent its own scoped address on a domain you control and pushes the parsed message as JSON. For developers wiring an autonomous email agent.
- [The Postal alternative for AI agents](https://mailkite.dev/blog/postal-for-ai-agents/): Postal is a full self-hosted mail server: it sends, it receives inbound over incoming routes, and it can POST parsed messages to an HTTP endpoint. The catch for an agent inbox is operational, not technical. You run the box (MariaDB, Caddy, DNS, TLS, IP warmup, rDNS, blocklists). MailKite (which we build) is that same parsed-JSON receive→reply loop with no server to operate. For developers deciding whether to self-host an agent's inbox or hand off the ops.
- [The Postmark alternative for AI agents](https://mailkite.dev/blog/postmark-for-ai-agents/): Postmark's inbound is genuinely good: it parses incoming mail to clean JSON and POSTs it to your webhook. But it was built for transactional sending under manual account review, inbound sits behind the Pro plan, and the payload has no signature or SPF/DKIM verdict for an agent to trust. MailKite (which we build) gives an agent its own inbox on the free tier, a signed webhook with an auth block, and an optional built-in agent runner. For developers wiring an autonomous agent to email.
- [Why we built programmable email for agents](https://mailkite.dev/blog/programmable-email-for-agents/): An autonomous agent needs its own inbox and a way to reply — not a human's Gmail bolted on with IMAP and a refresh token. On SES that's a pipeline you wire and operate; Resend is send-first and not shaped for receiving; AgentMail is purpose-built but defaults to a shared domain and caps inboxes by plan. MailKite (which we build) gives the agent an address on a domain you own: DNS-verify it, then either point a route at a managed agent runner or bring your own agent behind a webhook — and hand it the MCP server or the SDK to send. For developers wiring an agent to email.
- [Programmable email: send and receive mail from code (run it in your browser)](https://mailkite.dev/blog/programmable-email-live-demo/): Programmable email means driving mail entirely from code — send with one API call, receive every message as JSON on a webhook, and give any app or agent its own inbox. Here's a live demo you can run right now: verify your email and send yourself a real, parsed message in about ten seconds, no signup form.
- [Programmable email vs. email API: what's the difference?](https://mailkite.dev/blog/programmable-email-vs-email-api/): An email API sends mail from your code. Programmable email adds the return trip — inbound delivered as JSON, an inbox your app or agent owns, and replies threaded back out, all on one domain you control. A fair comparison with the round-trip code that a send-only API can't give you.
- [The Resend alternative for AI agents](https://mailkite.dev/blog/resend-for-ai-agents/): Resend has first-class sending DX and, since November 2025, real inbound email. But its inbound webhook is metadata only: an agent fetches the body with a second API call and derives SPF/DKIM trust itself. MailKite (which we build) pushes the parsed body and an auth verdict in one event, so an agent's receive→reply loop is a single round trip. For developers giving an autonomous agent its own inbox.
- [The SendGrid alternative for AI agents](https://mailkite.dev/blog/sendgrid-for-ai-agents/): SendGrid is an outbound-first sending platform; its one inbound path, Inbound Parse, POSTs mail as multipart/form-data with a charsets map your code must honor before an agent can even read a verification code. MailKite (which we build) gives an agent a real inbox: parsed JSON, an auth block for trust, and a receive→reply loop. For developers wiring an autonomous agent to email.
- [Email you set up once and reuse for every project](https://mailkite.dev/blog/set-up-email-once-reuse-every-project/): If you ship a lot of small things, email shouldn't be a from-scratch chore each time: new account, verify domain, request production access, wire a parser. This is the setup you do once — one account, one API key — and what each new project costs after that: point a domain, reuse the key, drop in one webhook. With a reusable Node module and a single inbound handler that fans out to every project you run. For developers who launch many apps a year.
- [The SocketLabs alternative for AI agents](https://mailkite.dev/blog/socketlabs-for-ai-agents/): SocketLabs is enterprise sending infrastructure that can also receive: its Inbound Parse POSTs mail as JSON to a URL you configure, guarded by a validation-code handshake and a shared secret key, with a spam score but no normalized SPF/DKIM/DMARC verdict. MailKite (which we build) gives an agent a real inbox: signed parsed JSON, an auth block for trust, and a receive→reply loop. For developers wiring an autonomous agent to email.
- [The SparkPost alternative for AI agents](https://mailkite.dev/blog/sparkpost-for-ai-agents/): SparkPost (now Bird Email) is an enterprise sender whose inbound is Relay Webhooks: it POSTs a batched JSON array of relay messages carrying the raw RFC822 email — base64 in some fields — and no normalized auth verdict. MailKite (which we build) gives an agent a real inbox as one parsed email.received event with an auth block and a receive→reply loop. For developers wiring an agent to email.
- [The SMTP2GO alternative for AI agents](https://mailkite.dev/blog/smtp2go-for-ai-agents/): SMTP2GO is a clean, drop-in SMTP relay for sending, but it can't receive email at all, so an agent that has to read verification codes or replies needs a second provider bolted on. MailKite (which we build) gives the agent a real inbox as parsed JSON with a receive→reply loop, and sends too. For developers wiring an autonomous agent to email.
- [What is programmable email?](https://mailkite.dev/blog/what-is-programmable-email/): Programmable email is email you drive entirely from code: send with one API call, receive every message as JSON on a webhook, and give any app or AI agent its own inbox on a domain you control, with no mail server to run. The developer definition, the three primitives, and runnable code.
- [Why we built free programmable email for developers](https://mailkite.dev/blog/why-free-programmable-email-developers/): The path most of us walk is SES, then SendGrid, then Resend — each one fixes the last one's pain, and each one meters the thing a serial shipper does most: another domain, another project, another teammate. So we built MailKite (which we build) to meter only one thing — email volume — with unlimited domains, mailboxes, and teammates, and 3,000 messages a month free. Set it up once, reuse it on every project you launch, pay only when one takes off.
- [The ZeptoMail alternative for AI agents](https://mailkite.dev/blog/zeptomail-for-ai-agents/): ZeptoMail is Zoho's cheap, transactional-only sending service, so an AI agent built on it can email out but has no inbox to read a login code or a reply. To give it one you bolt on a Zoho Mail mailbox over IMAP: two providers, MIME parsing, a poll loop. MailKite (which we build) is one provider that receives inbound as parsed JSON and sends the reply, for developers wiring an agent to its own address.
- [Why aren't we seeing more agent security discussions?](https://mailkite.dev/blog/agent-security-blind-spot/): Agents are writing our codebases and running on our platforms, and the security conversation hasn't caught up. A field note on the vectors that came back, and one I opened on myself.
- [The Amazon SES alternative for developers](https://mailkite.dev/blog/amazon-ses-alternative/): SES is the cheapest way to send and the most assembly-required way to receive: sandbox approval, then raw MIME in S3 behind SNS, Lambda, and IAM. MailKite (which we build) sends the moment DNS verifies and delivers inbound as one parsed JSON webhook. Honest comparison, working code, runnable demo.
- [I wrote the same email parser three times, and the hard part was making them fail identically](https://mailkite.dev/blog/byte-identical-mime-failures/): @mailkite/mail-parse parses MIME in Node, Python, and Go. Getting all three to parse a good email the same way is the easy part; getting them to break the same way on the same malformed one, and emit a byte-identical FNV-1a fingerprint when they do, is the real work. How we proved it, with two lessons that transfer to any polyglot library.
- [The Mailgun Routes alternative for developers](https://mailkite.dev/blog/mailgun-routes-alternative/): Mailgun Routes is a filter-expression engine for inbound mail: match_recipient rules fire forward() and store() actions, and the parsed message arrives as form-encoded fields you decode and verify. MailKite (which we build) drops the rule DSL: point an address or catch-all at a webhook and the message arrives as one JSON payload with decoded text/html, SPF/DKIM/DMARC results, and signed attachment URLs. A fair comparison with working code for both sides.
- [Deliverability is a black box, and shared IPs let strangers tank you](https://mailkite.dev/blog/deliverability-black-box-shared-ips/): On a shared sending pool, a stranger's spam run can drag down the IP reputation your receipts go out on, while the dashboard still says 'delivered.' What you actually control: correct SPF/DKIM/DMARC, a separate monitored stream, and reading inbound auth results as data.
- [Give your AI agent its own email inbox](https://mailkite.dev/blog/give-your-agent-an-inbox/): Give an AI agent a real, scoped address on a domain you control. Inbound mail arrives as parsed JSON to an event.received loop and the agent replies over the Send API, or MailKite runs the agent for you on a route with action: agent. Working code, the security caveat, and the honest DIY alternatives.
- [They killed my account with no warning](https://mailkite.dev/blog/killed-my-account-no-warning/): Developer email has a pattern: silent suspensions, unappealable bans, and free tiers that vanish once they cost the vendor money. Why it happens, and the one protection that outlives any provider going bad: you own the domain, so moving is a DNS change, not a migration.
- [Build a support inbox in Next.js (email in, tickets out)](https://mailkite.dev/blog/support-inbox-nextjs/): Point support@yourdomain at MailKite, parse the inbound email to JSON, and POST it to a Next.js App Router Route Handler. Verify the signature against the raw body, create a ticket, and auto-reply. The whole loop, in working code.
- [The honest SendGrid Inbound Parse alternative](https://mailkite.dev/blog/sendgrid-inbound-parse-alternative/): SendGrid Inbound Parse POSTs inbound mail to your endpoint as multipart/form-data: a headers blob, body text, attachment file parts, and a charsets map you must honor to re-decode each field to UTF-8. MailKite (which we build) delivers the same mail as one JSON webhook with decoded text/html, an auth{spf,dkim,dmarc,spam} object, and attachments as short-lived signed URLs. A fair comparison with working code for both sides.
- [Cloudflare Email Routing can't reply: how to send from your domain](https://mailkite.dev/blog/cloudflare-email-routing-cant-reply/): Cloudflare Email Routing forwards inbound mail and Email Workers hand your code the raw MIME, but there's no first-class reply-from-your-domain path: that takes Routing plus a Worker that parses MIME plus the separate Email Service beta. Where the gap is, the DIY assembly on Cloudflare with real code, and how MailKite (which we build) closes the loop: parsed JSON in, one send call out.
- [Handling email attachments without losing the £ sign](https://mailkite.dev/blog/email-attachments-without-corruption/): Received email attachments arrive as inline base64 that bloats every webhook, and a charset mismatch turns £ into £. Here's why it happens, how SendGrid Inbound Parse, Cloudflare Email Routing, and self-hosting each leave the decode to you, and what a parsed attachments[] array of signed URLs looks like instead, with runnable Node code.
- [How to verify inbound email webhooks (HMAC signatures)](https://mailkite.dev/blog/verify-inbound-webhooks-hmac/): An unverified webhook endpoint is an open door: anyone can POST a fake email.received event. How to verify the HMAC signature with one SDK call in Node, Python, and Go, why the raw body bytes matter, and the hand-rolled check if you can't take a dependency.
- [Reply-by-email: handling inbound replies in your app](https://mailkite.dev/blog/reply-by-email-in-your-app/): When users reply to your notification emails, capture the reply, thread it to the right conversation with threadId, and respond: either an inline ack or a real outbound message. Working Node code, honest DIY path.
- [Receiving email is the part nobody warns you about](https://mailkite.dev/blog/receiving-email-nobody-warns-you/): Sending email is a solved problem. Receiving it, turning real-world MIME into something your app can use, is where everyone quietly loses a week. Why inbound is the hard direction, how each option punts, and what one clean webhook looks like instead.


## Email tools directory

- [Email platforms](https://mailkite.dev/tools#platforms): Resend, Postmark, SendGrid, Mailgun, Amazon SES, MailKite.
- [Inbound & parsing](https://mailkite.dev/tools#inbound): Email-to-webhook and parsing services.
- [Agent & MCP email](https://mailkite.dev/tools#agent-mcp): Inboxes and MCP servers that give AI agents email.
- [SMTP relay](https://mailkite.dev/tools#smtp): Send-only SMTP relay services.
- [Deliverability & DNS](https://mailkite.dev/tools#deliverability): SPF/DKIM/DMARC and monitoring tools.
- [Email testing](https://mailkite.dev/tools#testing): Sandbox inboxes and QA tools.
- [Open-source mail servers](https://mailkite.dev/tools#oss-server): Self-hosted mail infrastructure.