Direcciones de correo de prueba para desarrolladores y QA: lo que el entorno de pruebas oculta en el correo transaccional

30 de octubre de 2026 · 27 min de lectura · Por Equipo editorial de VookMail

Digamos que tu equipo lanza un nuevo correo de restablecimiento de contraseña. QA lo da por bueno en el entorno de pruebas: el mensaje aparece, el enlace funciona, la plantilla se ve bien. Dos días después del lanzamiento, soporte tiene una cola de tickets. Las personas con direcciones de Gmail dicen que el correo nunca llegó. Las de unas cuantas grandes empresas dicen que llegó, pero que el enlace estaba «ya usado» la primera vez que hicieron clic. Nadie cambió el código entre el entorno de pruebas y producción, y todas las pruebas siguen pasando.

Entonces, ¿qué correo de prueba para desarrolladores habría detectado esto? Ninguno por sí solo. Un receptor SMTP local sirve para el desarrollo diario, el sandbox de tu proveedor o un dominio de pruebas que controles sirve para las pruebas automáticas, y una bandeja externa real sirve para la comprobación manual de que el correo sale de tu entorno parecido a producción y llega al dominio de un desconocido. Una bandeja temporal como VookMail cubre ese último caso sin configuración, porque la dirección está lista al cargar la página. Las cuentas semilla en los grandes proveedores de buzones cubren después lo que ninguna de las otras puede ver. El resto de esta guía trata de elegir entre esas opciones, leer los fallos cuando ocurren y las comprobaciones que pertenecen a un lanzamiento.

Por qué ese restablecimiento pasó en el entorno de pruebas

El entorno de pruebas y producción rara vez se parecen tanto como sugiere el diagrama de despliegue, y el correo expone las diferencias más que la mayoría de las funciones. Un mensaje pasa por tu aplicación, una cola, un proveedor, el DNS, el servidor del destinatario y el cliente del destinatario. El entorno de pruebas puede usar una versión distinta de casi todo eso.

Toma el primer ticket, los usuarios de Gmail que no recibieron nada. Supón que el entorno de pruebas envía a través de un subdominio del proveedor autenticado hace meses, mientras que producción envía desde un nuevo dominio From introducido con el cambio de marca. Las directrices de remitentes de Google exigen que todos los remitentes se autentiquen con SPF o DKIM, y la tabla de errores de Gmail lista 5.7.26 para el correo no autenticado. Un buzón interno de QA en tu propio dominio podría dejar pasar el mismo mensaje, ya que tu propio servidor puede confiar en tu propio relé. La prueba nunca podía fallar.

El segundo ticket, el del enlace «ya usado», tiene otra causa. Las pasarelas de seguridad corporativas suelen abrir los enlaces del correo entrante para analizarlos antes de que la persona lo vea. Si tu enlace canjea el token con una simple solicitud GET, el escáner lo consume y el empleado hace clic en un enlace muerto. Ningún buzón de pruebas tuyo ejecuta ese escáner, a menos que tu propia empresa use uno.

Estos dos errores no se pueden ver desde el mismo sitio. Uno necesita una entrega real a un sistema receptor que no gestionas. El otro necesita un cambio en cómo se comporta el enlace, algo que una revisión detectaría más fácilmente que una prueba. Ese es el argumento para probar por capas: cada tipo de dirección responde a una pregunta y calla sobre las demás.

Lo que suele diferir entre pruebas y producción	Lo que puede ocultar
Dominio de envío y dirección `From`	SPF y DKIM ausentes o desalineados
Cuenta o subcuenta del proveedor	Modo sandbox, límites de envío, otra reputación de IP
Destinatarios	Dominios internos que confían en ti y listas de permitidos que ocultan direcciones erróneas
Seguimiento de clics	Enlaces reescritos que se rompen, o un dominio de seguimiento sin certificado válido
Volumen	Colas y límites de velocidad que solo muerden bajo carga
Listas de supresión	Direcciones de producción que rebotaron una vez y ahora se omiten en silencio
Ajustes de la URL base	Enlaces que apuntan al host equivocado

Qué dirección responde a qué pregunta

Estas son las opciones, cada una con la pregunta a la que realmente puede responder.

Un receptor local: «¿qué produjo mi app?»

Un receptor SMTP acepta todo lo que envía tu app y lo muestra en una página web sin entregar nada. Mailpit es una opción popular de código abierto. Por defecto escucha SMTP en el puerto 1025 y sirve su interfaz web en el puerto 8025, así que apuntas tu configuración de desarrollo a localhost:1025 y abres http://localhost:8025. Ethereal, de Nodemailer, es una idea parecida con un servicio SMTP falso alojado. Un receptor es rápido y privado, y te permite enviar a cualquier dirección sin riesgo de llegar a una persona real. Tampoco dice nada sobre DNS, autenticación o filtrado, porque nada cruza internet.

