Cómo elegir una cuenta de correo electrónico de prueba para control de calidad

¿Qué es una cuenta de correo de prueba para QA?

Una cuenta de correo de prueba, o dirección de correo de prueba para QA, es una dirección que tu equipo usa para recibir e inspeccionar los correos que envía tu propia aplicación. Usa una bandeja de entrada temporal para comprobaciones manuales de registro y OTP que no sean sensibles. Elige un buzón de empresa para mensajes que debas conservar, respuestas o archivos adjuntos, y un sandbox SMTP o una API de bandeja de entrada alojada cuando las pruebas automatizadas deban inspeccionar el correo sin intervención de una persona.

Tmailor gestiona este blog, así que aquí es donde encaja. Tmailor es un servicio de correo temporal gratuito y de solo recepción disponible en la web, Android, iOS y un bot de Telegram. Encaja en el primer caso: una persona abre una bandeja de entrada, inicia un registro y lee lo que llega. Para el último caso, la API independiente de Tmailor Temp Mail permite que las pruebas automatizadas creen direcciones de solo recepción y lean sus mensajes desde el código. Los mensajes se conservan unas 24 horas desde su llegada, no se reciben archivos adjuntos y la dirección no puede enviar ni responder. Si eres nuevo en las bandejas de entrada desechables, empieza por cómo funciona el correo temporal.

• No es necesario que llegue ningún correo (validación de formularios, datos de prueba, pruebas unitarias): usa un dominio de ejemplo reservado.
• Una persona lee el correo y nada de su contenido es sensible: una bandeja de entrada temporal es la opción más rápida.
• Datos sensibles, respuestas, archivos adjuntos o pruebas que debas conservar: usa un buzón aprobado y controlado por la empresa; añade etiquetas plus solo si tu sistema de correo y tu aplicación las admiten.
• Nadie supervisa: usa un SMTP catcher si controlas la configuración del correo saliente de la app, o una API de bandeja de entrada alojada si la app debe enviar a través de su proveedor habitual.

Pruebas de correo manuales frente a automatizadas: un árbol de decisiones

Cuatro preguntas determinan qué cuenta de correo de prueba necesita una comprobación: si debe llegar un correo, si lo lee una persona o un código, si contiene datos sensibles y si controlas a dónde envía la aplicación su correo saliente.

1. ¿La prueba necesita que llegue un correo? Las comprobaciones de formato, los estados de la interfaz, los datos de prueba y las pruebas unitarias normalmente no lo necesitan. Usa direcciones en example.com, example.org o example.net. Esos dominios están reservados para documentación y ejemplos, así que nada llega a una persona real. Evita inventar dominios aleatorios, porque alguien podría ser su propietario.
2. ¿Leerá una persona el mensaje durante la prueba? Las pruebas de humo, el UAT manual, las demostraciones y las sesiones exploratorias tienen a una persona en el proceso. Las suites de regresión y los trabajos de CI normalmente no.
3. Si lo lee una persona, ¿hay algo sensible en él? Los registros reales de clientes, las credenciales, los datos regulados o los mensajes que debas conservar como evidencia de auditoría no deben estar en una bandeja de entrada temporal. Usa un buzón de empresa en su lugar. Si la respuesta es no, una bandeja de entrada temporal es suficiente.
4. Si lo lee un código, ¿puede el entorno de prueba enviar su correo a un servidor SMTP de prueba? Si es así, un SMTP catcher captura todos los mensajes sin entregarlos. Si no, porque la app debe enviar a través de su proveedor de correo habitual, usa una bandeja de entrada alojada que tus pruebas lean a través de una API.

La tabla compara las cinco opciones una al lado de la otra.

¿Qué direcciones debería aceptar o rechazar un campo de correo electrónico?

Prueba la validación del formulario por separado de la entrega del mensaje. Usa una dirección reservada como user@example.com para un caso que parezca válido y que nunca se entregue, incluye una dirección con etiqueta plus y otra con subdominio, y añade casos mal formados como la ausencia de la parte local o del dominio. Mantén los resultados esperados alineados con el validador que realmente usa tu sistema de producción.

Cuándo basta una bandeja de entrada temporal

Una bandeja de entrada temporal sirve cuando una persona revisa un flujo a la vez y el mensaje no contiene nada que te importaría perder al cabo de un día. Ese es el uso clásico de un correo desechable para QA: necesitas una dirección de correo para probar un formulario a mano, no una cuenta duradera. Los casos típicos son una prueba de humo previa al lanzamiento del formulario de registro, una pasada manual de UAT sobre un nuevo correo de incorporación, una demostración de ventas de creación de cuenta o una sesión exploratoria en la que pruebas entradas extrañas y observas lo que envía la aplicación.

