Herramientas de diagnóstico de red
Política TLS forzada para el correo entrante
DNS y registros
Consulta DNS Todos los registros DNS de cualquier dominio Consulta de registro A Direcciones IPv4 de un dominio Consulta de registro AAAA Direcciones IPv6 de un dominio Consulta MX Servidores de correo de un dominio Consulta NS Servidores de nombres autoritativos Consulta TXT Registros TXT, SPF, verificación Consulta CNAME Registros de nombre canónico (alias) Consulta SOA Registro Start of Authority Consulta SRV Registros de localización de servicios Consulta CAA Qué CAs pueden emitir certificados DNS inverso (PTR) Dirección IP a nombre de host Comprobación DNSSEC ¿Está el dominio firmado y validado? Diagnóstico DNS Un informe completo de delegación y DNSEntregabilidad de correo
Comprobación SPF Valida tu registro Sender Policy Framework Comprobación DMARC Inspecciona y califica tu política DMARC Comprobación DKIM Encuentra y valida tu clave pública DKIM Comprobación de lista negra Comprueba una IP contra listas negras de correo (DNSBLs) Test SMTP Conecta a un servidor de correo y comprueba STARTTLS Comprobación MTA-STS Política TLS forzada para el correo entrante Comprobación BIMI Registro del logo de marca para el correo Comprobación TLS-RPT Política de informes de TLS de SMTPRed y web
Comprobación de certificado SSL Inspecciona el certificado TLS de un sitio y su caducidad Comprobación de cabeceras HTTP Inspecciona cabeceras de respuesta, redirecciones y seguridad Ping (TCP) Accesibilidad y latencia sobre TCP Comprobación de puertos Qué puertos comunes están abiertosDominio
Consulta WHOIS Datos de registro de dominios, IPs y ASNsMTA-STS permite que un dominio exija que el correo entrante se entregue por TLS autenticado, defendiéndose de ataques de degradación e intermediario. IPeek lee el registro TXT _mta-sts y obtiene el archivo de política publicado en mta-sts.tu-dominio. Cierra el hueco que deja el STARTTLS oportunista, que un atacante puede eliminar en silencio.
MTA-STS usa dos partes. Un registro TXT en _mta-sts.tu-dominio contiene una versión y un identificador de política que indica a los servidores remitentes que existe una política y cambia cuando la actualizas. La política en sí vive en un archivo de texto plano servido sobre HTTPS en https://mta-sts.tu-dominio/.well-known/mta-sts.txt. Ese archivo lista la versión, el modo, los hostnames MX permitidos y un tiempo de caché max_age. Un remitente compatible con MTA-STS obtiene y cachea la política, y luego rechaza entregar a cualquier MX cuyo certificado no valide contra ella.
IPeek muestra si el registro TXT _mta-sts existe y si el archivo de política es alcanzable por HTTPS. El valor del modo es lo más importante. none significa que no hay política en vigor, testing significa que los fallos se reportan pero el correo sigue fluyendo, y enforce significa que un remitente debe abortar la entrega si la autenticación TLS falla. Comprueba que las entradas mx de la política coincidan con tus registros MX reales y que el certificado HTTPS del host de la política sea válido. Un max_age alto, a menudo 604800 segundos, mejora la protección porque las políticas cacheadas resisten la manipulación en vivo.
El error más común es un registro TXT que existe mientras el archivo de política devuelve un 404 o una redirección, lo que hace la política inservible. El host de la política debe servir HTTPS válido, así que un certificado caducado o que no coincide en mta-sts.tu-dominio rompe la aplicación por completo. Las entradas MX que se desincronizan con tu DNS provocan fallos de entrega en cuanto pasas a enforce. Despliega primero en testing, monitoriza los informes TLS-RPT en busca de fallos y pasa a enforce solo tras confirmar que cada MX presenta un certificado válido y coincidente.
En modo testing, los remitentes que detectan un fallo de TLS siguen entregando el correo pero reportan el problema, lo que te permite encontrar fallos sin bloquear el tráfico. En modo enforce, un remitente debe abortar la entrega a cualquier MX cuyo certificado falle la validación. Empieza en testing, vigila tus informes TLS-RPT y pasa a enforce solo cuando no aparezca ningún fallo.
El archivo de política se sirve sobre HTTPS en https://mta-sts.tu-dominio/.well-known/mta-sts.txt, en un subdominio llamado mta-sts. El registro DNS TXT en _mta-sts.tu-dominio solo anuncia que existe una política y lleva un identificador; las reglas reales, incluidos el modo y los hosts MX permitidos, viven en ese archivo HTTPS. Ambos deben estar presentes y ser válidos para que MTA-STS funcione.
STARTTLS es oportunista: ofrece cifrado pero un atacante en la red puede eliminar el anuncio de STARTTLS y forzar la entrega en texto plano sin que se detecte. MTA-STS añade una política publicada que indica a los remitentes que TLS es obligatorio y qué certificados MX confiar, de modo que una conexión TLS eliminada o inválida hace que la entrega falle en lugar de degradarse en silencio. Endurece STARTTLS frente a los ataques de degradación.
No. MTA-STS se apoya deliberadamente en HTTPS y la PKI web para su confianza, no en DNSSEC, lo que lo hace más fácil de desplegar que DANE. El certificado HTTPS del archivo de política proporciona la autenticación. Si tu dominio ya tiene DNSSEC, puedes ejecutar DANE junto a MTA-STS, ya que ambos mecanismos se complementan en lugar de entrar en conflicto.
Publica primero el registro TXT y el archivo de política en modo testing, luego activa TLS-RPT para que los servidores remitentes te envíen por correo informes de cualquier fallo de TLS. Confirma que los hostnames MX de la política coinciden con el DNS y que cada MX presenta un certificado válido. Cuando los informes no muestren fallos durante un ciclo de informe normal, cambia el modo a enforce y actualiza el identificador de política.