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

dig +short TXT ton-domaine.fr

nslookup -type=TXT ton-domaine.fr

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 tu 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.

No puedes hacer este cálculo 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 te muestra el recuento real. Si estás cerca o por encima de diez, mira el límite de búsquedas DNS de SPF para corregirlo.

Paso 4: examinar la calificación terminal

Fíjate en lo que sigue al all final:

• -all (hardfail) — el objetivo: lo que no está listado no eres tú.
• ~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.

Si encuentras +all, es la urgencia absoluta: tu 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. Si encuentras dos (por ejemplo, uno añadido por el equipo de marketing y otro por TI), muchos destinatarios consideran la configuración inválida e ignoran los dos — dejándote sin SPF efectivo cuando creías estar 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 de tu From:. La mayoría de los proveedores externos usan su propio dominio de sobre; su SPF pasa entonces para ellos, no para ti, y DMARC no lo tiene en cuenta. Para verificar la alineación real, tienes que mirar del lado del destinatario: es precisamente lo que revelan tus informes agregados, que muestran, fuente por fuente, si SPF se ha alineado. Si «alineación» te parece confuso, lee cómo funcionan juntos los tres protocolos.

El método rápido: un analizador

Puedes hacer todas estas comprobaciones a mano, pero un buen analizador las hace en unos segundos y sin errores. Pasa tu dominio por nuestro analizador DMARC gratuito: confirma la existencia del SPF, valida la sintaxis, despliega el árbol y cuenta las búsquedas, te muestra la calificación terminal, señala un posible registro doble, y — combinado con tus informes — te indica si tus 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, boutique.fr. Lanzas dig +short TXT boutique.fr y obtienes:

"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 apuntamos a -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: abres tus informes agregados y constatas 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 te ha enseñado tres cosas que un simple «el SPF existe» te habría ocultado: rozas el límite de las diez, tu calificación se queda corta, y una de tus 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 tu correo llega.

No olvides la caché DNS cuando corrijas

Una última trampa, descubierta por lo general en el peor momento: el DNS se almacena en caché. Cuando corriges tu 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 concluyas demasiado rápido que una corrección «no funciona»: consulta primero el servidor autoritativo de tu zona (el de tu 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, si preparas un cambio delicado — migración de proveedor, paso a -all — baja el TTL del registro unos días antes: en caso de error, tu corrección o tu 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, verifica 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;
• tus fuentes legítimas se alinean en los informes.

Si las seis casillas están marcadas, tu SPF hace su trabajo. Si no, sabes exactamente qué corregir.

Preguntas frecuentes

¿Con qué frecuencia comprobar mi SPF? Al menos cada vez que añadas o retires 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 tu 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 tuyo). Tus informes agregados lo zanjan.

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

¿Qué hago si no tengo ningún SPF? Publica uno, listando tus fuentes de envío reales y terminando por -all (o ~all mientras haces 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. Si envías desde un subdominio, compruébalo como el dominio principal — y recuerda que 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 lo has dejado en include: ese es todo el interés, el proveedor mantiene el registro por ti. Si has fijado sus IP en ip4: (o has aplanado tu SPF), no — te toca a ti hacer el seguimiento, y una comprobación periódica se vuelve indispensable.

Deja que Thomas vigile por ti

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

Analiza tu dominio gratis → o crea una cuenta para un SPF vigilado en permanencia.