Un asistente de pruebas del framework: «¿pidió mi código el correo correcto?»

La mayoría de los frameworks pueden registrar el correo saliente en memoria durante una ejecución de pruebas. Laravel tiene Mail::fake(), Django reúne los mensajes en django.core.mail.outbox y Rails tiene ActionMailer::Base.deliveries. Úsalos para comprobar que una tarea se dispara una vez con el destinatario y el token correctos. Son la respuesta más rápida que puedes obtener, y prueban todavía menos del mundo exterior que un receptor.

El modo de prueba de un proveedor: «¿funciona mi integración?»

Los proveedores ofrecen distintos tipos de ayuda aquí, y las diferencias importan. Amazon SES tiene un simulador de buzón con direcciones como success@simulator.amazonses.com, bounce@simulator.amazonses.com y complaint@simulator.amazonses.com, que producen esos resultados sin dañar tu reputación. Una cuenta nueva de SES también empieza en un sandbox donde solo puede enviar a direcciones verificadas. El modo sandbox de SendGrid, que se activa con mail_settings.sandbox_mode.enable, valida tu solicitud sin entregar. Postmark acepta el token POSTMARK_API_TEST para el mismo fin. Sirven para errores de API y para los webhooks de rebotes y quejas, y no demuestran que el correo llegara a nadie. Consulta la documentación actual de tu proveedor, porque estas funciones cambian.

Un dominio de pruebas propio: «¿funciona el flujo completo, una y otra vez?»

Para las pruebas automáticas de extremo a extremo, configura un dominio o subdominio que controles, con un buzón comodín o un webhook de entrada, para que tu código de pruebas pueda leer el correo mediante una API. Cuesta algo de esfuerzo montarlo, pero es privado y estable, y no depende del sitio web de nadie más. No inventes direcciones en dominios que no son tuyos. Alguien puede ser dueño de testuser@gmail.com, y recibirá lo que envíes. La RFC 2606 reserva example.com y los nombres de nivel superior .test y .example para que la documentación y los datos de prueba tengan un lugar seguro adonde apuntar. Esos nombres no pueden recibir correo, lo que los hace adecuados para datos de ejemplo e inútiles para pruebas de entrega.

Una bandeja temporal externa real: «¿lo recibiría el dominio de un desconocido?»

Aquí es donde una bandeja temporal se gana su lugar. Es un buzón real en un dominio que no controlas y para el que no tienes lista de permitidos. Tu mensaje tiene que encontrar el registro MX, abrir una conexión SMTP y ser aceptado. En VookMail, los registros MX de los dominios apuntan a un proveedor de entrega de correo que recibe el mensaje y lo reenvía por HTTPS. Una dirección nueva también significa que no hay historial: ni mensajes antiguos, ni rebotes anteriores en tu lista de supresión, ni filtros. Eso la convierte en una forma rápida de reproducir «me registré con una dirección nueva y no recibí nada». También es útil para quienes no son desarrolladores. Un diseñador o un responsable de producto puede leer lo que recibe un usuario nuevo sin acceso a tus herramientas.

Cuentas semilla en grandes proveedores de buzones: «¿dónde aterriza?»

Un mensaje entregado en un dominio no te dice nada sobre la carpeta de spam de otro. Mantén un pequeño conjunto de cuentas reales en los proveedores que usan de verdad tus usuarios y comprueba la ubicación antes de cambios importantes de plantilla o de dominio. Después vigila las cifras de rebotes y quejas tras un lanzamiento. Si tu correo parece un problema de spam, estas cuentas son donde lo verás primero.

Enfoque	Cruza internet	Configuración	Automatización	Privacidad del contenido	Mejor fase
Asistente de pruebas del framework	No	Ninguna	Excelente	Se queda en el proceso	Pruebas unitarias y de funcionalidad
Receptor SMTP local	No	Baja	Buena	Se queda en local	Desarrollo
Modo de prueba del proveedor	Normalmente no	Baja	Buena	Se queda con el proveedor	Pruebas de integración
Tu propio dominio de pruebas	Sí	Media a alta	Buena	Lo controlas tú	Extremo a extremo en CI, entorno de pruebas
Bandeja temporal	Sí	Ninguna	No recomendada	Trátala como pública	QA manual y comprobaciones previas al lanzamiento
Cuentas semilla	Sí	Media	Limitada	Moderada	Comprobaciones de ubicación

