Cómo comprobar un registro SPF (y qué hay que mirar)

dig +short TXT ejemplo.es

nslookup -type=TXT ejemplo.es

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all

Paso 3: contar las búsquedas DNS

Es el control que más a menudo se descuida. Cada include, a, mx, ptr, exists y redirect cuesta al menos una búsqueda DNS, y el total no debe superar diez. Por encima, es PermError, y el SPF ya no se evalúa. La trampa: los include de proveedores se despliegan en varias búsquedas cada uno, así que el recuento «visible» engaña.

Este cálculo no se hace a ojo sobre un registro complejo — hay que desplegar el árbol. Es exactamente lo que hace nuestro analizador DMARC gratuito: resuelve recursivamente cada include y muestra el recuento real. Cerca o por encima de diez, la corrección se detalla en el límite de búsquedas DNS de SPF.

Paso 4: examinar la calificación terminal

Lo que sigue al all final merece toda la atención:

• -all (hardfail) — el objetivo: lo que no está listado no es legítimo.
• ~all (softfail) — un compromiso de transición, aceptable pero no una meta.
• ?all (neutral) — no afirma nada; a reemplazar.
• +all (pass) — peligro: autoriza a todo el mundo. A corregir de inmediato.

Un +all es la urgencia absoluta: el dominio se autodeclara suplantable. El detalle de los calificadores está en los mecanismos -all y ~all.

Paso 5: comprobar el registro doble

Un dominio solo debe tener un único registro v=spf1. Cuando hay dos (por ejemplo, uno añadido por el equipo de marketing y otro por el de sistemas), muchos destinatarios consideran la configuración inválida e ignoran los dos — dejando el dominio sin SPF efectivo cuando parecía cubierto. La corrección consiste en fusionar ambos en un solo registro, combinando sus mecanismos (y vigilando de paso el límite de las diez búsquedas).

Paso 6: confirmar la alineación, no solo el paso

Aquí está el control más sutil, y el más importante para DMARC. Un SPF que «pasa» técnicamente no sirve de nada si no se alinea con el dominio del From:. La mayoría de los proveedores externos usan su propio dominio de sobre; el SPF pasa entonces para ellos, no para el remitente, y DMARC no lo tiene en cuenta. Para verificar la alineación real, hay que mirar del lado del destinatario: es precisamente lo que revelan los informes agregados, que muestran, fuente por fuente, si SPF se ha alineado. Si «alineación» parece confuso, la lectura previa es cómo funcionan juntos los tres protocolos.

El método rápido: un analizador

Todas estas comprobaciones se pueden hacer a mano, pero un buen analizador las hace en unos segundos y sin errores. Nuestro analizador DMARC gratuito acepta cualquier dominio: confirma la existencia del SPF, valida la sintaxis, despliega el árbol y cuenta las búsquedas, muestra la calificación terminal, señala un posible registro doble, y — combinado con los informes — indica si las fuentes se alinean de verdad. Es el control completo, no solo el «existe».

Una comprobación de principio a fin, en la práctica

Desarrollemos una comprobación completa sobre un dominio ficticio, tienda.es. Un dig +short TXT tienda.es devuelve:

"v=spf1 include:_spf.google.com include:shopify.com include:sendgrid.net include:_spf.mailjet.com ~all"

Primer reflejo: ¿un solo v=spf1? Sí, bien. ¿Sintaxis? Correcta. ¿Calificación? ~all — aceptable, pero anotamos que el objetivo es -all. Ahora el punto crítico, el recuento: estos cuatro include se despliegan. Google ≈ 4 búsquedas, Shopify ≈ 2, SendGrid ≈ 1-2, Mailjet ≈ 2. Total: alrededor de diez, al límite. Un quinto proveedor haría bascular a PermError. Veredicto: el registro «funciona» hoy pero es frágil, y cualquier nueva fuente tendrá que pasar por un subdominio.

Última etapa, la alineación: los informes agregados muestran que el correo de Shopify pasa SPF pero no se alinea (Shopify usa su propio dominio de sobre). Conclusión concreta: para que las notificaciones de pedido cuenten para DMARC, hay que activar una firma DKIM alineada en el lado de Shopify — el SPF solo no bastará.

