Mejores clientes de correo para desarrolladores 2026: TUI, …

El ciclo 2025-2026 se ha convertido discretamente en un gran año para el correo en terminal. aerc capitalizó su paso por FOSDEM 2025 con una base Go 1.23; Himalaya llegó a v1.2.0 en febrero de 2026; NeoMutt mantiene su cadencia mensual con un lanzamiento del 2026-05-04; y Thunderbird Monthly Release 145 añadió soporte nativo de Exchange Web Services, cerrando el último hueco para desarrolladores atrapados en Microsoft 365. Resultado: en 2026 un desarrollador puede tener un cliente de correo de teclado real, texto plano primero, scriptable, en Linux, Mac o Windows sin pagar un céntimo. Aquí van los siete que realmente usaríamos, con los compromisos explicitados.

Cómo seleccionamos

Probamos cada cliente contra un flujo pensado para desarrollador: una cuenta IMAP con unos cuantos miles de hilos archivados, una cuenta JMAP en Fastmail, un Maildir para correo personal y un buzón Microsoft 365 para trabajo de cliente. Criterios duros: atajos vim o al estilo vim, vista de fuente bruta (cabeceras, partes MIME), renderizado de bloques de código y patches, acceso a nivel de protocolo (IMAP/JMAP/Maildir sin webmail) y scriptabilidad — ex-command, API de plugins o CLI pipeable por shell.

Descartamos cualquier cliente cuya arquitectura obligue al correo a pasar por servidores propietarios (Hey, Superhuman). Descartamos clientes de consumo pulidos que se niegan a exponer la fuente del mensaje o el árbol MIME de adjuntos (la mayoría de apps iOS-first).

Los criterios del veredicto que nos importaron:

Atajos. Al estilo vim/Emacs, o remappeable a eso. Sin recurso al ratón aceptable para triage.
Texto plano primero. HTML se renderiza a demanda, no por defecto; cambio a vista de fuente con un atajo.
Nativo al protocolo. IMAP, JMAP, Maildir, SMTP — sin abstracciones propietarias.
Scriptable. Leer/enviar/buscar desde un script o pipeline de shell; nada de flujos solo por UI.
Amigable con git y patches. Render de diffs inline, adjuntos pipeables a git am, o ambos.
Licencia honesta. Código abierto preferido, comercial aceptado si la licencia no es hostil al usuario.

1. aerc — TUI hecha para el hacker exigente

Ideal para: Desarrolladores que viven en tmux y quieren correo consciente de git.

aerc es un cliente de correo en terminal escrito en Go (92,5 % del código) bajo licencia MIT. Ofrece atajos al estilo vim, un sistema ex-command, una terminal embebida para redactar correos junto a otros hilos o repositorios git, renderizado inline de diffs y patches, y soporta backends IMAP, JMAP, Maildir, Notmuch y Mbox. El proyecto se describe como «perfecto para el hacker exigente» — y tras las pruebas, esa descripción se sostiene. (Fuente: aerc-mail.org, consultado el 2026-05-27.)

Las funciones decisivas para un flujo de desarrollo son concretas:

Redacción en terminal embebida. Abre una pestaña con una shell y un repo git a mano mientras escribes una respuesta. Sin baile alt-tab.
Manejo de patches. Soporte de primera clase para git send-email y git am. Resaltado inline de diffs en patches sin configuración.
HTML a demanda. El renderizado HTML es opt-in mediante filtros (w3m o el navegador de terminal integrado). El default es texto plano o texto plano formateado — exactamente el default correcto para hilos cargados de código.
ex-commands. Todo lo que haces interactivo se puede scriptear — :filter, :pipe, :read se integran con herramientas de shell.

El compromiso que hay que aceptar de entrada: aerc canaliza contribuciones por mailing list (el mirror en GitHub es solo lectura), la configuración es TOML denso y no hay plan B GUI. Si haces pair-programming sobre triage de correo, tu pareja debe ser también usuario de terminal.

Ideal para: Usuarios avanzados de Linux/macOS que hacen correo junto a git, quieren que los flujos de patch parezcan nativos y aceptan el compromiso TUI.

Sáltalo si: Necesitas GUI para triage de newsletters HTML, o compartes setup con compañeros no-terminal.

2. NeoMutt — el clásico de terminal, modernizado

Ideal para: Veteranos de Mutt que quieren parches modernos y mantenidos sin renunciar a la memoria muscular.

NeoMutt es un fork de Mutt que agrupa «muchos parches viejos de Mutt» actualizados y documentados — el parche Sidebar es el ejemplo canónico, adoptado más tarde por el Mutt upstream. El proyecto sigue una cadencia mensual; el lanzamiento más reciente está fechado el 2026-05-04. (Fuente: neomutt.org, consultado el 2026-05-27.)

