Comprobador SPF:
¿tu registro está dentro del límite de 10 consultas?

Escribe tu dominio arriba. Consultamos sus registros TXT, confirmamos que exactamente uno empieza por v=spf1 (dos es un fallo inmediato — no se combinan, mueren los dos), y luego analizamos cada mecanismo según RFC 7208: cada include se expande de forma recursiva en un árbol, cada consulta DNS se cuenta sobre el presupuesto de 10, se evalúa la política all final, y se suman en una sola lista todos los rangos de IP que tu registro autoriza. Gratis, sin registro.

Los receptores que evalúan SPF ejecutan como máximo 10 mecanismos que consultan DNS por comprobación (RFC 7208 §4.6.4). include, a, mx, ptr, exists y redirect cuentan todos, incluidos los que se esconden dentro de los include de tus proveedores. En la consulta #11 la evaluación se aborta con permerror. Nada rebota por tu lado; DMARC simplemente trata tu dominio como si no publicara SPF. La rotura llega poco a poco, un alta a la vez, y nunca se anuncia.

-all es el destino: rechaza lo que no es tuyo. ~all es el camino: «márcalo, no lo rechaces». Es el ajuste correcto mientras todavía estás descubriendo remitentes — esa herramienta de facturación que nadie mencionó. También es el más seguro si perder un correo legítimo te cuesta más que dejar pasar uno falsificado. Dos matices: con DMARC en marcha, la diferencia práctica se reduce, porque DMARC falla el correo no autorizado en ambos casos. Y -all al final de un registro que supera el límite de consultas es rigor aplicado a un cadáver — gana el permerror.

No — y el fallo es especialmente cruel. RFC 7208 dice que varios registros v=spf1 hacen que la comprobación devuelva permerror: ni «gana el primero», ni «se combinan» — los dos quedan invalidados. Suele pasar sin mala intención: un plugin del sitio, el asistente de un ESP o un segundo administrador «añade SPF» sin darse cuenta de que ya existía un registro. El arreglo es cosa de un minuto: combina todos los mecanismos en un único registro y elimina el resto. Esta herramienta cuenta tus registros lo primero de todo, precisamente por esto.

Termina tu registro con «…y todos los demás también pasan». Cualquier IP de internet se convierte en remitente autorizado de tu dominio: un spammer que falsifica tu dirección recibe un pass de SPF, y si tu política DMARC depende de la alineación con SPF, ese correo falsificado también puede pasar DMARC — tu autenticación ahora responde por el atacante. Es literalmente peor que no publicar SPF, porque «sin registro» hace sospechar a los receptores mientras que «+all» les da confianza. Aparece en la práctica como un «arreglo» de entregabilidad mal entendido. Si esta herramienta encuentra uno, no será nada discreta al respecto.

Por sí solo, no. SPF valida el remitente del sobre (la dirección usada en la conversación SMTP), no el From: que ve quien lee el correo. Un falsificador puede pasar SPF en su propio dominio mientras muestra el tuyo. Cerrar esa brecha es trabajo de DMARC: exige que el From visible esté alineado con lo que validó SPF o DKIM. También le dice al receptor qué hacer cuando no lo está. La pila completa es SPF + DKIM + DMARC, y esta herramienta se asegura de que la parte de SPF se sostenga, porque un permerror aquí deja cojas a las otras dos en silencio.

De menor a mayor esfuerzo: elimina lo que no envía nada — a y mx son victorias gratis si tu servidor web y tu MX nunca envían correo saliente. ptr siempre se puede quitar. Elimina proveedores muertos — cada include debería corresponder a un servicio que sigues pagando. Divide por subdominio — deja que las newsletters envíen como news.yourdomain.com con su propio registro y su propio presupuesto. Último recurso, aplanar: sustituir los include por sus rangos ip4/ip6 literales cuesta cero lookups. Pero congela una copia de las redes de tus proveedores — cuando las renumeren, tu registro se pudre en silencio. Aplana solo con herramientas o monitorización que lo vuelvan a comprobar.