Por qué tu registro SPF falla una y otra vez (y cómo arreglarlo)

Qué comprueba realmente SPF

SPF —Sender Policy Framework— es un registro TXT en tu dominio que enumera qué servidores están autorizados a enviar correo en tu nombre. El servidor receptor consulta ese registro, lo compara con la dirección IP que acaba de conectarse y decide si la conexión está autorizada.

Dos detalles sobre qué compara explican casi toda la confusión con SPF:

• SPF comprueba el remitente del sobre, no la dirección From: que ve tu destinatario. El remitente del sobre (el MAIL FROM de la conversación SMTP, también llamado ruta de retorno) es invisible en el cliente de correo. Un mensaje puede pasar SPF mientras muestra una dirección From: completamente distinta y falsificada, y por eso SPF por sí solo no detiene la suplantación.
• SPF comprueba la IP que conecta y nada más. No inspecciona el mensaje, ni las cabeceras, ni el contenido. Es una única pregunta: ¿esta IP tenía permiso para conectar en tu nombre?

Así que un fallo de SPF casi nunca significa que tu registro esté mal formado. Normalmente significa que el correo salió de algún sitio que el registro no enumera, o que el registro no se pudo evaluar por completo. Son problemas distintos con soluciones distintas, y el resto de esta guía los separa.

Cómo leer tu propio registro SPF

Un registro SPF es una sola línea de TXT, y se lee sin dificultad en cuanto conoces sus cuatro partes.

Mecanismos: quién tiene permiso

Cada término añade remitentes permitidos. ip4: e ip6: enumeran direcciones o rangos directamente. a autoriza aquello a lo que apunte el registro A de tu dominio. mx autoriza tus propios servidores de correo. include: es el que más importa en la práctica: incorpora el registro SPF completo de otro dominio, y así autorizas a Google, Microsoft o un proveedor de envíos masivos sin conocer sus direcciones.

include: es una delegación, no una copia. La otra parte puede cambiar su lista cuando quiera y tu registro la sigue, que es justo el objetivo y también el motivo de que tu registro pueda romperse sin que lo hayas tocado.

Cualificadores: qué pasa al coincidir

Cada mecanismo puede llevar un prefijo. + es pass y es el valor por defecto, así que un mx suelto significa +mx. - es fallo duro: rechazar. ~ es fallo blando: aceptar, pero marcarlo. ? es neutral: sin opinión, lo que equivale a no tener política.

El all del final

El último término es casi siempre un mecanismo all, y decide qué pasa con todos los remitentes que el registro no ha enumerado. -all dice rechazar todo lo demás. ~all dice aceptar pero marcarlo. +all autoriza a internet entero y siempre es un error.

Empieza con ~all mientras estés averiguando quién envía legítimamente por ti, y pasa a -all cuando tus informes DMARC estén limpios. Ir directo a -all sin esas pruebas es como un sistema de facturación olvidado o un servicio de soporte deja de llegar a nadie.

Exactamente un registro, sin excepciones

Un dominio puede publicar un registro SPF. Dos registros TXT que empiecen por v=spf1 son un permerror, y un permerror significa que la comprobación no se puede evaluar en absoluto: en un receptor estricto eso es peor que un simple fallo. Pasa constantemente, porque el asistente de configuración de un proveedor nuevo añade su propio registro en lugar de editar el tuyo. Fusionarlos significa un registro con los dos conjuntos de mecanismos, no dos registros.

El límite de diez consultas, el asesino silencioso

Es la causa más común de un registro SPF que parece perfecto y falla igualmente.

La especificación limita la evaluación de SPF a diez consultas DNS. Cada include:, a, mx, ptr y exists: cuesta una, y las consultas dentro de cada registro incluido también cuentan. Un include: que a su vez contiene tres includes cuesta cuatro de tus diez. Si superas el límite el resultado es permerror: no un fallo, sino un registro no evaluable, que muchos receptores tratan como no autenticado.

Lo desagradable es que es invisible y crece solo. Tu registro pasaba cuando lo escribiste. Meses después, uno de tus proveedores añadió un include: a su propio registro, tu total superó los diez y tu correo empezó a marcarse sin que nada cambiara por tu parte. ip4: e ip6: no cuestan ninguna consulta, y ahí está tu principal palanca.

Cuenta las tuyas antes de dar por bueno el registro. Consulta el registro TXT de tu dominio, luego el registro de cada dominio incluido, y sigue hasta que no quede nada por expandir. Una herramienta de consulta DNS lo hace rápido: busca el registro TXT y después sigue cada include: de uno en uno.

Por qué falla el correo cuando el registro parece correcto

Si el registro es sintácticamente válido y está dentro del límite de consultas, repasa esto en orden.

• Algo envía desde un servicio no enumerado. Los sospechosos habituales son un CRM, un sistema de facturación o de tickets, una plataforma de marketing, una herramienta de monitorización o un servidor de aplicaciones que envía por su propio agente local. Cada uno necesita un include: o su rango de IPs.
• El remitente del sobre es otro dominio. Una plataforma que envía «en nombre de» ti suele usar su propia ruta de retorno, así que SPF se comprueba contra su dominio y pasa mientras tu alineación DMARC sigue fallando. El mensaje puede estar autenticado y no alineado al mismo tiempo.
• Un subdominio sin registro propio. SPF no se hereda. El correo de mail.example.com se comprueba contra ese nombre exacto, y si no tiene registro TXT el resultado es none, no tu política del ápice. Publica un registro por cada subdominio que envíe, y un v=spf1 -all vacío en los subdominios que nunca deberían enviar.
• El registro cambió y las cachés no se han puesto al día. Tu registro TXT lleva una TTL como cualquier otro, así que un arreglo no está activo en todas partes en el momento de guardarlo: cómo funcionan la TTL y la propagación explica los tiempos.
• Un include: obsoleto. Un proveedor que dejaste de usar y cuyo dominio ya no resuelve puede producir un permerror, y a nadie le interesa avisarte.

