Verificador de SPF y DMARC

Escribe el dominio y pulsa Comprobar. La herramienta lee el registro SPF y expande todos sus include y redirect, lee el registro DMARC en _dmarc.tudominio, sondea un conjunto de selectores DKIM conocidos y resuelve los hosts MX. Cada registro recibe su propio veredicto, y MTA-STS, TLS-RPT y BIMI se comprueban en la misma pasada.

La RFC 7208 permite como mucho diez términos que provoquen una consulta DNS durante la evaluación: include, a, mx, ptr, exists y el modificador redirect. Los include cuentan de forma recursiva, así que un puñado de proveedores puede empujar el total más allá de diez sin que se note. La evaluación se detiene en el primer mecanismo que coincide, de modo que ese total es el peor caso y no un veredicto sobre cada mensaje: un remitente cuya ruta llega más allá de la décima consulta recibe un error permanente —que bajo DMARC cuenta como fallo de SPF—, mientras que uno que coincide antes sigue pasando. Por eso un registro que se pasa del presupuesto parece perfectamente normal y solo falla para algunos remitentes.

Empieza quitando los include de proveedores por los que ya no envías: normalmente basta con eso. Cuando un proveedor publica rangos de direcciones estables, sustituye el include por mecanismos ip4 e ip6, que no consumen presupuesto. Mover parte del correo a un subdominio con su propio registro SPF divide el presupuesto en dos. Aplanar un include en direcciones literales funciona, pero hay que mantenerlo, porque el proveedor puede cambiar sus rangos sin avisar.

-all es un fallo duro: un servidor que no esté en la lista no está autorizado y los receptores pueden rechazar el mensaje. ~all es un fallo leve: no autorizado, pero se entrega y se marca. ~all es lo sensato mientras todavía estás localizando remitentes sueltos; -all es donde conviene acabar. ?all es neutral y no afirma nada, así que un registro que termine ahí hace más o menos lo mismo que no tener registro.

Porque el DNS no tiene forma de listar los selectores que publica un dominio. Una clave DKIM vive en selector._domainkey.tudominio, y sin saber el nombre del selector no hay nada que consultar. Esta herramienta sondea los selectores que usan los grandes proveedores, pero cualquiera personalizado —incluidos los selectores aleatorios que emite Amazon SES— hay que indicarlo. Tómalo de la etiqueta s= en la cabecera DKIM-Signature de cualquier mensaje del dominio y añádelo al campo de selectores.

p=none significa solo monitorizar: los receptores no aplican ninguna acción y se limitan a enviar informes. Es el sitio correcto para empezar, pero no protege nada, así que es una escala y no un destino. p=quarantine indica a los receptores que traten el correo que falla como sospechoso, normalmente dejándolo en spam. p=reject lo rechaza directamente. El camino habitual es none hasta que los informes se ven limpios, luego quarantine y después reject.

La causa más común es un registro de autorización que falta. Si tu dirección rua está en un dominio distinto del que se informa —un proveedor de monitorización, por ejemplo—, ese dominio tiene que publicar un registro en tudominio._report._dmarc.sudominio confirmando que los acepta. Sin él, los remitentes de informes que siguen la norma los descartan sin avisar a nadie, lo que se parece exactamente a que no se envíe ninguno. Esta herramienta comprueba ese registro para cada dirección externa.

No. Una página web no puede abrir una conexión SMTP —el puerto 25 queda fuera del alcance de un navegador—, así que la sección MX solo comprueba la configuración. Confirma que los registros existen, lee sus preferencias, resuelve cada destino y señala los fallos habituales: un destino sin registro de dirección, un CNAME donde hace falta un nombre de host o una dirección IP suelta. Saber si un servidor responde al otro lado requiere una herramienta capaz de hablar SMTP.

Que SPF pase no es lo mismo que que pase DMARC. DMARC exige además alineación: el dominio que pasó SPF tiene que coincidir con la dirección From que ve el destinatario. El correo enviado a través de un proveedor suele pasar SPF con el dominio del propio proveedor mientras la cabecera From muestra el tuyo, y eso rompe la alineación. Firmar con DKIM usando tu dominio lo resuelve, porque la alineación DKIM se comprueba por separado. La reputación, el contenido y la higiene de las listas quedan del todo fuera de la autenticación.

MTA-STS indica a los servidores que envían que exijan TLS al entregarte correo, cerrando el ataque de degradación que deja abierto el TLS oportunista. TLS-RPT les pide que informen cuando eso falla. BIMI publica un logotipo para los receptores que muestran uno, y antes exige DMARC en modo aplicado. Los tres son opcionales, y no publicarlos es completamente normal.

Sí, y merece la pena en cualquier subdominio que envíe correo, ya que SPF y DKIM se consultan en el nombre exacto. DMARC funciona distinto: los receptores recurren al registro del dominio organizativo cuando un subdominio no tiene ninguno, y aplican su etiqueta sp. Esta herramienta lee el nombre exacto que escribas, así que un resultado DMARC vacío en un subdominio suele significar que lo que se aplica es la política del dominio padre.

Responden a preguntas distintas. La herramienta de consulta DNS te muestra registros: cualquier tipo, cualquier resolutor, con trazado de la delegación. Esta juzga un conjunto concreto de ellos: expande la cadena SPF en lugar de imprimir una línea, la cuenta frente al límite, y lee DMARC y DKIM según las reglas que los rigen. Usa aquella para ver qué está publicado y esta para saber si es correcto.