Source: https://once-email.com/es/blog/email-testing-checklist Pruebas e ingeniería · 2 ago 2026Actualizado 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. [Equipo de ingeniería de Once Email, Once Email author Equipo de ingeniería de Once Email]() 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. ## Guías relacionadas 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 guardar evidencias de pruebas de correo sin exponer secretos]() 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. [Cómo usar una API de correo temporal sin crear pruebas inestables]() 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. [Postfix vs Dovecot: funciones distintas en un servidor de correo entrante]() [Por qué Once Email solo recibe correo por diseño Qué problemas resuelve un buzón temporal, cuándo no conviene utilizarlo y por qué Once Email mantiene un límite estricto de solo recepción.]() [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.]()