Pruebas e ingeniería·Actualizado 8 ago 2026

Lista de pruebas de correo para desarrolladores: de la solicitud a la caducidad

Un plan reproducible para comprobar generación, entrega, contenido, enlaces, adjuntos, accesibilidad y limpieza sin usar datos reales.

Revisado por Revisión editorial de Once Email

Qué te ayuda a hacer esta guía
El equipo obtiene una lista reutilizable con evidencias mínimas, tiempos UTC y criterios de resultado que reducen pruebas inestables.

Guía del artículo

Por qué vale la pena leer este artículo

Análisis original
Dividimos el recorrido en eventos observables para diferenciar defectos de aplicación, proveedor, transporte, renderizado y limpieza.
Contexto de tendencias
El correo transaccional combina más plantillas, localización, enlaces firmados y controles de autenticación, aumentando los puntos de fallo.
Valor práctico
El equipo obtiene una lista reutilizable con evidencias mínimas, tiempos UTC y criterios de resultado que reducen pruebas inestables.

Una prueba de correo completa no consiste solo en «el mensaje llegó». Debe demostrar que el evento correcto generó un único mensaje, que el destinatario y el contenido son adecuados, que los secretos caducan y que el entorno queda limpio.

1. Define el escenario

Especifica propósito, entorno, tipo de usuario y resultado esperado. Utiliza una cuenta y datos creados para la prueba. Nunca copies listas de clientes ni direcciones reales a un entorno de ensayo.

Registra un identificador de ejecución que no sea secreto y horas UTC para cada paso. Decide cuánto retraso es aceptable antes de considerar el caso fallido.

2. Observa la solicitud

Comprueba que la acción del usuario produjo una única orden de envío. Si administras la aplicación, registra el nombre de plantilla, locale, destinatario enmascarado y un identificador del proveedor. No registres códigos, tokens ni el cuerpo completo.

Ensaya dobles clics y reintentos: la interfaz debe evitar envíos duplicados o explicar el límite. Un error de proveedor debe mostrarse sin afirmar que el correo fue entregado.

3. Comprueba la recepción

Verifica destinatario exacto, remitente visible, asunto y hora. Mide la latencia desde la solicitud hasta la recepción. Distingue «aceptado por el proveedor», «aceptado por el servidor receptor» y «visible en el buzón»; son hitos diferentes.

Confirma que una ejecución solo consume su propio mensaje. Las pruebas paralelas necesitan direcciones o identificadores independientes para no leer el correo de otro caso.

4. Valida texto y HTML

Revisa versión de texto, HTML protegido, jerarquía de títulos, contraste, idioma y enlaces. El contenido importante debe seguir siendo comprensible con imágenes bloqueadas. Los botones necesitan texto descriptivo y un destino coherente.

Prueba asuntos largos, nombres con caracteres internacionales y datos próximos a los límites. Evita incluir información sensible innecesaria en asunto o preencabezado, porque pueden aparecer en notificaciones y registros.

5. Códigos y enlaces

Un código debe aceptar el valor más reciente, caducar en el plazo documentado y no poder reutilizarse después del éxito. Un enlace debe usar HTTPS, un dominio reconocible y un token impredecible; tras caducar debe mostrar una respuesta segura sin revelar estado interno.

Comprueba que solicitar un nuevo secreto invalida los anteriores según el contrato. No guardes el valor real como evidencia. Registra únicamente que estaba presente, su longitud o formato permitido y el resultado de uso.

6. Adjuntos

Si la función envía archivos, prueba tipo, nombre, tamaño, descarga y comportamiento ante contenido no admitido. Utiliza ficheros de prueba inocuos. La respuesta debería forzar descarga, impedir interpretación MIME ambigua y evitar caché cuando el contenido sea sensible.

Incluye casos sin adjuntos, varios adjuntos, nombre Unicode y tamaño justo por debajo y por encima del límite. Nunca utilices malware real para una prueba funcional corriente.

7. Autenticación y cabeceras

Revisa SPF, DKIM y DMARC en el receptor de prueba, teniendo en cuenta proveedores delegados y alineación. Confirma Message-ID, Date y cadena Received razonables. Un pass de autenticación no sustituye las pruebas de contenido y autorización.

8. Accesibilidad y localización

Navega el mensaje y la página de destino con teclado. Comprueba orden de lectura, texto alternativo y zoom. Para cada idioma, revisa formato de fecha, dirección del texto, expansión de botones, tono y terminología; no limites la prueba a que «no falten claves».

9. Casos negativos

Prueba dirección inválida, dominio rechazado, proveedor no disponible, límite de frecuencia, buzón caducado, token alterado y acceso desde otra sesión. La aplicación debe utilizar estados claros y no filtrar si una cuenta sensible existe.

10. Limpieza y evidencia

Elimina cuenta, buzón, archivos y datos creados. Conserva solo identificador de ejecución, versión, horas, resultados y capturas redactadas cuando sean necesarias. La guía de evidencia segura explica cómo evitar que un informe se convierta en una filtración.

Automatiza los pasos deterministas y reserva la revisión visual para cambios de plantilla. Una prueba robusta consulta con intervalos y un plazo total, no con esperas fijas que fallan según la carga.

Cómo guardar evidencias de pruebas de correo sin exponer secretos
Qué conservar, qué ocultar y cómo demostrar un resultado sin archivar códigos, enlaces de acceso o mensajes completos.
Cómo usar una API de correo temporal sin crear pruebas inestables
Diseño de pruebas con buzones aislados, consultas limitadas, tiempos máximos, correlación segura y limpieza determinista.
Postfix vs Dovecot: funciones distintas en un servidor de correo entrante
Ubica Postfix, Dovecot, LMTP, la cola e IMAP en la ruta de entrada y decide con evidencias dónde falla una entrega.