La ventaja es la rapidez. No hay que solicitar ninguna cuenta a TI ni limpiar ningún buzón compartido. La contrapartida es el control: tienes una ventana de mensajes corta, sin archivos adjuntos, y una bandeja de entrada que lee una persona en lugar de un código.

Cuándo necesitas un capturador SMTP o una API de bandeja de entrada alojada

Cuando las pruebas se ejecutan sin supervisión, la bandeja de entrada debe poder leerse mediante código. Dos familias de herramientas cubren esa necesidad y resuelven problemas distintos.

Los capturadores SMTP y los sandboxes sustituyen el servidor de correo saliente de tu aplicación en un entorno de prueba y conservan cada mensaje para inspeccionarlo en lugar de entregarlo.

• Mailpit es una herramienta gratuita y de código abierto que ejecutas tú mismo. Captura el correo de forma predeterminada y ofrece una interfaz web y una API REST para pruebas de integración.
• MailHog funciona igual, pero es más antiguo. Los mantenedores de Mailpit lo describen como ya sin mantenimiento, así que comprueba su estado antes de adoptarlo.
• Mailtrap Email Sandbox es una versión alojada de la misma idea, con acceso por SMTP y API. Es independiente del producto de envío de producción de Mailtrap.
• Ethereal es un servicio SMTP falso gratuito que se usa principalmente con Nodemailer. Los mensajes se capturan para previsualizarlos y nunca se entregan.

Las APIs de bandeja de entrada alojadas dan a las pruebas direcciones reales en los dominios del proveedor, así que tu app envía el correo a través de su proveedor habitual y la prueba lee el resultado mediante una API. La propia API de correo temporal de Tmailor funciona así, con SDKs oficiales para Python, Node.js y PHP.

• Mailosaur ofrece direcciones de correo de prueba, una API y bibliotecas cliente que funcionan con frameworks como Cypress, Playwright y Selenium. También cubre códigos por SMS.
• MailSlurp crea bandejas de entrada bajo demanda mediante su API y sus SDKs. Las pruebas pueden esperar un mensaje y luego extraer códigos, enlaces y archivos adjuntos.

Las funciones y los planes de los proveedores cambian, así que confirma los datos actuales en cada sitio oficial antes de vincular una suite de pruebas a uno de ellos.

Cuándo es mejor opción un buzón de empresa con etiquetas plus

Las etiquetas plus permiten que un buzón de empresa acepte muchas variaciones de dirección. El correo enviado a qa+signup o qa+reset en el dominio de tu empresa llega al buzón de qa, donde puedes filtrarlo por etiqueta. Google Workspace lo admite, y Microsoft documenta que el direccionamiento plus en Exchange Online está activado por defecto, a menos que un administrador lo desactive.

Usa esta vía cuando un flujo maneje datos reales de clientes, dure más de un día, necesite respuestas o archivos adjuntos, o genere evidencias que un auditor pueda solicitar. Ten en cuenta los límites. Las etiquetas son variaciones de un mismo buzón, no bandejas de entrada separadas, así que las pruebas en paralelo pueden leer los mensajes de las demás. Algunos formularios de registro rechazan el signo más, y algunas apps tratan las variantes con etiqueta como la misma cuenta. Ambos comportamientos merecen un caso de prueba propio.

Cómo hacer una prueba de registro manual con una bandeja de entrada temporal

Una prueba de registro manual que usa correo temporal para las pruebas necesita tres cosas: una dirección nueva, la compilación que estás probando y un lugar fuera de la bandeja de entrada para registrar lo que llegó. Ejecútala solo contra sistemas que sean tuyos o que estés autorizado a probar.

