Seguridad de correo: descubre si alguien puede hacerse pasar por tu empresa
Descubre si alguien puede enviar correos en nombre de tu empresa. El análisis lee SPF, DKIM, DMARC y MTA-STS de tu dominio. Resultado en pantalla y PDF completo.
El fraude de la factura falsa no empieza invadiendo nada.
Empieza con un correo que parece venir de tu dominio. No hay ninguna intrusión: el correo funciona como se diseñó en los años 80, cuando nadie tenía que probar quién era. La verificación del remitente sigue siendo opcional, y quien la activa eres tú, publicando tres registros en tu DNS.
Cada registro hace algo distinto. SPF lista los servidores que pueden enviar en nombre del dominio. DKIM firma cada mensaje con una clave que solo tú tienes. DMARC es el único que indica al destinatario qué hacer cuando la verificación falla, y sin él los otros dos son información sin consecuencia.
Configuraciones incompletas que señala el análisis: SPF que termina en ~all, DMARC detenido en p=none desde su publicación y un conteo de consultas DNS superado por integraciones acumuladas, lo que invalida todo el SPF sin aviso. Cada una viene con la corrección específica. Los términos están explicados en el glosario.
Qué busca el análisis
SPF que funciona de verdad
DMARC y la decisión
DKIM y firma
TLS en el transporte
Del dominio al informe
Indica el dominio
Solo el dominio. Sin cuenta, sin tarjeta y sin instalar nada.
El análisis se ejecuta
El mismo scanner de la plataforma se ejecuta contra el host, en tiempo real.
La nota aparece en pantalla
Nota de 0 a 100, calculada con la fórmula del producto, con los hallazgos más graves visibles.
El informe llega por correo
PDF completo con evidencia e instrucciones de corrección, enviado a un correo del dominio analizado.
Por qué solo a un correo del dominio analizado. El informe describe debilidades de un dominio específico. Enviarlo a cualquier dirección permitiría que terceros obtuvieran ese análisis sin relación con el dominio. Si no tienes correo en el dominio, contáctanos y enviamos el informe después de confirmar tu relación con él.
Qué hace el análisis en el objetivo
Consultar registros DNS públicos
SPF, DKIM (selectores comunes), DMARC, MX, MTA-STS y TLS-RPT se leen del DNS, como hace cualquier servidor de correo antes de entregar un mensaje.
Resolver los includes de SPF
Se sigue cada include y redirect para contar las consultas y llegar al conjunto real de remitentes autorizados.
Conectar a los servidores MX
Una conexión SMTP a cada MX para registrar STARTTLS, versión de TLS y certificado. No se envía ningún mensaje.
Verificar la política de recepción
Se lee el archivo MTA-STS publicado por HTTPS y se compara con el registro DNS.
Sondear puertos y servicios
El escaneo de puertos alcanza infraestructura que puede pertenecer al proveedor, como en PaaS y CDN. Este tipo de prueba requiere autorización formal del responsable del entorno.
Enumerar rutas
No hay intentos de descubrir rutas como /admin o /.env con listas de palabras. Ese procedimiento genera volumen de solicitudes en el objetivo y solo se ejecuta con autorización.
Explotar vulnerabilidades
No se envía ningún payload ni se explota ninguna vulnerabilidad. Las sondas observan cómo responde el servidor, sin extraer datos.
Cubrir todo el inventario
El resultado cubre el dominio indicado. Subdominios, entornos de pruebas y servicios auxiliares forman parte del análisis completo de la plataforma.
Preguntas frecuentes
¿Cualquier persona puede enviar correos en nombre de mi empresa?
Por defecto, sí. SMTP no verifica quién dice ser el remitente. Esa verificación es opcional y depende de tres registros que publicas en tu DNS: SPF indica qué servidores pueden enviar, DKIM firma los mensajes y DMARC indica al destinatario qué hacer cuando la verificación falla. Sin DMARC en cuarentena o rechazo, el destinatario puede notar la suplantación y aun así entregar el mensaje.
Tengo SPF configurado. ¿No es suficiente?
No, por dos motivos. Primero, SPF solo no instruye al destinatario: publica la lista de servidores autorizados, pero quien decide qué hacer con un fallo es la política DMARC. Segundo, un SPF que termina en ~all (softfail) pide al destinatario aceptar el mensaje aunque falle, lo que es permisivo por definición. Además existe un límite técnico de diez consultas DNS: superarlo invalida todo el registro sin aviso, y ocurre en dominios que acumularon integraciones de marketing y facturación con los años.
¿Qué significa DMARC con p=none?
Significa modo de observación: el destinatario verifica, te envía reportes y entrega el mensaje de todos modos. Es el punto de partida correcto, y sirve para descubrir quién envía legítimamente antes de endurecer la política. El problema es quedarse ahí: la política nunca avanza a quarantine o reject, y mientras tanto el dominio sigue siendo suplantable en la práctica.
¿Por qué el análisis verifica MTA-STS y TLS-RPT?
SPF, DKIM y DMARC tratan de autenticidad: quién envió. MTA-STS y TLS-RPT tratan de confidencialidad en tránsito. La entrega de correo entre servidores negocia el cifrado de forma oportunista: si TLS falla, lo habitual es entregar en texto plano en lugar de no entregar. MTA-STS es la política que cierra esa brecha exigiendo TLS, y TLS-RPT es el canal que te avisa cuando alguien intenta forzar la degradación.
¿El análisis envía correos de prueba a mi dominio?
No. Las verificaciones son consultas de DNS público (SPF, DKIM, DMARC, MTA-STS, TLS-RPT y DNSSEC son registros publicados), más la negociación de STARTTLS con los servidores de entrada listados en tu MX, que es el mismo contacto que hace cualquier servidor de correo antes de entregar un mensaje. No se envía ningún mensaje y no se toca ningún buzón.
Mi correo es Google Workspace o Microsoft 365. ¿Igual lo necesito?
Sí, y es justamente donde más aparece la falla. El proveedor se encarga de la infraestructura de envío, pero los registros están en tu DNS y eres tú quien los publica. La configuración por defecto de ambos entrega SPF y DKIM funcionales y deja DMARC por tu cuenta. La decisión sobre la suplantación de tu dominio sigue siendo tuya, y por defecto no está tomada.
¿La nota de esta página incluye TLS y cabeceras HTTP?
No. En esta página solo se ejecuta el análisis de correo, y la nota refleja ese resultado. El diagnóstico completo ejecuta TLS, cabeceras HTTP y correo en el dominio indicado. El fraude de facturas falsas y de pagos empieza por correos en nombre de la empresa, así que la seguridad del correo suele traer los hallazgos de mayor impacto.