Una pasada manual con una bandeja temporal

Este es un recorrido repetible por un flujo de registro en el entorno de pruebas o en uno previo a producción. Debería llevar unos diez minutos cuando lo conozcas.

Confirma que el entorno usa la misma configuración de proveedor que producción, salvo las credenciales, y que solo contiene datos inventados. Si no es así, anótalo, porque limita lo que puedes concluir.
Abre VookMail y pulsa Nuevo. Escribe un nombre de usuario que codifique la prueba, como email-signup-03-x7, elige uno de los más de 30 dominios y pulsa la flecha. Usa el botón amarillo «Aleatorio» si algo del correo pudiera ser sensible, porque cualquiera que conozca o adivine una dirección puede abrir esa bandeja.
Pulsa Copiar y regístrate como un usuario nuevo con datos de perfil inventados.
Anota la hora a la que enviaste el formulario y la hora a la que aparece el mensaje. La bandeja comprueba cada pocos segundos, así que una diferencia de minutos apunta a tu cola o a tu proveedor. Pulsa Actualizar si quieres estar seguro.
Lee el mensaje como lo haría un usuario nuevo: nombre del remitente, asunto, texto de vista previa, cuerpo, botón, enlace simple, pie. VookMail muestra los códigos y enlaces de confirmación detectados sobre el mensaje, lo que sirve como comprobación aproximada de que tu código y tu enlace se distinguen fácilmente.
Míralo con las imágenes desactivadas. VookMail mantiene las imágenes desactivadas hasta que las permites y elimina los píxeles de seguimiento ocultos. Si el mensaje no tiene sentido en ese estado, algunos de tus usuarios ven lo mismo. No uses esta bandeja para juzgar tu seguimiento de aperturas, sin embargo, porque los píxeles no se activarán.
Pulsa el botón QR, escanea la dirección con un teléfono de pruebas y abre allí la misma bandeja para tocar el enlace real en un dispositivo real, sobre todo si usas enlaces universales o enlaces de app.
Completa la verificación y confirma que el estado de la cuenta cambia como debe.
Ejecuta los casos negativos de la lista de comprobación de abajo: reutilizar el enlace, esperar a que caduque, pedir un reenvío.
Guarda tus pruebas: capturas de pantalla, marcas de tiempo y la dirección usada. Los mensajes se eliminan pasado aproximadamente un día, así que un informe de error escrito la semana que viene no tendrá nada a lo que apuntar.
Pulsa Eliminar y borra la cuenta de prueba si tu proceso lo exige.

Se pueden mantener varias direcciones en un mismo navegador, de modo que quien invita y quien es invitado, o la dirección antigua y la nueva de un cambio de correo, pueden estar abiertas a la vez. Si adjuntas archivos en tu prueba, recuerda que VookMail rechaza los archivos de programa comunes, como .exe, y muestra una advertencia con los archivos comprimidos, así que un adjunto rechazado allí puede no ser un error de tu lado.

Leer un fallo

«El correo nunca llegó» describe un síntoma que puede estar en unos seis lugares, y los equipos pierden horas empezando por el equivocado. Avanza por el camino desde tu código hacia fuera y detente en el primer punto donde ya no puedas ver el mensaje.

¿Lo intentó la app? Busca en el registro de la aplicación el intento de envío y cualquier excepción. Busca una tarea que nunca se creó, a menudo porque una condición o un indicador de función era falso.
¿Se ejecutó el worker? Revisa las tareas atascadas, fallidas o reintentadas. Un worker de cola que no se reinició tras un despliegue puede ejecutar código antiguo, y una política de reintentos puede enviar duplicados.
¿Lo aceptó el proveedor? Busca el destinatario o el Message-ID en el registro de actividad de tu proveedor. Aceptado, diferido, rebotado y descartado son cuatro historias distintas.
¿Fue suprimido? Si esa dirección rebotó o presentó una queja antes, muchos proveedores omiten en silencio los envíos futuros. Esto suele pillar a los probadores que reutilizan una dirección antigua.
¿Qué dijo el servidor receptor? Los registros del proveedor suelen mostrar la respuesta SMTP, y ese texto es la línea más útil de toda la investigación.
¿Es correcto el DNS? Comprueba SPF, DKIM y DMARC del dominio de envío real.
¿Está ahí pero oculto? Las carpetas de spam, las pestañas y los filtros del cliente van al final, cuando una cuenta semilla puede mostrártelo.

Lo que te dice la respuesta SMTP

Según la RFC 5321, una respuesta que empieza por 4 es un fallo temporal, y el remitente debe volver a intentarlo más tarde. Una respuesta que empieza por 5 es permanente. Los códigos de estado mejorados de la RFC 3463 añaden detalle a continuación. Una línea de registro inventada podría verse así, solo como ejemplo del formato:

Solo un ejemplo: to=user@gmail.example status=bounced reply="550 5.7.26 unauthenticated sender"

Léela de izquierda a derecha. El 5 significa que los reintentos no ayudarán. La familia 5.7 tiene que ver con la seguridad o las políticas, lo que te manda al DNS y a la firma, y te aleja de la dirección del destinatario. La tabla siguiente te da un punto de partida para los patrones comunes.

Lo que ves	Capa más probable	Primer sitio donde mirar
Nada en el registro del proveedor	App o cola	Registros de la aplicación y tareas fallidas
El proveedor dice «dropped» o «suppressed»	Lista de supresión del proveedor	Quita la dirección de prueba o usa una nueva
La API devuelve éxito, pero nada se registra nunca como enviado	El modo sandbox sigue activo	Ajustes del proveedor para ese entorno
`5.1.1` o similar	Dirección del destinatario	Errores de escritura y validación del formulario que alteró la dirección
`5.7.26` en Gmail	Autenticación	SPF, DKIM y alineación con el dominio `From`
Aplazamientos `4xx` que se resuelven pasado un tiempo	El receptor te está frenando	Volumen, reputación o una IP de envío nueva
Entregado en una bandeja externa, ausente en Gmail	Política o filtrado del receptor	Cuentas semilla y las directrices de remitentes de Google
Llega, pero el enlace dice «ya usado»	Un escáner precarga el enlace	Canjea los tokens con POST, no con GET
El enlace lleva a una advertencia de seguridad	Dominio de seguimiento de clics	Certificado del subdominio de seguimiento
Llega dos veces	Lógica de reintentos	Idempotencia de la tarea y los tiempos de espera que provocan reintentos
Llega muy tarde	Cola	Capacidad del worker y si el correo de restablecimiento comparte cola con el correo masivo

Esa última fila es un punto de diseño que merece una frase más. Si los restablecimientos de contraseña comparten cola con el envío de un boletín, esperan detrás de él. Da al correo transaccional su propia cola, e idealmente su propio subdominio y su propio flujo de envío, para que un problema de marketing no retrase un inicio de sesión.

Comandos que acortan la búsqueda

Puedes comprobar la mayor parte de esto sin salir de tu terminal. En estos ejemplos, sustituye los nombres de ejemplo por los tuyos.

dig +short MX example.com muestra dónde recibe correo un dominio. Una respuesta vacía requiere mirar más de cerca, ya que la RFC 5321 permite a los remitentes recurrir a un registro de dirección, mientras que una respuesta 0 . es un MX nulo según la RFC 7505, lo que significa que el dominio no acepta correo en absoluto.
dig +short TXT example.com muestra el registro SPF entre otros registros de texto.
dig +short TXT selector._domainkey.example.com muestra una clave DKIM. Toma el selector real del valor s= de la cabecera DKIM-Signature del mensaje.
dig +short TXT _dmarc.example.com muestra la política DMARC.
openssl s_client -starttls smtp -connect smtp.example.com:587 comprueba que puedes llegar a tu relé y muestra su certificado. Un fallo aquí indica un problema de cortafuegos o de TLS, mucho antes de cualquier cuestión de contenido.
swaks --to qa@example.test --from app@example.test --server localhost:1025 envía a mano un mensaje sencillo. Se salta tu app, así que puedes saber si un problema pertenece a tu código o a la ruta.

Para obtener pruebas a nivel de cabeceras, la vista más fiable es un buzón que controles en un gran proveedor. En Gmail, abre el mensaje, usa el menú de tres puntos y elige Mostrar original, que enumera los resultados de SPF, DKIM y DMARC en la parte superior. Ten en cuenta que el «pass» de un receptor no garantiza el de otro.

Qué comprobar en cada flujo

«¿Llegó?» es la primera pregunta, y normalmente la menos interesante. Después, cada flujo tiene sus propias formas de fallar.

Restablecimiento de contraseña

La Forgot Password Cheat Sheet de OWASP es la referencia sobre la que construir aquí. Pide un mensaje coherente exista o no la cuenta, respuestas que tarden un tiempo uniforme, tokens aleatorios, largos, almacenados de forma segura y de un solo uso, y Referrer-Policy: no-referrer en la página de restablecimiento.

