Un verificador de transporte puede descubrir un problema real sin comprobar la seguridad de cada mensaje que envía o recibe su organización. La mayoría de las comprobaciones observan un punto final seleccionado en un momento determinado utilizando un método de resolución y validación particular. Por lo tanto, un resultado defendible incluye alcance y cobertura faltante, no sólo una tarjeta de pase.
Definir el inventario de rutas de entrega.
Referencias: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.
Enumere los dominios de los destinatarios, los nombres de host MX , las prioridades, las direcciones IPv4 e IPv6 , las puertas de enlace alojadas y las rutas de conmutación por error. Tenga en cuenta si la prueba sigue el enrutamiento MX normal o un host inteligente configurado explícitamente. Registre la implementación del remitente y si es compatible MTA-STS, DANE o una política local de TLS obligatorio. Diferentes sistemas de envío pueden tomar decisiones diferentes para el mismo dominio de recepción.
Luego defina el reclamo que cada cheque puede respaldar. Una solicitud HTTPS pública puede establecer la disponibilidad de la política desde ese punto de vista. Una sonda TLS puede observar un certificado presentado en una dirección elegida. Una consulta DNS de validación puede proporcionar evidencia sobre DNSSEC estado bajo un modelo de confianza de resolución específico. Ninguno prueba por sí solo que un envío real MTA utilizó los mismos datos y aplicó la política de entrega esperada.
Captar el estado en lugar de solo los resultados
Referencias: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.
Para MTA-STS , conserve el registro de descubrimiento, los bytes exactos de la política HTTPS, el tiempo de recuperación, el modo, la vida útil y el estado de la caché del remitente. Para DANE , conserve el MX y TLSA respuestas, estado de validación y comparación de asociaciones. Para cada conexión SMTP , capture el host y la IP seleccionados, STARTTLS negociación, resultado de la verificación entre pares y decisión de entrega. RFC 8461 secciones 3 a 5, RFC 7672 secciones 2-3.
Una sonda fallida debe registrar su etapa de falla. El tiempo de espera DNS , el tiempo de espera de TCP, la ausencia de STARTTLS , el error en el protocolo de enlace y la falta de coincidencia de certificados no son hallazgos intercambiables. Un apretón de manos exitoso tampoco establece que el remitente rechazará una futura conexión degradada. Incluir casos negativos controlados cuando se autorice, especialmente antes de habilitar un requisito estricto de transporte.
Trabajar a través de una brecha de cobertura
En este ejemplo de inventario sintético, mx1.example.net tiene rutas IPv4 e IPv6 y mx2.example.net es una copia de seguridad. Una observación de ejemplo cubre sólo la dirección IPv4 de mx1. El inventario debe marcar las rutas IPv6 y de respaldo como no probadas en lugar de propagar el éxito entre las tres. La observación es explícitamente sintética y no pretende ninguna conexión real.
Agregue una fila de aceptación del lado del remitente para un MTA de soporte que utilice una política de aplicación válida, otra con un caché vacío y un remitente compatible con DANE con TLSA validada. Estas filas permanecen pendientes hasta que se capturen los registros reales. Esto hace que el plan de aceptación sea útil sin presentar los resultados esperados como mediciones. También permite que el personal de respuesta a incidentes vea si alguna vez se utilizó la ruta fallida.
Conciliar informes y evidencia operativa
Referencias: RFC 8460 §4.1, RFC 8460 §4.2.
TLS-RPT Los informes pueden revelar fallas observadas por los remitentes participantes durante un período de informe, complementando las investigaciones en un momento dado. Sus recuentos de sesiones no son recuentos de mensajes únicos y su cobertura no es universal. Un período de informe tranquilo no demuestra que todas las rutas tuvieron éxito, y los reintentos repetidos pueden complicar las estimaciones del impacto empresarial. RFC 8460 sección 4.4.
Conserve el resultado sin procesar, la marca de tiempo, la versión de la herramienta o el comando y la conclusión más específica que extrajo de él. Vuelva a realizar la prueba después de la renovación del certificado, la migración MX , los cambios DNSSEC y las actualizaciones de políticas. El paquete de revisión incluye siete transcripciones de bucle invertido retenidas el 7 de noviembre de 2026, con bytes de certificado de pares para las cuatro sesiones que alcanzaron la captura del certificado. Cubren un cliente/servidor Python IPv4 local en puertos generados con entradas de política y confianza configuradas explícitamente, no SMTP de Internet, una cadena de validación DNSSEC , colas MTA de producción o el cumplimiento completo del perfil de certificado MTA-STS . Las sesiones históricas fueron inspeccionadas pero no repetidas aquí. Los ejemplos de Internet IPv4 , IPv6 y rutas de respaldo aún no se han probado; ninguno hereda un pase local. El modelo de cobertura fuera de línea recientemente ejecutado solo verifica que una ruta sintética observada deje las otras rutas enumeradas sin probar. Capture el MTA previsto y las observaciones de enrutamiento antes de reclamar la garantía de implementación.