Source: https://once-email.com/es/blog/safe-email-test-evidence Pruebas e ingeniería · 2 ago 2026Actualizado 8 ago 2026 # 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. [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 lector puede crear un paquete reproducible con metadatos suficientes y una lista concreta de valores que deben redactarse. Guía del artículo Por qué vale la pena leer este artículo **Análisis original** Clasificamos evidencias por la afirmación que demuestran para minimizar contenido y evitar que capturas y registros prolonguen la vida de un secreto. **Contexto de tendencias** Los equipos comparten más artefactos en CI, tickets y chats, superficies cuya retención suele superar ampliamente la del buzón de prueba. **Valor práctico** El lector puede crear un paquete reproducible con metadatos suficientes y una lista concreta de valores que deben redactarse. Una evidencia útil responde a una pregunta concreta: qué versión se probó, qué evento ocurrió, cuándo ocurrió y cuál fue el resultado. Guardar el mensaje completo «por si acaso» añade datos y secretos sin mejorar necesariamente la reproducibilidad. ## [Empieza por la afirmación]() Si quieres demostrar que se utilizó la plantilla española, conserva identificador de versión, locale y una captura recortada del texto no sensible. Para demostrar entrega, basta con horas de solicitud y recepción, destinatario enmascarado y estado. Para caducidad, registra los intentos antes y después del plazo sin guardar el token. Cada artefacto debe tener un propósito. Si nadie puede explicar qué demuestra un campo, no lo conserves. ## [Valores que deben eliminarse]() Redacta o sustituye: - códigos de verificación y contraseñas de un solo uso; - enlaces de acceso, restablecimiento, cancelación o confirmación; - claves API, cookies, cabeceras Authorization y tokens de sesión; - direcciones personales completas y nombres no necesarios; - cuerpos, adjuntos, identificadores de mensajes e IP cuando no sean esenciales; - parámetros únicos de seguimiento. No basta con cubrir visualmente un valor si el PDF o la imagen conserva una capa de texto, metadatos o historial. Genera una copia plana y comprueba el resultado final. ## [Capturas de pantalla]() Recorta la ventana al área necesaria. Oculta notificaciones, pestañas, barra de marcadores, perfil del navegador y otros mensajes. Utiliza datos de prueba reconocibles y no reales. Si el defecto está en el diseño, reemplaza primero el secreto por un marcador. Una captura demuestra apariencia, no necesariamente entrega o autenticación. Combínala con metadatos estructurados cuando la afirmación sea técnica. ## [Cabeceras y registros]() Las cabeceras completas contienen más datos de los que parecen: direcciones, rutas, IP, identificadores y firmas. Extrae solo los campos necesarios. Para SPF/DKIM/DMARC, suele bastar ` Authentication-Results ` redactado y los dominios relevantes; conserva la cadena Received únicamente si investigas tránsito. Configura la aplicación para no registrar cuerpos ni secretos. Utiliza identificadores de correlación aleatorios, destinatarios enmascarados y códigos de resultado. Asegura que el modo de depuración no llegue a producción por accidente. ## [Almacenamiento y acceso]() Guarda evidencias en el sistema de pruebas o tickets aprobado, con acceso por función y una fecha de eliminación. No las copies a chats personales, documentos públicos o servicios de análisis externos. Los artefactos de CI también necesitan caducidad y permisos; «solo está en el pipeline» no significa privado para siempre. Si un proveedor externo debe investigar, comparte el mínimo mediante su canal seguro y documenta la transferencia. Nunca pegues un enlace activo en un buscador o verificador público. ## [Paquete mínimo recomendado]() - identificador de prueba y versión de la aplicación; - entorno y navegador; - horas UTC de solicitud, recepción y acción; - destinatario enmascarado; - plantilla y locale esperados; - resultado por paso y mensaje de error no sensible; - captura redactada solo cuando aporta evidencia visual; - responsable y fecha automática de eliminación. ## [Revisión antes de compartir]() Abre el artefacto como lo verá el destinatario. Busca patrones como ` token= `, ` code= `, ` Bearer `, direcciones y URL largas. Comprueba propiedades y metadatos. Pide una segunda revisión cuando el incidente afecte a producción o clientes. Si ya compartiste un secreto, no te limites a borrar el mensaje: revócalo o invalídalo, revisa accesos y registra el incidente según la política del equipo. La eliminación posterior no garantiza que no existan copias. La mejor evidencia es pequeña, verificable y efímera. Debe durar lo suficiente para corregir el defecto, no más que el riesgo que documenta. Integra estas reglas desde el principio con la [lista completa de pruebas de correo]() , en lugar de redactar secretos al final. ## Guías relacionadas 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. [Lista de pruebas de correo para desarrolladores: de la solicitud a la caducidad]() 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]() ## Herramientas de correo centradas en la privacidad Generador hash SHA-256 y SHA-512 Genera hashes de texto localmente con Web Crypto. Generador hash SHA-256 y SHA-512 [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.]() [Alias, buzón temporal o dirección permanente: ¿cuál conviene? Compara tres formas de recibir correo según continuidad, separación, recuperación, exposición y control.]()