Esta comprobación de cinco minutos ha enseñado tres cosas que un simple «el SPF existe» habría ocultado: roza el límite de las diez, la calificación se queda corta, y una de las fuentes clave no se alinea. Es exactamente la diferencia entre constatar una presencia y juzgar una calidad — y es esa diferencia la que decide si el correo llega.

La caché DNS, un factor a tener en cuenta al corregir

Una última trampa, descubierta por lo general en el peor momento: el DNS se almacena en caché. Cuando se corrige un registro SPF, los servidores destinatarios pueden seguir evaluando la versión antigua hasta que expire el TTL — a veces varias horas. Dos consecuencias prácticas. Primero, no hay que concluir demasiado rápido que una corrección «no funciona»: conviene consultar primero el servidor autoritativo de la zona (el del proveedor de DNS), que sirve siempre la versión fresca, antes de probar desde un resolver público que aún puede servir la antigua. Segundo, ante un cambio delicado — migración de proveedor, paso a -all — se baja el TTL del registro unos días antes: en caso de error, la corrección o la vuelta atrás se propagará tanto más rápido, y la ventana de exposición seguirá siendo corta.

Una lista de comprobación para tener a mano

Para un SPF sano, hay que verificar que:

• existe un único registro v=spf1;
• la sintaxis es válida (sin errores, sin include muerto);
• el recuento de búsquedas está en diez o por debajo;
• la calificación terminal es -all (o ~all en transición asumida);
• no hay ningún +all ni ptr;
• las fuentes legítimas se alinean en los informes.

Si las seis casillas están marcadas, el SPF hace su trabajo. Si no, la lista dice exactamente qué corregir.

Preguntas frecuentes

¿Con qué frecuencia comprobar mi SPF? Al menos cada vez que se añade o se retira un proveedor de envío, e idealmente en una revisión trimestral. Los parques de envío se desvían, y un registro sano hoy puede desbordar el límite de las diez mañana.

Mi SPF pasa en un comprobador, ¿basta? No necesariamente. Muchos comprobadores confirman que la sintaxis es válida, pero no verifican ni el recuento real de búsquedas (desplegando las cascadas), ni la alineación con el From:. Son justo esos dos puntos los que marcan la diferencia en producción.

¿Por qué falla mi correo si mi SPF «existe»? Tres causas frecuentes: un PermError por superar las diez búsquedas, una fuente legítima no listada, o un paso SPF que no se alinea (el proveedor firma con su dominio, no con el del remitente). Los informes agregados lo zanjan.

¿Se puede comprobar el SPF de otro dominio? Sí — el SPF es público. Es útil para auditar a un proveedor o comparar una postura con la de un competidor. Un analizador acepta cualquier dominio.

¿Y si no hay ningún SPF? Publicar uno, listando las fuentes de envío reales y terminando por -all (o ~all mientras se hace el inventario). Es el primer ladrillo de la autenticación, antes de DKIM y DMARC.

¿Hay que comprobar el SPF de mis subdominios por separado? Sí. Un subdominio de envío (news., notif.) tiene su propio registro SPF, independiente de la raíz. Un subdominio emisor se comprueba como el dominio principal — y dispone de su propio presupuesto de diez búsquedas, lo que a menudo es una ventaja que explotar.

¿El SPF se actualiza solo cuando un proveedor cambia sus IP? Solo si se ha dejado en include: ese es todo el interés, el proveedor mantiene el registro. Con las IP fijadas en ip4: (o un SPF aplanado), no — el seguimiento pasa a ser manual, y una comprobación periódica se vuelve indispensable.

Thomas vigila en continuo

Comprobar el SPF una vez está bien; mantenerlo sano a lo largo del tiempo, mejor. Thomas, el CISO virtual, controla en continuo el registro — sintaxis, recuento de búsquedas, calificación, registro doble — y verifica en los informes que las fuentes se alinean de verdad. Avisa cuando algo se desvía, antes de que el correo lo sufra.

Análisis de dominio gratuito o crear una cuenta para un SPF vigilado en permanencia.