Si ya eres usuario de Mutt, NeoMutt es la actualización indolora: tu .muttrc funciona en lo esencial, el binario es un drop-in limpio y los añadidos (sidebar, integración notmuch, mejoras de color) son justo los parches que aplicarías a mano. Si estrenas correo en terminal en 2026, aerc tiene mejores defaults; NeoMutt es la elección correcta cuando heredas una configuración existente o trabajas en una empresa que se estandarizó sobre Mutt hace años.

Lo que NeoMutt hace mejor que aerc, en concreto: flexibilidad de macros y bindings, notmuch como backend de primera clase y un corpus comunitario de 25 años (busca «muttrc github» — hay miles de dotfiles públicos). Lo que aerc hace mejor: los defaults, el renderizado HTML, la redacción embebida, la gramática ex-command.

Ideal para: Veteranos de Mutt, usuarios de notmuch, gente a la que le gusta editar la config hasta que todo encaja perfecto.

Sáltalo si: Empiezas de cero sin muttrc existente — aerc requiere menos rampa.

3. Himalaya — CLI en Rust, pipeable como JSON

Ideal para: Desarrolladores que quieren correo alcanzable desde xargs, un script u otro TUI.

Himalaya es un cliente de correo de línea de comandos en Rust (99,2 % Rust según el repositorio). Soporta backends IMAP, JMAP, SMTP, Maildir y m2dir, expone un modo de salida JSON, y se publica bajo licencia AGPL-3.0. La última versión estable es v1.2.0, publicada el 19 de febrero de 2026. (Fuente: github.com/soywod/himalaya, consultado el 2026-05-27.)

Himalaya no es un TUI en el sentido de aerc o NeoMutt — es un comando. Lanzas himalaya envelope list, pasas el JSON a jq, lo cableas en una función de shell o un plugin de Neovim. La superficie de autenticación es inusualmente amplia: anonymous, login, plain, OAuth bearer, XOAUTH2, SCRAM-SHA-256, más HTTP basic y bearer para JMAP. La configuración TOML soporta varias cuentas en un solo archivo, y los mecanismos de descubrimiento (PACC, autoconfiguración Thunderbird, SRV RFC 6186) hacen que la puesta a punto rara vez sea manual.

El encuadre honesto: Himalaya es casi siempre un complemento, no un cliente único. La mayoría de desarrolladores lo combinan con aerc o NeoMutt para leer y usan Himalaya para los trozos scripteados — envío masivo, búsqueda programática, notificaciones de CI/CD. Como herramienta «lee las noticias del día en 30 segundos», la pipeline JSON gana a abrir una GUI.

¿Necesitas un repaso del triage de bandeja antes de que todo esto cobre sentido? Cómo gestionar varias cuentas de correo cubre los cimientos.

Ideal para: Flujos centrados en shell, automatización scriptable, usuarios de Neovim que quieren primitivas de correo dentro del editor.

Sáltalo si: Quieres vivir en una sola app para leer, escribir y buscar.

4. Thunderbird — la GUI open source que por fin se ha puesto al día

Ideal para: Desarrolladores que necesitan GUI, quieren código abierto y tienen un buzón Microsoft 365 en juego.

Thunderbird lo mantiene MZLA Technologies Corporation (filial de Mozilla) bajo licencia MPL 2.0. Funciona en Windows, macOS y Linux, y se publica en dos canales: 128 ESR (la versión extended-support estable actual) y Monthly Release. Monthly Release 145 añadió soporte nativo de Exchange Web Services a finales de 2025. JMAP está soportado desde Thunderbird 115 (2023). (Fuente: blog de Thunderbird, community office hours de diciembre de 2025.)

Para un desarrollador que ha intentado los clientes TUI y se ha echado atrás, Thunderbird es el punto de partida correcto en 2026. La API de extensiones es real (busca extensiones de Thunderbird en MozillaAddons — ecosistema activo), la vista de fuente del mensaje queda a un atajo (Ctrl+U), y la cobertura de protocolos es ahora genuinamente completa: IMAP, POP3, JMAP y EWS (Exchange) en el mismo binario.

Dos ganancias específicamente de desarrollador a destacar:

Los filtros son scriptables a un nivel útil. Combinados con la vista de fuente, montas un sistema de triage que se acerca a la UI de filtros de Gmail en pura configuración local.
Soporte de Exchange sin Outlook. Si tu trabajo diario va sobre Microsoft 365, Thunderbird 145 Monthly es la primera opción GUI creíble que no es Outlook y maneja Exchange de forma nativa (en vez de con un puente IMAP frágil).

