Comprobar SPF

Qué hace esta herramienta

Consulta el registro SPF de un dominio y lo analiza contra lo que exige la RFC 7208: que exista uno solo, cómo termina (-all, ~all, ?all o +all) y cuántas consultas DNS gasta, con el límite de 10 que, al superarse, invalida la autenticación entera. Te muestra el registro en bruto y una lista de hallazgos por gravedad.

SPF es la lista de servidores autorizados a enviar correo con tu dominio en el remitente. Está publicada en un registro TXT en la raíz del dominio, y el servidor que recibe el correo la consulta para decidir si el envío es legítimo.

Cómo usarla

1. Escribe el dominio sin https:// ni www: ejemplo.com.
2. Pulsa Comprobar SPF.
3. Lee el registro y los hallazgos. Los rojos rompen la entrega o la protección; los naranjas la debilitan; los verdes confirman que esa parte está bien.

Los tres fallos que ve la herramienta

Dos registros SPF

Es el más común cuando se contrata un servicio nuevo (una plataforma de newsletters, un CRM, una tienda) y se «añade otro SPF» en vez de ampliar el existente. La RFC es tajante: si hay más de un registro que empiece por v=spf1, el resultado es permerror, un error permanente. En la práctica los receptores tratan el dominio como si no tuviera SPF, y algunos lo penalizan más que la ausencia. La solución es fundir los include de ambos en un solo registro; el generador de registros SPF y DMARC lo hace a partir de los proveedores que uses.

El calificador final

El mecanismo all va al final y dice qué hacer con los servidores que no están en la lista:

Con DMARC activo, ~all y -all se comportan casi igual, porque DMARC mira la alineación y no el matiz del fallo. Sin DMARC, -all es lo único que hace que un receptor rechace un correo falsificado.

Más de 10 consultas DNS

Cada include, a, mx, exists y redirect obliga al receptor a hacer una consulta DNS más, y el límite es 10 en total, contando las anidadas: el include de Google gasta 4 él solo, el de Microsoft 365 varios más. Al superar 10, el resultado es permerror y el SPF deja de valer, aunque todo lo demás esté perfecto. Es la avería silenciosa por excelencia: nadie la ve hasta que el correo empieza a caer en spam.

La herramienta cuenta las consultas reales, siguiendo los include anidados, no los mecanismos escritos. Si sale por encima de 10, las salidas habituales son quitar proveedores que ya no se usan, sustituir a y mx por ip4: cuando las IP son fijas, o pasar el dominio de envío masivo a un subdominio con su propio SPF.

Lo que SPF no hace

SPF solo comprueba el remitente del sobre (Return-Path), no la dirección que ve el usuario en «De». Un atacante puede usar su propio dominio en el sobre, pasar SPF, y poner el tuyo en el «De». Lo que cierra ese hueco es DMARC, que exige que el dominio autenticado coincida con el visible. Por eso SPF solo es el primer tercio: los otros dos son DKIM y DMARC, y el auditor de correo revisa los tres de una vez.

Tampoco sobrevive a los reenvíos: cuando un servidor reenvía tu correo, el remitente del sobre pasa a ser el reenviador y tu SPF falla en destino. Es esperado y es otra razón para tener DKIM, cuya firma viaja dentro del mensaje.

Preguntas que resuelve

• ¿Mi dominio tiene SPF? → si no hay registro, sale en rojo el primer hallazgo.
• ¿Por qué mi correo cae en spam desde que contraté X? → busca «varios registros» o «supera el límite de 10».
• ¿~all o -all? → -all si ya tienes todos los servidores listados; ~all mientras tanto, y DMARC en cualquier caso.
• ¿Cuántas consultas gasta cada proveedor? → el generador de registros las suma al elegirlos.