La página de solicitud muestra el mismo mensaje para direcciones registradas y no registradas, y tarda más o menos lo mismo. Una respuesta instantánea para direcciones desconocidas filtra tanto como lo haría la redacción.
El enlace funciona una vez. Ábrelo una segunda vez y obtienes una explicación clara con una forma de solicitar otro.
Solicitar un nuevo restablecimiento invalida los enlaces anteriores, o tu diseño dice otra cosa a propósito.
El servidor aplica la caducidad y se ha probado esperando, o cambiando la hora en un entorno de pruebas.
Un restablecimiento correcto envía un correo de confirmación, y las demás sesiones se gestionan según tu política.
Abrir el enlace no cambia nada por sí solo. El token se canjea al enviar el formulario.
La página de restablecimiento no envía su URL a analítica de terceros ni a seguimiento de errores.
Los límites de velocidad se aplican por cuenta además de por IP, para que nadie pueda inundar la bandeja de un desconocido.
Las direcciones con mayúsculas y minúsculas mezcladas o con signo más funcionan igual que las sencillas.

Verificación de registro

Un registro envía un mensaje, también cuando se reintenta la tarea.
El enlace o el código funciona una vez, y la página de enlace caducado ofrece una salida.
Un reenvío invalida el token anterior o convive con él según el diseño, y tiene límite de velocidad.
Las cuentas sin verificar tienen exactamente las restricciones que pretendías.
Registrarse otra vez con una dirección ya registrada no le dice a un visitante anónimo que la cuenta existe, si tu producto lo considera sensible. Un patrón habitual es enviar un correo al titular existente.
El enlace apunta al entorno correcto. Un mensaje del entorno de pruebas que enlaza a producción acabará tarde o temprano cambiando datos de producción.

Códigos de inicio de sesión y enlaces mágicos

Los códigos son lo bastante largos, caducan rápido y tienen un límite de intentos.
Los enlaces mágicos muestran una página de destino con un botón y se canjean con ese POST, de modo que el GET de un escáner no hace daño.
Abrir el enlace en otro dispositivo hace lo que dice tu diseño, y el usuario puede saber qué ocurrió.
La línea de asunto lleva un código solo si has decidido que es aceptable, ya que las notificaciones lo muestran en la pantalla de bloqueo.

Cambio de dirección de correo

La confirmación va a la nueva dirección, y nada cambia hasta que se confirma.
Se envía un aviso a la dirección antigua, para que el verdadero titular pueda reaccionar ante un cambio no autorizado.
Los tokens de restablecimiento pendientes dejan de funcionar tras el cambio.
Dos bandejas temporales hacen que este caso sea rápido de ejecutar a mano.

Invitaciones, recibos y notificaciones

Una invitación a una persona sin cuenta lleva al registro con la dirección rellenada o bloqueada, según el diseño. Una invitación caducada o revocada lo dice.
Una invitación no puede ser aceptada por una cuenta distinta salvo que tu diseño lo permita.
Los recibos muestran importes, monedas, fechas y zonas horarias correctos para la configuración regional del usuario, y los adjuntos tienen nombres razonables y se abren bien.
Los cambios de preferencias surten efecto en el siguiente envío.
El correo no esencial tiene una baja que funciona, y el correo de cuenta y de seguridad está claramente separado. Nuestro artículo sobre la sobrecarga de boletines muestra cómo se ve eso desde el lado del lector.
Existen plantillas traducidas para cada idioma compatible, con el diseño de derecha a izquierda correcto cuando corresponda, y sin fragmentos sin traducir en el asunto.

Revisar el código de los tokens

Probar a través de una bandeja muestra el comportamiento. Una breve revisión de código detecta fallos de diseño que ninguna bandeja te mostrará. Cuando leas el código que hay detrás del restablecimiento, la verificación y los enlaces mágicos, busca esto.

La fuente de aleatoriedad. Debe ser un generador criptográficamente seguro, como secrets.token_urlsafe(32) en Python, crypto.randomBytes(32) en Node o random_bytes(32) en PHP. Una marca de tiempo, un ID incremental o un hash del correo no es aceptable.
Longitud. Los tokens de los enlaces suelen llevar al menos 128 bits de aleatoriedad. Un código de seis dígitos solo vale con una caducidad ajustada y un límite de intentos.
Almacenamiento. Guarda un hash del token, para que la filtración de una base de datos no reparta enlaces de restablecimiento que funcionen.
Comparación. Usa una función de tiempo constante, como hmac.compare_digest, hash_equals o crypto.timingSafeEqual, donde compares valores secretos directamente.
Finalidad. Un token de verificación no debe servir como token de restablecimiento, y el token de una cuenta no debe servir para otra.
Caducidad. El servidor guarda la hora de caducidad, de modo que no se puede cambiar editando el enlace.
Invalidación. El uso del token, un cambio de contraseña por otra vía o un cambio de correo deben cancelar los tokens pendientes.
Registros. Las URL completas con tokens no deben llegar a los registros de la aplicación, a los eventos de analítica ni a los sistemas de seguimiento de errores. Revisa también tus registros de acceso HTTP.

