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

Escriba su 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 su 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 sus proveedores. En la consulta #11 la evaluación se aborta con permerror. Nada rebota por su lado; DMARC simplemente trata su 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 suyo. ~all es el camino: «márquelo, no lo rechace». Es el ajuste correcto mientras todavía está descubriendo remitentes — esa herramienta de facturación que nadie mencionó. También es el más seguro si perder un correo legítimo le 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 «agrega 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 su registro con «…y todos los demás también pasan». Cualquier IP de internet se convierte en remitente autorizado de su dominio: un spammer que falsifica su dirección recibe un pass de SPF, y si su política DMARC depende de la alineación con SPF, ese correo falsificado también puede pasar DMARC — su autenticación ahora responde por el atacante. Es, sencillamente, peor que no publicar SPF, porque «sin registro» hace sospechar a los receptores mientras que «+all» les da confianza. En la práctica, suele aparecer como un «arreglo» de entregabilidad mal planteado. 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 suyo. 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: elimine lo que no envía nada — a y mx son victorias gratis si su servidor web y su MX nunca envían correo saliente. ptr siempre se puede quitar. Elimine proveedores muertos — cada include debería corresponder a un servicio que sigue pagando. Divida 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 sus proveedores — cuando las renumeren, su registro se pudre en silencio. Aplane solo con herramientas o monitoreo que lo vuelvan a comprobar.