El reenvío rompe SPF, por diseño

Esto no es culpa tuya y no se puede arreglar en tu registro, así que conviene entenderlo antes de dedicarle un día.

Cuando un destinatario reenvía tu mensaje —un alias universitario, una regla .forward, una lista de correo—, el servidor que reenvía se conecta al destino final usando su propia dirección IP mientras mantiene tu dominio como remitente del sobre. El receptor comprueba tu registro SPF contra una IP de la que nunca has oído hablar, y falla. Con razón: esa IP, efectivamente, no está autorizada por ti.

Existen dos mitigaciones, y ninguna es un cambio en SPF. DKIM firma el mensaje criptográficamente y sobrevive al reenvío, así que un mensaje reenviado que falla SPF puede pasar DKIM y por tanto DMARC, y eso es la razón principal para usar los dos. SRS (Sender Rewriting Scheme) es tarea de quien reenvía: reescribe el remitente del sobre a su propio dominio para que SPF se compruebe contra él. No puedes obligar a un reenviador remoto a hacerlo.

La conclusión práctica: nunca diagnostiques SPF desde una copia reenviada de un mensaje, y no pases a -all dando por hecho que todo fallo que ves es un atacante.

Que SPF pase no es que DMARC pase

Un resultado pass en las cabeceras mientras DMARC sigue fallando desconcierta a casi todo el mundo, y el motivo es la alineación.

SPF autentica el remitente del sobre. DMARC exige además que el dominio autenticado coincida con el dominio From: visible. Una plataforma que envía con su propia ruta de retorno puede darte un pass de SPF impecable en su dominio, lo que no hace nada por tu dominio From:: la comprobación SPF pasó, la de alineación no, y DMARC falla por eso.

Así que SPF nunca fue una defensa contra la suplantación: un atacante puede publicar un SPF perfectamente válido para su propio dominio y seguir poniendo tu nombre en el campo From:. DMARC es lo que ata la autenticación a la dirección que el destinatario ve de verdad, y también lo que te envía los informes que te dicen quién envía como tú. La guía de SPF, DKIM y DMARC explica cómo encajan los tres y cómo desplegar una política.

Cómo arreglar un registro que falla

En este orden, porque cada paso elimina causas que los siguientes esconderían.

• Confirma que hay exactamente un registro. Consulta tus registros TXT y cuenta cuántos empiezan por v=spf1. Más de uno es un permerror: fusiona los mecanismos en un solo registro antes de investigar nada más.
• Cuenta las consultas, incluidas las anidadas. Si estás en diez o cerca, sustituye el include: más pesado por los rangos ip4: a los que resuelve y elimina los includes de proveedores que ya no usas. Quitar un solo include abandonado suele dejarlo todo otra vez por debajo del límite.
• Inventaría quién envía realmente por ti. Los informes agregados de DMARC son la única fuente fiable aquí: enumeran cada IP que envía como tu dominio, incluidos los sistemas que nadie recuerda. Adivinar produce un registro incompleto.
• Elimina ptr por completo. Está obsoleto, es lento, poco fiable, y algunos receptores ignoran los registros que lo usan.
• Mantén ~all hasta que los informes estén limpios, y luego pasa a -all. Un fallo duro sobre un registro incompleto rebota tu propio correo.
• Baja la TTL antes de editar y verifica desde fuera. Comprueba el registro TXT en vivo con una herramienta de consulta DNS en lugar de confiar en tu panel, y vuelve a comprobarlo cuando haya expirado la TTL antigua.

Errores comunes

• Dos registros SPF porque el asistente de un proveedor añadió el suyo. Permerror, y peor que un fallo.
• Superar las diez consultas y no enterarse nunca, porque el fallo es un permerror en los registros de otra persona.
• Saltar a -all antes de conocer a todos los remitentes legítimos. El sistema que olvidaste suele ser el que factura a tus clientes.
• Esperar que los subdominios hereden. No lo hacen. Publica un registro por cada subdominio que envíe.
• Usar ptr, o +all, que autoriza a todo el mundo.
• Diagnosticar desde un mensaje reenviado. El reenvío falla SPF legítimamente y no te dice nada sobre tu registro.
• Dar por hecho que un pass de SPF implica que DMARC pasa. Sin alineación con el dominio From: visible, no lo implica.
• Editar el registro y probar inmediatamente. El registro TXT antiguo sigue en caché durante toda su TTL.

En resumen

SPF compara la IP que conecta contra un registro TXT y comprueba el remitente invisible del sobre, no la dirección From: que lee tu destinatario. Publica exactamente un registro, mantén el total de consultas DNS —incluidas las anidadas dentro de cada include:— en diez o menos, enumera todos los servicios que envían legítimamente por ti, da a cada subdominio emisor su propio registro y quédate en ~all hasta que tus informes DMARC demuestren que la lista está completa. El correo reenviado fallará SPF hagas lo que hagas, y por eso existen DKIM y DMARC a su lado. Lee el registro TXT en vivo de cualquier dominio, expande cada include: y ve la TTL restante con la herramienta gratuita de consulta DNS.

Herramientas y guías relacionadas:

• Búsqueda de DNS: Consulta registros A, AAAA, MX, TXT, NS y más, con valores y TTL, además de DNS inverso.
• Cómo leer un informe DMARC sin ahogarte en XML: Qué contiene un informe agregado de DMARC

Preguntas frecuentes