Comprueba tu DMARC, SPF y DKIM: ¿pueden suplantar tu correo?
Revisa la configuración pública de correo, dominio y web. Gratis y sin registro.
Alcance y privacidad del análisis
Escribe tu dominio y verás si alguien podría mandar correos haciéndose pasar por él, y qué cambiar primero. No te pedimos un email de contacto y, si escribes un correo, solo usamos el dominio. El resultado es temporal: al recargar no se recupera ni se vuelve a consultar.
Metodología, límites y preguntas frecuentes
Qué comprobamos
Catorce comprobaciones de la configuración pública de tu dominio, agrupadas en correo, dominio y web. El veredicto «¿Te pueden suplantar?» sale de tu DMARC y tu SPF: manda lo más grave. Cada comprobación termina en Bien, Mejorable, Riesgo, Sin datos, No aplica o Informativo, con lo que significa y lo que tiene que hacer tu equipo de TI.
| Comprobación | Grupo | Qué mira | Fuente |
|---|---|---|---|
| SPF | Correo | Qué servidores pueden enviar correo con tu dominio, y si el registro se puede evaluar entero. | RFC 7208 |
| DKIM | Correo | Si encontramos claves de firma con los selectores habituales (o el tuyo) y su tamaño. | RFC 6376, RFC 8301, RFC 8463 |
| DMARC | Correo | Qué pides a los buzones que hagan con los correos que usan tu dominio sin autorización. | RFC 9989 (y RFC 7489) |
| MX | Correo | A qué servidores llega tu correo, o si declaras que el dominio no recibe correo. | RFC 5321, RFC 7505 |
| MTA-STS | Correo | Si publicas una política que exige cifrado al recibir correo entre servidores. | RFC 8461 |
| TLS-RPT | Correo | Si pides informes de los fallos de cifrado al recibir correo. | RFC 8460 |
| BIMI | Correo | Si publicas el registro para mostrar tu logotipo en algunos buzones (informativo). | Borrador de la IETF |
| DNSSEC | Dominio | Si las respuestas de tu DNS van firmadas y un resolvedor que valida las acepta. | RFC 4033-4035, RFC 9364 |
| CAA | Dominio | Qué autoridades pueden emitir certificados para tu dominio. | RFC 8659 |
| TLS de la web | Web | Versión de TLS, cadena del certificado y si acepta versiones antiguas. | RFC 8446, RFC 8996 |
| Caducidad del certificado | Web | Cuántos días le quedan al certificado de tu web. | CA/Browser Forum |
| HTTPS y HSTS | Web | Si la web redirige a HTTPS y obliga al navegador a usarlo. | RFC 6797 |
| Cabeceras de seguridad | Web | La política de contenidos efectiva, la protección contra marcos y otras cabeceras. | W3C CSP Level 3, WHATWG Fetch |
| security.txt | Web | Si publicas a quién avisar de un problema de seguridad, y si sigue vigente. | RFC 9116 |
Lo que no hace
- No escanea puertos ni busca subdominios.
- No se conecta a tus servidores de correo: mide la política que publicas, no lo que hace cada servidor ni cada buzón.
- No prueba vulnerabilidades. Solo hace consultas DNS a resolvedores públicos y unas pocas peticiones a tu web, como las de un navegador.
- No da una nota numérica. Lo que no hemos podido comprobar sale aparte, como «Sin datos», y nunca cuenta como bien.
Para quién es
Para quien dirige una empresa y quiere saber si alguien puede mandar correos con su dominio; para el equipo de TI, que necesita el registro exacto y el paso siguiente; y para proveedores de TI y gestorías que revisan los dominios de sus clientes, con su permiso.
Cómo corregirlo
Empieza por «Tus 3 primeros cambios» del resultado. Para DMARC, el camino habitual es publicar «p=none» con informes («rua»), revisarlos dos a cuatro semanas, pasar a «p=quarantine» y terminar en «p=reject». En SPF, quita los proveedores que ya no usas; aplanarlo a direcciones IP exige mantenerlo cuando el proveedor cambie las suyas. Si un dominio no envía ni recibe correo, publica un MX nulo, «v=spf1 -all» y DMARC con «p=reject».
En el Esquema Nacional de Seguridad, la medida mp.s.1 trata la protección del correo electrónico. Si te afecta, la guía del ENS explica qué te pide. Si prefieres que alguien opere tu correo y lo revise cada mes, eso forma parte de nuestra seguridad gestionada.
Tus datos
Sin registro ni email. El dominio viaja en el cuerpo de la petición, no en la dirección de la página, y no lo guardamos ni lo enviamos a nuestra analítica. Si escribes un correo, tu navegador solo envía lo que va detrás de la @. Más información en la política de privacidad.
Preguntas frecuentes sobre el comprobador
Tres registros que publicas en tu DNS para que los buzones distingan tu correo del que se hace pasar por ti. SPF dice qué servidores pueden enviar correo con tu dominio. DKIM firma cada mensaje con una clave cuya parte pública está en tu DNS. DMARC dice a los buzones qué hacer con los correos que usan tu dominio sin superar SPF ni DKIM: no hacer nada («p=none»), apartarlos («p=quarantine») o rechazarlos («p=reject»), y te permite recibir informes de quién envía correo en tu nombre.
Escribe el dominio en este comprobador. Buscamos su registro TXT que empieza por «v=spf1», comprobamos que solo haya uno, que no pase de 10 términos con consulta DNS (el límite de la RFC 7208) y cómo termina: «-all» rechaza a los no autorizados, «~all» los marca como sospechosos y «+all» deja pasar a cualquiera. También puedes verlo en una terminal con «nslookup -type=txt tudominio.es».
Cada clave DKIM se publica como registro TXT en «selector._domainkey.tudominio.es». Escribe tu dominio y, si conoces el selector de tu proveedor de correo, indícalo en la opción avanzada. La prueba definitiva es un correo que hayas enviado: en sus cabeceras debe aparecer una firma «DKIM-Signature» y el resultado «dkim=pass».
Las claves DKIM se publican bajo un nombre (el selector) que no se puede listar desde fuera. Probamos los selectores más habituales; si tu proveedor usa otro, escríbelo en la opción avanzada. No encontrar ninguno no significa que no tengas DKIM, y encontrar una clave no demuestra que todo tu correo salga firmado.
Que tu DMARC está en modo de observación: no pide a los buzones que rechacen ni que aparten los correos que se hacen pasar por tu dominio. Si además indicas un destino válido en «rua», puedes recibir informes de quién envía correo en tu nombre. Es un buen primer paso; el objetivo es llegar a «p=quarantine» y después a «p=reject».
No. «Difícil» se refiere a correos con tu dominio exacto y a la política que publicas. No cubre dominios parecidos ni un buzón ya robado.
El comprobador solo consulta información pública (registros DNS, el certificado y las cabeceras de la web), la misma que consulta cualquier servidor de correo o navegador, con peticiones de baja intensidad. Aun así, úsalo con dominios de tu organización o de clientes que te lo pidan.
No. Consultamos el dominio que escribes a través de resolvedores DNS públicos (Cloudflare y Google), que reciben el nombre del dominio y la dirección de nuestro servidor, no la tuya. Para evitar abusos usamos durante 48 horas una huella seudonimizada de tu dirección IP y del dominio consultado; no guardamos la IP. El dominio no va en la dirección de la página ni en nuestra analítica.
Sí: comprueba tu DMARC, tu SPF y tu DKIM, que son lo que permite a los buzones frenar la suplantación de email con tu dominio exacto. No cubre los dominios parecidos al tuyo ni un buzón ya robado, y mide la política que publicas, no lo que hace cada buzón.
Google exige DMARC (aunque sea con «p=none») a quien envía más de 5.000 correos al día a cuentas de Gmail, además de SPF y DKIM. Lo explica en sus directrices para remitentes.
Fuentes oficiales
- RFC 7208 · SPF
- RFC 6376 · DKIM
- RFC 8301 · Algoritmos y tamaños de clave de DKIM
- RFC 9989 · DMARC
- RFC 7489 · DMARC (versión anterior)
- RFC 7505 · MX nulo
- RFC 8461 · MTA-STS
- RFC 8460 · TLS-RPT
- RFC 9364 · DNSSEC
- RFC 8659 · CAA
- RFC 8996 · Retirada de TLS 1.0 y 1.1
- RFC 6797 · HSTS
- W3C · Content Security Policy Level 3
- RFC 9116 · security.txt
- Google · Directrices para remitentes de correo
El correo es una parte. Para ver el resto de tu ciberseguridad, haz el test: preguntas sin tecnicismos y un resultado con por dónde empezar.