1. Abre una bandeja de entrada. Crea una bandeja de entrada temporal gratuita en la web, o usa la app de Tmailor o el bot de Telegram, y copia la dirección. En un ordenador de escritorio, la extensión del navegador Tmailor también puede rellenarla en el campo de correo de tu compilación de prueba.
2. Regístrate en tu compilación de prueba. Usa la dirección en tu entorno de staging o QA y anota la hora a la que enviaste el formulario.
3. Espera el correo. Comprueba qué mensaje llegó, el nombre del remitente y la dirección From, el asunto y cuánto tardó.
4. Completa el paso. Haz clic en el enlace o introduce el código. Confirma que la cuenta cambia de estado una sola vez y que reutilizar el mismo enlace falla con un mensaje claro.
5. Registra la evidencia en otro lugar. Copia el enlace, el código, las marcas de tiempo y una captura de pantalla en tu caso de prueba. Los mensajes se conservan unas 24 horas desde su llegada, así que la bandeja de entrada no es tu registro de pruebas.
6. Guarda el access token si vas a volver a probar. El token vuelve a abrir la misma dirección más adelante, por ejemplo, para repetir un restablecimiento de contraseña. No restaura los mensajes que ya caducaron, y un token perdido no se puede recuperar.

Cuando una sesión necesita varios perfiles a la vez, como un usuario gratuito, un usuario de prueba y un compañero invitado, la vista de múltiples bandejas de entrada mantiene hasta cinco direcciones una al lado de otra en una sola pestaña del navegador. Cada perfil tiene su propia dirección, así que puedes ver qué correo pertenece a cada cuenta.

Esta vista sigue siendo manual. Las bandejas de entrada las crea una persona en un navegador, no las aprovisiona el código, así que no sustituye a una API de bandeja de entrada alojada para ejecuciones paralelas sin supervisión.

¿Una bandeja de entrada o una dirección por prueba?

Una sola bandeja de entrada compartida está bien para una comprobación rápida, pero enseguida se vuelve caótica. Cuando varias pruebas se ejecutan a la vez, los asuntos parecidos dificultan saber qué correo pertenece a qué script, y la depuración se convierte en pura conjetura.

Una dirección por caso de prueba resuelve eso. Los registros, las capturas de pantalla y los correos coinciden, y un mensaje que falta apunta a un solo escenario en lugar de a todos. La guía sobre gestionar múltiples buzones de entrada temporales explica ese flujo de trabajo con más detalle.

Algunos recorridos necesitan la misma dirección días después, como una prueba que se convierte en pago o un usuario que vuelve tras abandonar. Una dirección de correo temporal reutilizable mantiene la dirección disponible a través de su token de acceso, pero no el correo. Guarda los enlaces y códigos que necesites a medida que se ejecuta cada paso, y traslada a un buzón de la empresa cualquier paso que dependa de mensajes antiguos. Si quien prueba inicia sesión en una cuenta gratuita de Tmailor antes de crear direcciones de persona, cada una se guarda en Correos creados, así que perder un token ya no significa perder una dirección.

Qué revisar en los correos de registro e incorporación

Empieza con un inventario de todos los correos que el recorrido puede enviar y luego decide qué debe comprobar cada prueba. A menudo los equipos descubren correos adicionales solo cuando aparecen a mitad de la prueba, después de que un experimento de crecimiento o un cambio de seguridad añadiera uno que nadie había anotado.

Correos de un recorrido de registro típico

• Enlace de verificación o código de un solo uso
• Correo de bienvenida y cualquier secuencia de inicio rápido
• Inicio de sesión con enlace mágico
• Restablecimiento de contraseña
• Cambio de dirección de correo electrónico, enviado tanto a la dirección antigua como a la nueva
• Alerta de seguridad por nuevo dispositivo o nueva ubicación
• Recordatorios para registros que nunca se completaron

Para cada uno, anota el desencadenante, el momento esperado y las condiciones que lo modifican, como el plan, la región o el idioma. Define la ventana de entrega permitida según el requisito documentado de tu producto, en lugar de asumir un umbral universal; un mensaje de verificación inmediata y una secuencia de bienvenida programada requieren expectativas distintas. Una vez definidas esas expectativas, cada prueba tiene algo concreto con lo que comparar.

Qué comprobar en cada correo de prueba

• Remitente y destinatario: el nombre y la dirección del remitente, el Reply-To y la dirección exacta del destinatario.
• Asunto y cuerpo: tanto la versión HTML como la de texto plano, con nombres, detalles del plan e idioma correctos.
• Enlaces: el destino y si apunta al entorno correcto. Un correo de staging que enlaza a producción es un error real.
• Códigos: formato, longitud, texto de caducidad y si la caducidad indicada coincide con la que aplica el servidor.
• Tiempo: cuánto tardó en llegar el mensaje tras el desencadenante.
• Adjuntos: si un flujo envía un PDF o una factura, pruébalo en un buzón de la empresa o en una herramienta de prueba. Tmailor no recibe archivos adjuntos.