El compromiso: Thunderbird no es un TUI. Es una GUI de escritorio con tripas amigables para desarrolladores, no un cliente developer-first. El arranque es más lento que aerc, el sistema de atajos es remappeable pero los defaults son con forma GUI, y el índice de búsqueda puede arrastrarse en setups multi-cuenta por encima de 50 GB.

Ideal para: Requisito de GUI, entornos Microsoft 365, preferencia open source, equipos multiplataforma.

Sáltalo si: Quieres arranque por debajo de 100 ms y un flujo 100 % teclado — ve a aerc o NeoMutt.

5. Mailspring — Electron, motor nativo, licencia MIT

Ideal para: Desarrolladores que quieren una GUI pulida sin el retraso de arranque de Thunderbird y no se asustan con Electron.

Mailspring es un cliente de correo de escritorio con un motor de sincronización nativo en C++ y una UI Electron. Funciona en macOS, Windows y Linux, soporta Gmail, iCloud, Office 365, Fastmail, Outlook.com, Yahoo e IMAP/SMTP genérico, y es íntegramente código abierto bajo licencia MIT. El plan Pro cuesta 8 $/mes y añade confirmaciones de lectura, tracking de enlaces, envío diferido, plantillas y enriquecimiento de contactos. (Fuente: getmailspring.com, consultado el 2026-05-27.)

Mailspring ocupa un nicho extraño: demasiado pulido para la tribu terminal, demasiado plano para quienes quieren la capa colaborativa de Spark. Para un desarrollador que quiere una GUI gratuita, activamente mantenida y que no bloquee funciones tras paywall en la versión gratuita, es una opción razonable. El motor de sincronización nativo en C++ es más rápido que los backends JavaScript que arrastran la mayoría de clientes Electron.

Los límites honestos: no hay API pública de plugins documentada al modo de la de Thunderbird. El código es hackeable (MIT, fórkalo), pero no eres el público objetivo de la historia de extensibilidad existente. Si «scriptable» pesa más que «GUI pulida», sigue de largo.

Ideal para: Desarrolladores multiplataforma que quieren una GUI gratuita con bandeja unificada y no necesitan scripting.

Sáltalo si: Quieres una API de plugin documentada, o prefieres pagar por el pulido nativo Gmail de Mimestream en Mac.

6. Apple Mail — con AppleScript y Atajos

Ideal para: Desarrolladores solo-Mac que prefieren automatizar el cliente de serie a instalar otra app.

Apple Mail en macOS Sequoia 15.4 (marzo de 2025) ganó categorías de bandeja de Apple Intelligence y resúmenes en el dispositivo. Para uso de desarrollo, la función más pertinente es la superficie de AppleScript y Atajos, presente desde hace tiempo: Mail.app expone un diccionario de scripting, lo que significa que puedes construir automatizaciones de bandeja, exportadores de adjuntos y reglas de archivado en AppleScript invocable desde shell, sin herramientas externas.

Apple Mail no es un cliente developer-first. Es un cliente de serie con una superficie de automatización que la mayoría olvida que existe. El diccionario AppleScript cubre mensajes, cuentas, buzones, firmas y reglas. Atajos en macOS (desde Monterey) se superpone a eso y te ofrece una interfaz pinchar-y-construir sobre las mismas acciones.

Para qué es útil: automatizaciones de bandeja rutinarias que no justifican una herramienta aparte. Guardar adjuntos de un remitente conocido en una carpeta de proyecto, archivar hilos al acabar un evento de calendario, despachar mensajes de un dominio a una carpeta etiquetada. Nada revolucionario, pero viene con el SO y cuesta cero.

Para qué no es útil: cualquier equipo multiplataforma, cualquier cosa que deba correr en un servidor, cualquier cosa que requiera composición amigable con patches. La vista de fuente de Apple Mail existe (Cmd+Opción+U) pero es incómoda, y el renderizado HTML es opinable.

Ideal para: Desarrolladores solo-Mac, automatización ligera, postura «no quiero otra app».

Sáltalo si: Te mueves entre plataformas, o necesitas triage por teclado de verdad a velocidad.

7. Spark — capa de triage de equipo, no cliente de desarrollador

Ideal para: Equipos pequeños donde uno o dos miembros son desarrolladores y el resto no.