Cabeceras y autenticación

Abre el código fuente en bruto en un receptor para ver lo que produjo tu app, y en un buzón que controles en un gran proveedor para ver lo que añadieron el proveedor y la red.

Cabecera o elemento	Qué verificar
`From`	El nombre de marca correcto, en un dominio que posees y autenticas
`Reply-To`	Un buzón vigilado, o ausente a propósito
`Return-Path`	El dominio de rebotes, alineado con tu dominio si dependes de SPF para DMARC
`DKIM-Signature`	Presente, con un dominio `d=` alineado con el dominio `From`
`Message-ID`	Presente y único, ya que es tu clave para rastrear en los registros del proveedor
`Content-Type`	`multipart/alternative` con partes en HTML y en texto plano
`List-Unsubscribe`, `List-Unsubscribe-Post`	Presentes en el correo masivo y de marketing, con baja de un clic según la RFC 8058
`Auto-Submitted`	`auto-generated` en el correo automático, como define la RFC 3834, para ayudar a evitar bucles de respuesta

Algunas reglas que conviene comprobar antes de lanzar un nuevo dominio de envío. Una evaluación de SPF no puede superar diez consultas DNS (RFC 7208), y pasarse del límite es una forma fácil de fallar tras añadir un proveedor más a tu registro. DKIM necesita que el registro de selector del proveedor esté publicado y se verifique. DMARC necesita un registro en tu dominio From, normalmente empezando en p=none con los informes activados y endureciéndolo una vez confirmada la alineación.

El volumen también cambia las reglas. Las directrices de Google consideran masivo a un remitente a partir de unos 5000 mensajes al día a cuentas personales de Gmail, y los remitentes masivos necesitan SPF, DKIM y DMARC, baja de un clic en el correo promocional y una tasa de spam notificado por los usuarios por debajo del 0,3 %, con un 0,1 % como objetivo recomendado. Otros proveedores tienen sus propias reglas. Amazon SES, por ejemplo, pone una cuenta en revisión con una tasa de rebotes del 5 % o una tasa de quejas del 0,1 %. Lee las cifras actuales en la documentación de tu proveedor antes de planificar en torno a ellas, porque cambian.

Manejo y validación de direcciones

Los formularios rechazan direcciones válidas con más frecuencia de la que la gente cree, y un error de validación previo puede parecerse exactamente a un fallo de entrega. Pruébalo con esto.

Entrada	Tratamiento esperado	Error común
`user+tag@example.com`	Aceptar	Una expresión regular rechaza el signo más
`User@Example.COM`	Aceptar, y tratar el dominio como insensible a mayúsculas	Cuentas duplicadas que solo difieren en las mayúsculas
`o'brien@example.com`	Aceptar	Se rechaza, o rompe una consulta o una plantilla si no se escapa
`first.last@sub.example.co.uk`	Aceptar	La validación asume un solo punto en el dominio
Espacios al principio o al final	Recortar primero	«Correo no válido» ante un pegado correcto
Una dirección muy larga	Aplicar 64 caracteres para la parte local y 254 en total	Una columna corta de la base de datos la trunca en silencio
Dominios y direcciones internacionalizados	Aceptar o rechazar de forma coherente, con un mensaje claro	Un fallo en la codificación o en el registro
Un dominio sin ruta de correo	Avisar o rechazar	Una cuenta que nunca puede verificarse

Valida de forma laxa en el formulario y deja que el correo de confirmación demuestre que la dirección funciona. Una expresión regular estricta te hace perder usuarios reales y te dice muy poco sobre si existe un buzón.

Si tu producto rechaza dominios desechables en producción, tu proceso de QA sigue necesitando una vía de paso en el entorno de pruebas. Las opciones incluyen una lista de permitidos de dominios de prueba fuera de producción, un indicador que desactive la comprobación en los entornos de prueba o tu propio dominio de pruebas. No debilites la regla de producción para facilitar las pruebas. Y si estás decidiendo si tener esa regla, nuestro artículo sobre por qué los sitios web bloquean el correo desechable expone los costes y beneficios desde la perspectiva del propietario.

Cómo se muestra

El renderizado es donde más ayuda la revisión de un diseñador, y necesita mensajes reales en clientes reales.

