Todo equipo que construye funciones de email se enfrenta tarde o temprano a la misma bifurcación: apuntar el desarrollo a un proveedor SMTP real, o fingir la capa de correo y esperar que producción se comporte. La primera opción filtra credenciales, quema cuota del proveedor y ocasionalmente escribe a un cliente real desde un portátil. La segunda no prueba nada más allá del punto en que tu código entrega el mensaje a un servidor. Hay un camino medio mejor — varios, de hecho. Así se comparan las opciones estándar de pruebas locales, y cuándo gana cada una.
Por qué el SMTP real en desarrollo es mala idea
La tentación es comprensible: proveedor real, comportamiento real, cero configuración. Los costes aparecen después:
- Fuga de credenciales. Las claves de API que viven en archivos .env de las máquinas de los desarrolladores acaban en logs, capturas de pantalla y, tarde o temprano, en un hilo de chat.
- Envíos reales accidentales. Una ejecución de pruebas contra una base de datos de producción copiada escribe a usuarios reales desde tu portátil. Esto pasa constantemente, y siempre es memorable.
- Suites de pruebas inestables. Cuando los tests unitarios dependen del uptime, los límites de tasa y las rarezas del sandbox de un tercero, el CI se convierte en meteorología.
- Coste y cuota. Incluso los planes gratuitos generosos se agotan rápido cuando una suite envía cientos de mensajes por ejecución.
La solución es mantener el envío real fuera del bucle interno por completo — el razonamiento de correo temporal para desarrollo y pruebas QA se aplica también al desarrollo local.
Opción 1: servidores SMTP locales catch-all (MailHog, Mailpit)
Un servidor catch-all escucha en un puerto local, acepta todo sin auth ni TLS, guarda los mensajes en memoria y los muestra en una interfaz web. Tu app le apunta como a cualquier host SMTP:
SMTP_HOST=127.0.0.1 SMTP_PORT=1025
docker run -p 1025:1025 -p 8025:8025 axllent/mailpit
Mailpit es el estándar mantenido actual: vista previa HTML, parseo MIME, una API REST para aserciones y un modo caos que simula fallos y retrasos. MailHog, su predecesor, lleva sin mantenimiento desde 2020 pero sigue funcionando y sigue apareciendo en incontables tutoriales; elige Mailpit para cualquier cosa nueva.
Gana en: pruebas unitarias y de integración, trabajo de frontend donde los diseñadores necesitan ver los emails, y portátiles en trenes sin red alguna.
Opción 2: buckets SMTP en contenedor dentro del stack de desarrollo
El siguiente escalón incrusta el bucket de correo en tu stack de docker-compose de desarrollo como un servicio con nombre y un volumen persistente. Dos cosas mejoran:
- Estado compartido. El correo de cada desarrollador aterriza en un sitio predecible, y reiniciar tu app no borra la bandeja.
- Aserciones de prueba vía API. Mailpit expone una API REST, así que los tests de integración pueden obtener el último mensaje enviado a una dirección y afirmar sobre asunto, cabeceras y cuerpo sin parsear logs.
La contrapartida no cambia: el correo nunca sale de la máquina. La autenticación, el DNS y la entregabilidad real quedan sin probar, así que una suite en verde puede seguir desplegando un registro de envío roto. Antes de cablear el staging a dominios reales, confirma también el lado receptor — el comprobador de MX muestra los mail exchangers de cualquier dominio al que vayas a escribir.
Opción 3: bandejas desechables para realismo de staging
Los buckets locales no pueden responder a la pregunta de si el mensaje llegó de verdad a través de internet real. Esa pregunta exige entrega real, y ahí es donde las bandejas desechables se ganan el sueldo. Apunta el staging a tu infraestructura de envío real y usa direcciones temporales como destinatarias: los mensajes atraviesan DNS, TLS y filtrado de proveedor genuinos, y puedes afirmar sobre tiempo de llegada, contenido y envío a spam — no solo sobre tu propio log de salida.
Este enfoque brilla para:
- Flujos de registro de extremo a extremo. Enlaces de verificación y códigos de un solo uso, afirmados desde el lado de la bandeja, con el patrón de automatización de automatización con la API de correo temporal.
- Pipelines de webhooks. Los webhooks de bounce y de mensajes entrantes necesitan eventos de correo reales para probarse; nuestra guía sobre recibir webhooks de email desde una bandeja temporal recorre el cableado.
- Ensayos generales pre-producción. La configuración completa de staging se cubre en pruebas en entornos de staging.
Qué opción para cuándo
- Tests unitarios locales y vista previa: Mailpit en localhost. Rápido, offline, cero efectos secundarios.
- Entorno de desarrollo de equipo: Mailpit como servicio de compose con volumen. Compartido, inspeccionable, con aserciones por API.
- Staging y verificación de release: envío real más bandejas destinatarias desechables. La única opción que ejercita la ruta real que recorre el correo de tus usuarios.
- Monitorización de producción: no es un tema local en absoluto — ahí toman el relevo las comprobaciones de ubicación y las pruebas seed.
Trátalas como capas, no como competidoras: la mayoría de setups maduros ejecutan las tres, cada una a la altura que se le da bien.
FAQ
¿Sigue siendo MailHog una buena elección en 2026? Sigue funcionando, pero lleva años sin mantenimiento y va por detrás en el manejo de MIME moderno. Mailpit es su sucesor en desarrollo activo con un conjunto de funciones compatible — elígelo para cualquier cosa nueva.
¿Puedo probar DKIM y SPF con un servidor SMTP local? No. La autenticación implica DNS y búsquedas de clave pública que un servidor de localhost nunca ejercita. Usa entrega real a direcciones desechables y verifica luego las firmas en el mensaje recibido.
¿Cómo evito que mi entorno de desarrollo escriba a personas reales? Apúntalo a SMTP local, o usa un flag de staging que reescriba todos los destinatarios a bandejas desechables. Nunca mantengas credenciales de producción en un camino alcanzable desde dev.
¿Cuál es la forma más barata de afirmar que llegó un email en CI? Crea una bandeja temporal vía API, lanza el envío, haz polling del mensaje y falla el build por timeout. Son unas líneas de script y captura los fallos que los buckets locales no pueden.