Spark es un cliente de correo multiplataforma pulido (Mac, Windows, iOS, Android) con bandejas compartidas, comentarios en hilos y borradores asistidos por IA. No es un cliente orientado a desarrollador. Lo incluimos porque para flujos en forma de equipo — donde el desarrollador es un rol más junto a soporte, ventas y operaciones — la capa colaborativa de Spark es el compromiso adecuado.

El compromiso que Spark impone es procesamiento en servidor: tu correo pasa por la infraestructura de Readdle para alimentar las funciones inteligentes. Para la mayoría de desarrolladores es inaceptable como cliente principal; para equipos donde la alternativa es un guiso fragmentado de Slack + Gmail, es una elección defendible.

Incluimos a Spark en la lista estrictamente para que un desarrollador que evalúa «sobre qué debería estandarizarse mi equipo» tenga la opción cubierta. Como cliente de desarrollador personal, la ausencia de vista de fuente en texto plano, la falta de hooks de scripting y el enrutado por servidor juegan todos en contra.

¿Cansado del ruido de newsletters en cualquiera de estos clientes? Leave Me Alone gestiona limpio el desuscribirse en masa entre proveedores — ver nuestro comparativo de herramientas de desuscripción.

Ideal para: Equipos pequeños, multidisciplinares; fundadores que llevan operaciones junto a ingeniería.

Sáltalo si: Quieres un cliente developer-first, o no puedes hacer pasar el correo por servidores de terceros.

Comparativa lado a lado

Los siete clientes intercambian en tres ejes: GUI vs TUI, profundidad de scriptabilidad y amplitud de protocolos. aerc y Himalaya son los más scriptables; Thunderbird y Mailspring son las GUIs más completas; NeoMutt es el más configurable; Apple Mail y Spark se sitúan en el extremo «automatización como añadido». En licencias, seis de los siete son código abierto — Spark es la excepción.

Cliente	Tipo	Licencia	Protocolos	Mejor señal
aerc	TUI (Go)	MIT	IMAP, JMAP, Maildir, Notmuch, Mbox	Compose embebida, renderizado de patches
NeoMutt	TUI (C)	GPL-2.0+	IMAP, POP, SMTP, Maildir, Notmuch	Compatible con Mutt, config profunda
Himalaya	CLI (Rust)	AGPL-3.0	IMAP, JMAP, SMTP, Maildir	Pipeable como JSON, scriptable
Thunderbird	GUI (XUL/Rust)	MPL 2.0	IMAP, POP, JMAP, EWS	GUI + API de extensiones + EWS
Mailspring	GUI (Electron + C++)	MIT	IMAP, SMTP (Gmail/O365/Fastmail/…)	Sync rápida, plan gratuito completo
Apple Mail	GUI (Cocoa)	propietaria (gratis con macOS)	IMAP, POP, Exchange, iCloud	AppleScript + Atajos
Spark	GUI (propietaria)	propietaria	IMAP, OAuth (Gmail, O365)	Triage de equipo, bandeja compartida

Si prefieres no atarte a un único cliente, Mailbird es la opción multiplataforma pulida para quien quiere GUI sin la complejidad developer-first — está construido para los knowledge workers en Windows, no para desarrolladores. Bueno saber que existe; no recomendable como cliente dev principal.

Por qué no Hey, Superhuman o Mailbird

Hey de Basecamp enruta todo por su propia infraestructura sin escape IMAP. Superhuman es un frontend de Gmail a 30 $/mes sin scripting, sin vista de fuente, sin integración con IDE. Mailbird es una GUI Windows-first hecha para knowledge workers, no para desarrolladores — sin alternador de fuente en texto plano, sin API de plugins, sin modo terminal. Los tres son opciones razonables para no-desarrolladores; ninguno cumple el mínimo de un desarrollador.

Hey de Basecamp. Hey cierra deliberadamente IMAP y SMTP — la arquitectura es «tu correo vive en Hey, fin de la cita». Para el público de Basecamp es una feature. Para un desarrollador que necesita scriptear exportaciones masivas, integrar con un flujo git o simplemente cambiar de cliente sin reimportar todo, es un veto. Hey no cambió eso en 2026.

Superhuman. 30 $/mes por un wrapper rápido de Gmail es una elección perfectamente válida si tu única métrica es velocidad-a-cero en una cuenta Gmail. El producto no tiene capa de scripting, ni sistema de plugins, ni vista de fuente, ni integración relevante para desarrolladores. Llamarlo «cliente de correo para desarrolladores» exige definiciones creativas de «desarrollador».