Una advertencia sobre el renderizado. Un buzón temporal muestra cómo un visor web muestra tu HTML. No te dice cómo se ve el mismo correo en Gmail, Outlook, Apple Mail, en modo oscuro o en la pantalla pequeña de un móvil, así que planifica comprobaciones de renderizado aparte si te importan.

Flujos de cambio de correo y recuperación de cuentas

Los flujos de recuperación fallan de forma más silenciosa que el registro. Comprueba que un cambio de correo envía una confirmación a la nueva dirección y un aviso a la antigua, que un enlace de restablecimiento usado no se puede reutilizar, que un enlace de restablecimiento antiguo deja de funcionar tras enviar uno nuevo, y que un enlace abierto en un segundo dispositivo deja al usuario en un estado razonable. Los flujos OTP merecen una revisión de riesgos aparte; la lista de verificación de riesgos OTP para QA y UAT cubre métricas, ventanas de reenvío y titularidad.

Cómo probar casos límite de OTP y verificación

Prueba los flujos OTP y de verificación frente a entregas retrasadas, reenvíos, códigos caducados e incorrectos, y enlaces abiertos en otro dispositivo. Cada caso debe comprobar tanto el resultado del servidor como el mensaje que se muestra al usuario. Realiza estas pruebas solo en sistemas que sean tuyos o que estés autorizado a probar. Las buenas pruebas OTP rompen el flujo a propósito:

• Llegada lenta: espera antes de revisar la bandeja de entrada y confirma que la interfaz explica lo que está ocurriendo y ofrece una forma clara de reenviar.
• Comportamiento del reenvío: solicita un segundo código y comprueba si el primero queda invalidado o se sigue aceptando.
• Caducidad: introduce un código después de su vida útil indicada y confirma que el mensaje de error coincide con lo ocurrido.
• Código incorrecto: confirma que el límite de intentos y el texto del tiempo de espera tienen sentido para una persona.
• Enlaces mágicos entre dispositivos: solicita un enlace en un portátil, ábrelo en un teléfono y comprueba dónde acaba el usuario.

Para una visión más amplia de qué códigos llegan a una bandeja de entrada temporal y cuáles no, consulta esta guía sobre correo temporal para códigos OTP.

Si tu producto rechaza a propósito los dominios de correo desechable, prueba esa ruta directamente. Confirma que el mensaje de rechazo es claro y que una dirección real o controlada por la empresa sigue completando el registro. No vayas alternando entre otros dominios temporales para sortear el bloqueo, ni en tu propio producto ni en el de nadie más. Confirmar que el bloqueo funciona es la prueba; sortearlo no lo es. Esta explicación sobre por qué los sitios web bloquean dominios de correo temporal cubre las razones que hay detrás de esos filtros.

Qué cambia cuando las pruebas de correo se ejecutan sin supervisión

Cuando nadie está mirando, la prueba necesita una bandeja de entrada que pueda leer mediante código. Eso significa la API de un capturador SMTP o una API de bandeja de entrada alojada. La bandeja de entrada web de Tmailor no es esa herramienta, pero la API de Correo Temporal de Tmailor sí lo es: las pruebas pueden crear direcciones de solo recepción, listar y leer mensajes, y obtener el código de un solo uso o el enlace de verificación que encuentra la API. Un servidor MCP permite que agentes de IA como Claude, Cursor o VS Code Copilot hagan lo mismo con los flujos de registro que son tuyos o que tienes permiso para probar.

Algunos hábitos mantienen estables las pruebas de correo sin supervisión, sea cual sea la herramienta que elijas:

• Asigna a cada ejecución de prueba su propia dirección y un ID de correlación, para que un correo tardío de una ejecución anterior no pueda satisfacer la aserción equivocada.
• Usa una espera dedicada a la llegada del correo, con un retroceso razonable, separada del tiempo de espera total de la prueba, y registra cuánto tardó cada mensaje.
• Identifica el mensaje exacto por destinatario y asunto en lugar de leer "el último correo".
• Enmascara los códigos y los enlaces mágicos en los registros de CI, ya que los registros suelen durar más que la bandeja de entrada.

Además, ten claro qué demuestra una prueba superada. "La aplicación generó y entregó el correo", "un dominio de prueba alojado lo recibió a través de la infraestructura pública de correo" y "Gmail lo colocó en la bandeja de entrada, no en spam" son tres hechos diferentes. Un capturador SMTP demuestra el primero, una API de bandeja de entrada alojada demuestra los dos primeros, y ninguna de las dos demuestra el tercero. Para configurar pipelines en GitHub Actions, GitLab CI y CircleCI, consulta la guía sobre pruebas de correo electrónico en pipelines CI/CD.