La parte de texto plano se lee bien e incluye el enlace completo. «Haz clic en el botón de abajo» no sirve allí.
El modo oscuro deja los logotipos visibles y mantiene el contraste. VookMail tiene modo oscuro, que es un comienzo, y los clientes que prefieren tus usuarios son la prueba real.
Con las imágenes bloqueadas, la llamada a la acción sigue siendo un enlace de texto real o un botón HTML.
Los botones son lo bastante grandes para tocarlos, y las URL largas no rompen el diseño en un teléfono.
El texto de vista previa está escrito a propósito, sin restos de texto de la plantilla.
Los encabezados son semánticos, el contraste es suficiente, el texto de los enlaces es descriptivo y el HTML tiene un atributo de idioma.
Los datos que faltan no producen «Hola {first_name}» ni «Hola ,».
El tamaño del mensaje se mantiene muy por debajo de unos 102 KB, el punto a partir del cual se informa ampliamente de que Gmail recorta los mensajes largos. El recorte puede ocultar tu pie y cualquier enlace de baja que esté en el cuerpo.

Salvaguardas contra accidentes

Los incidentes de correo embarazosos son sobre todo errores de configuración: correo del entorno de pruebas que llega a clientes reales, producción con una clave de prueba, enlaces a localhost. Unos pocos ajustes evitan la mayoría.

Mantén credenciales separadas por entorno, en variables de entorno o en un gestor de secretos. Fuera de producción, usa una lista de destinatarios permitidos para que el enviador entregue solo a dominios de prueba aprobados y redirija o descarte todo lo demás. Construye todos los enlaces a partir de un solo ajuste, como APP_URL, de modo que las plantillas no contengan hosts escritos a mano. Pon a los asuntos de fuera de producción un prefijo como [STAGING] para que un mensaje mal dirigido resulte evidente a quien lo reciba.

Si copias datos de producción al entorno de pruebas, sustituye cada dirección real por una sintética antes de que arranque cualquier worker de correo. El orden importa, porque un worker que arranca primero puede empezar enseguida a procesar el correo programado. Y controla el modo sandbox de forma deliberada en cada entorno. Lanzar con producción todavía en sandbox es un clásico: la API devuelve éxito, los registros parecen limpios y no sale ningún correo.

Las suites automáticas deben quedarse en infraestructura que controlas

Una bandeja temporal pública es la dependencia equivocada para CI. Rascar la página web de otro es frágil, y tus compilaciones fallarían por motivos ajenos a tu código. También pone tu tráfico de pruebas en un servicio que no gestionas. Los mensajes allí los puede leer cualquiera que tenga la dirección, así que nada automatizado debería depender de ellos.

Una disposición sensata se ve así. Los asistentes del framework comprueban que se solicita el correo correcto. Un contenedor de Mailpit en tu pila de pruebas recibe el mensaje real, y tu prueba lo lee mediante la API HTTP de Mailpit (GET /api/v1/messages), extrae el enlace y lo sigue. El modo de prueba del proveedor ejercita los webhooks y el manejo de errores. Un trabajo nocturno en tu propio dominio de pruebas envía a través del proveedor real y lee el resultado mediante un webhook de entrada, de modo que obtienes una señal diaria de que la entrega real sigue funcionando.

El correo temporal pertenece a las partes humanas de las pruebas: sesiones exploratorias en las que necesitas una identidad nueva rápidamente, una prueba de humo antes del lanzamiento, la reproducción del informe de un usuario, revisiones de texto y de diseño, y pruebas en un teléfono. Para esto último, el botón QR o la app de Google Play o de Huawei AppGallery lleva la bandeja a un dispositivo de pruebas. Comprueba que los enlaces abren tu app cuando está instalada y recurren a una página web que funciona cuando no lo está, y que la app detecta el estado verificado sin exigir un nuevo inicio de sesión.

Un caso de prueba que sobrevive a un traspaso

Los casos de prueba coherentes son más fáciles de repetir en cada versión y de pasar entre probadores. Este ejemplo tiene los campos que suelen importar.

Campo	Ejemplo
ID de la prueba	EMAIL-RESET-03
Flujo	Restablecimiento de contraseña, reutilización del token
Condiciones previas	Cuenta de prueba verificada en el entorno de pruebas, con una dirección temporal nueva
Pasos	Solicitar un restablecimiento, abrir el enlace, fijar una contraseña nueva, abrir el mismo enlace otra vez
Resultado esperado	El segundo uso explica que el enlace ya no es válido y ofrece una nueva solicitud
Pruebas	Capturas de pantalla, `Message-ID` si está disponible, marcas de tiempo, dirección usada
Entorno	Número de compilación del entorno de pruebas y configuración de correo