Mailbird. Mailbird es un buen cliente de correo Windows para knowledge workers — bandeja unificada, panel de apps con Slack y WhatsApp acoplados, atajos pulidos. Explícitamente no es un cliente de desarrollador: no hay vista de fuente en texto plano por defecto, ni API de plugin para lógica propia, ni modo terminal/TUI. Recomendamos Mailbird en nuestra ronda de Windows y ronda de Mac para uso general; no pertenece a una lista centrada en desarrolladores.

Cuándo ninguno encaja

Si tu flujo es sobre todo automatización en servidor (correo de CI/CD, enrutamiento de alertas, envío transaccional), olvídate de clientes y usa una librería: imaplib + email en Python, lettre en Rust, nodemailer en Node, net/mail en Go. Si tu primario es iOS, ninguna de las opciones developer-friendly funciona — repliega en Apple Mail y delega el scripting a tu Mac o un servidor.

Casos en servidor. Leer acuses de webhook en CI, deduplicar alertas, envío transaccional — ninguno necesita cliente. Usa una librería, escribe un demonio pequeño, registra en tu stack de observabilidad.

Desarrolladores iOS-first. Los clientes TUI no existen en iOS. Las opciones realistas son Apple Mail (con Atajos corriendo en el dispositivo), Spark (en servidor, acepta el compromiso) o Gmail web. El tooling developer-first no está.

Quieres GUI pulida Y TUI en una sola app. No existe en 2026. Lo más cerca es correr Thunderbird + aerc en paralelo contra la misma cuenta IMAP — no entran en conflicto, simplemente leen el mismo estado en servidor.

¿Necesitas manejar tres o cuatro cuentas a la vez sin perder contexto? Nuestra guía para gestionar varias cuentas de correo desgrana los patrones de bandeja unificada.

Lectura relacionada:

Alexis Dollé

Fundador & Editor

Alexis Dollé, experto en email desde hace 10+ años y usuario de terminal de larga data. Fundador de Email Tools. Pruebo cada cliente sobre un flujo real de desarrollador — IMAP + JMAP + Maildir, git send-email y un buzón Microsoft 365 para trabajo de cliente — y luego escribo como si se lo explicara a un colega. Sin paja de marketing, sin rankings patrocinados, cada afirmación documentada.

Preguntas frecuentes

¿Cuál es el mejor cliente de correo para desarrolladores en 2026?: aerc

aerc, si vives en una terminal. Atajos al estilo vim, terminal embebida para redactar junto a git, renderizado de patches y diffs de primera clase, soporte JMAP. Como alternativa GUI que respeta los instintos de desarrollador, Thunderbird con su API de extensiones es la segunda opción más segura.

¿Sigue siendo relevante mutt, o conviene pasar a aerc?: NeoMutt está al día

NeoMutt sigue mantenido activamente — la versión del 2026-05-04 es la más reciente — y es la opción correcta si tu memoria muscular ya está en mutt. aerc es la mejor apuesta si empiezas de cero en 2026: mejores valores por defecto en HTML, redacción en terminal embebida y un sistema ex-command más limpio.

¿Puedo usar Himalaya como cliente de correo único?: suele ser un complemento

Si tu flujo tolera una interfaz solo de línea de comandos, sí. Himalaya v1.2.0 (publicada el 19 de febrero de 2026) es estable para uso diario con IMAP, JMAP, SMTP y Maildir. Combina bien con notmuch o aerc como capa de lectura. Para la mayoría de desarrolladores es un complemento, no un sustituto.

¿Thunderbird ya soporta JMAP?: sí, desde 115

Sí — JMAP se añadió en Thunderbird 115 (2023) y sigue presente en la 128 ESR y en el canal Monthly Release. Thunderbird 145 Monthly añadió soporte nativo de Exchange Web Services. Como cliente libre y de código abierto que cubre IMAP, JMAP y ahora EWS, Thunderbird es la opción GUI más completa.

¿Por qué no Hey, Superhuman o Spark para desarrolladores?: falta lo básico

Hey de Basecamp es cerrado y opinable; todo pasa por la infraestructura de Hey, sin escape IMAP. Superhuman es un frontend de Gmail sin integración con IDE ni git. Spark sirve para triage en equipo, pero no ofrece vista en texto plano de la fuente, ni hooks scriptables, y enruta correo por los servidores de Readdle. Las funciones relevantes para un desarrollador son mínimas en los tres.

¿Mailspring es scriptable?: sin API de plugin documentada

Mailspring es código abierto bajo licencia MIT y usa un motor de sincronización nativo en C++ con una UI Electron. El código es hackeable, pero no hay una API pública de plugins documentada como la que expone Thunderbird. Para «scriptable» te van mejor aerc, Himalaya o NeoMutt — cada uno está construido en torno a configuración como código.

Fuentes