Mantén seguros los datos de prueba y cumple las normas

Usa identidades sintéticas y contenido no sensible en las bandejas de entrada temporales de prueba, y ejecuta las pruebas de registro solo contra sistemas que sean tuyos o que estés autorizado a evaluar. Mantén las cuentas de QA fuera de la analítica de producción, respeta los límites de tasa y traslada los datos regulados, las credenciales, los archivos adjuntos y las evidencias conservadas a sistemas aprobados y controlados por la empresa.

• Ningún dato real en una bandeja de entrada temporal. Nunca envíes registros reales de clientes, credenciales, claves API ni datos regulados a una dirección de correo temporal. Usa usuarios sintéticos con nombres obviamente falsos.
• Prueba solo lo que tienes permiso para probar. Ejecuta las pruebas de registro contra tu propio producto o contra un sistema que estés autorizado a probar, y respeta los límites de tasa y las condiciones de ese servicio. No uses el correo temporal para crear cuentas de forma masiva en sitios de terceros. Las pruebas de volumen y de carga corresponden a tu propio entorno de staging, con un capturador SMTP o una API de bandeja de entrada alojada.
• Mantén el tráfico de QA fuera de las cifras de producción. Etiqueta claramente las cuentas de prueba y exclúyelas de los paneles de analítica y crecimiento. Evita enviar grandes volúmenes de correo de prueba desde tu dominio de envío de producción, donde los rebotes y las quejas pueden perjudicar su reputación.
• Deja la política por escrito. Indica qué flujos pueden usar una bandeja de entrada temporal, cuáles necesitan un buzón de la empresa, cuánto tiempo se conservan los datos de prueba y quién tiene acceso. Las revisiones de seguridad y cumplimiento avanzan más rápido cuando los límites ya están sobre el papel.

Cuando seguridad pregunte cómo gestiona un proveedor los datos, fíjate en lo que recopila, cuánto tiempo conserva los mensajes y cómo funciona el acceso. Esta visión general sobre el correo temporal y la privacidad en línea cubre esas preguntas desde el punto de vista del usuario. La decisión sobre qué flujos pueden usar bandejas de entrada desechables sigue correspondiendo a tus propios equipos legal, de privacidad y de seguridad.

Límites a tener en cuenta al planificar

La bandeja de entrada web de Tmailor sirve para revisiones manuales breves de correo entrante no sensible (la automatización es para lo que está la API de Correo Temporal). Antes de elegirla, decide si el flujo de trabajo necesita acciones salientes, archivos adjuntos, evidencias duraderas o recuperación duradera de la dirección. Cualquiera de esos requisitos exige un buzón controlado por la empresa o una herramienta especializada en pruebas; la lista de comprobación que aparece a continuación explica por qué.

• Tmailor es de solo recepción. Puede comprobar el correo entrante de registro, verificación y OTP, pero no los flujos de respuesta ni nada que se envíe desde la dirección.
• Tmailor no recibe archivos adjuntos, por lo que los correos de facturas, contratos o entrega de documentos necesitan un buzón de la empresa o una herramienta de prueba.
• Los mensajes permanecen disponibles unas 24 horas desde su llegada. Exporta los enlaces, códigos y marcas de tiempo que necesitará una investigación más larga.
• Un token de acceso reabre una dirección, no los mensajes caducados, y un token perdido no se puede recuperar.
• La bandeja de entrada web la lee una persona. La lectura desatendida de la bandeja de entrada requiere un capturador SMTP o una API de bandeja de entrada alojada, como la API de correo temporal de Tmailor.
• Algunos servicios bloquean los dominios de correo desechable. Si un flujo que pruebas hace esto a propósito, valídalo con una dirección real o controlada por la empresa.

Elegir la bandeja de entrada de prueba adecuada

Elige la bandeja de entrada según lo que la prueba deba demostrar. Usa un dominio de ejemplo reservado cuando la entrega no sea necesaria, una bandeja de entrada temporal para comprobaciones manuales no sensibles, un buzón de la empresa para recorridos que deban conservarse o sean sensibles, un capturador SMTP cuando controles la configuración de salida y una API de bandeja de entrada alojada para pruebas de extremo a extremo desatendidas.

Para los casos manuales, abre una bandeja de entrada temporal y empieza por el flujo de registro que vayas a lanzar a continuación. El correo temporal tiene muchos usos prácticos más allá de QA.