Poner el ID de la prueba en el nombre de usuario, como en email-reset-03-x7, vincula cada bandeja con su caso e impide que dos probadores choquen en una misma dirección. El breve sufijo aleatorio está ahí porque cualquiera puede abrir una bandeja si adivina el nombre.

Qué no enviar a una bandeja pública

Trata cualquier bandeja temporal como legible por cualquiera que conozca la dirección y prueba en consecuencia.

Envía solo datos sintéticos: nombres falsos, pedidos falsos, direcciones falsas. Los datos reales de clientes no pertenecen ahí y, según dónde operes, enviarlos también podría crearte un problema legal.
Nunca envíes claves de API, credenciales de bases de datos ni invitaciones de administrador de sistemas reales.
Elimina las cuentas de prueba con regularidad, sobre todo las privilegiadas. Un usuario administrador de pruebas vinculado a una bandeja pública es una vía de entrada si alguien más abre esa bandeja y pide un restablecimiento. Como la dirección no queda reservada para ti una vez borrada, ese riesgo persiste después de la prueba.
Nunca uses una dirección temporal como titular de una cuenta de producción real ni de un servicio de terceros del que dependa tu empresa.
Conoce el periodo de conservación. Los mensajes y los archivos adjuntos se eliminan pasado aproximadamente un día, y la política de privacidad tiene los detalles.

Probar tu propio producto es uno de los usos legítimos más claros del correo desechable. Mantenlo así: prueba sistemas que son tuyos o que estás autorizado a probar. No uses bandejas temporales para crear cuentas en servicios de otras empresas contra sus condiciones, para acumular pruebas gratuitas ni para someter a pruebas de carga el formulario de registro de otro. Los términos y condiciones cubren el uso aceptable, y la página de metodología explica cómo funciona el servicio. VookMail forma parte de la red de herramientas gratuitas de PAYATE.

Antes de lanzar

SPF, DKIM y DMARC verificados para el dominio de envío real de producción, con el dominio From alineado.
Enviador de producción con credenciales de producción, con el modo sandbox desactivado, confirmado con un mensaje real.
Verificación de registro recibida en una dirección externa nueva, enlace usado una vez, caducidad probada.
Restablecimiento de contraseña probado de extremo a extremo, incluidas las respuestas idénticas para direcciones desconocidas y el mensaje de confirmación.
Tokens de restablecimiento y de enlace mágico canjeados al enviar un formulario, para que el GET de un escáner no los consuma.
El cambio de correo envía tanto a la dirección nueva como a la antigua.
Todos los enlaces apuntan al host de producción por HTTPS, incluidos los reescritos por el seguimiento de clics.
Correo transaccional separado del correo masivo, al menos en su cola.
HTML y texto plano presentes y legibles, con el modo oscuro y las imágenes bloqueadas comprobados.
Una comprobación de ubicación en cuentas semilla si el dominio o la plantilla cambiaron de forma significativa.
Baja funcionando en el correo no esencial y plantillas traducidas revisadas.
Pruebas adjuntas al ticket de lanzamiento, y cifras de rebotes y quejas en un panel que alguien vigilará tras el lanzamiento.

Preguntas que se hacen los desarrolladores

Una bandeja real aceptó mi correo. ¿Estoy a salvo en Gmail?

No. La entrega en un dominio demuestra que tu mensaje salió, encontró una ruta y fue aceptado allí. Gmail aplica sus propias reglas de autenticación y filtrado, y lo mismo hace cualquier otro gran proveedor. Usa cuentas semilla y las Postmaster Tools de Google para esa pregunta.

¿Puedo reutilizar la misma dirección de prueba?

Puedes dentro de una sesión, pero una dirección nueva te da una prueba más limpia. Las direcciones antiguas acumulan entradas de supresión y mensajes viejos, y en un servicio temporal la bandeja se vacía pasado aproximadamente un día de todos modos.

El correo llega a mi receptor pero no al exterior. ¿Por dónde empiezo?

Un receptor demuestra que tu app produjo un mensaje y nada más, así que empieza por el registro de actividad del proveedor. La mayoría de las veces la respuesta es un ajuste de sandbox, una entrada de supresión, unas credenciales equivocadas o un rechazo SMTP que menciona la autenticación.

¿Cuánto tiempo debe seguir siendo válido un enlace de restablecimiento?

Lo bastante corto para limitar el daño y lo bastante largo para que llegue un correo lento. Muchos equipos se quedan entre 15 minutos y una hora, pero depende de tu riesgo y de la rapidez con que se entregue tu correo, y el correo de tus usuarios puede retrasarse más allá de tu control. Elijas lo que elijas, prueba el estado caducado y di a la gente qué hacer a continuación.