SPF: quién puede enviar correo en nombre de su dominio

SPF es la lista de servidores autorizados a enviar correo en nombre de su dominio. Cómo se escribe el registro, dónde se rompe y qué hacer con cada hallazgo.

SPF es una lista de invitados. Su dominio publica en el DNS un renglón que dice: estos servidores pueden enviar correo en mi nombre, los demás no. Cuando llega un mensaje que dice venir de su empresa, el servidor receptor compara la dirección IP de origen con esa lista.

Lo incómodo de SPF es que la lista tiene que estar completa: cuentan el proveedor de buzones, pero también el boletín, la tienda, el formulario de contacto, el CRM y la aplicación de facturación. Una vía de envío que falta no produce ningún aviso, sino un mensaje que acaba en spam semanas después, sin que nadie relacione una cosa con la otra.

Cómo es el registro

SPF es un único registro TXT publicado en el dominio mismo. Así se ve uno realista:

ejemplo.es.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.25 ~all"

El mecanismo final manda: lo que vaya escrito detrás se ignora sin avisar. Entre ~all y -all la diferencia es práctica: con ~all, un servicio que olvidó declarar sigue entregando, aunque marcado; con -all, deja de entregar. Empiece por ~all, revise unas semanas los informes de DMARC y endurezca después.

El límite de diez consultas

Es la trampa que más dominios rompe y la que nunca se ve mirando el registro. Un SPF puede provocar como máximo diez consultas DNS al evaluarse; cuentan include, a, mx, ptr, exists y redirect, también los que están dentro de los registros incluidos. A la consulta número once el resultado es un error permanente y el registro entero se descarta.

Un registro con cinco include puede estar holgado o muy pasado, según lo que haya dentro de cada uno. Estas cifras las hemos consultado en el DNS antes de publicarlas.

Un caso corriente: Webempresa (4) más Microsoft 365 (1) más Mailchimp (1) más SendGrid (2) más mx (1) suman 9. Se añade Brevo para una campaña y son 10. Se añade Acumbamail y son 11: deja de funcionar todo, incluido Microsoft 365, que llevaba años bien.

Lo que SPF no resuelve solo

SPF comprueba la dirección del sobre, no el remitente que se ve en pantalla. Un mensaje puede pasar SPF y llevar en la línea «De» un nombre ajeno; lo que une ambas cosas es DMARC. Y SPF se rompe con los reenvíos: si el destinatario reenvía a otra dirección, el mensaje llega al segundo servidor desde una IP que no está en su lista. Por eso DKIM es imprescindible: la firma sobrevive al reenvío y a DMARC le basta con una de las dos.

Cómo se configura

El registro se edita donde estén los servidores de nombres del dominio, que no siempre es donde está el buzón: si el dominio está en Dinahosting y el correo en Microsoft 365, se escribe en Dinahosting.

Donde ponemos «tome el valor del panel» es porque no hemos podido confirmar ningún bloque en el DNS. Preferimos decirlo a que usted copie una línea que no existe.

Paso a paso en Dinahosting

1. Entre en el panel, abra Dominios, elija el dominio y Gestión DNS.
2. Busque si ya hay un registro TXT que empiece por v=spf1 en el nombre @. Si lo hay, se edita: no se crea un segundo.
3. Si no lo hay, añada un registro TXT con nombre @.
4. Escriba el contenido en una sola línea: v=spf1, un include por cada servicio que envíe en su nombre, y ~all al final.
5. Guarde. La propagación tarda de unos minutos a unas horas, según el TTL anterior.
6. Vuelva a lanzar la comprobación: el informe cuenta las consultas por usted.

Los hallazgos, uno por uno

Sin registro SPF

Ninguno de los registros TXT del dominio empieza por v=spf1: no existe lista de servidores autorizados.

Importa porque el receptor no tiene con qué distinguir su correo del de quien escribe usando su dominio: sus mensajes legítimos entran en spam más a menudo y las falsificaciones pasan sin fricción.

Qué hacer. Haga la lista de todo lo que envía con su dominio —buzones, boletín, tienda, formularios, facturación, CRM— y publique un solo registro TXT que los nombre todos, terminado en ~all.

Varios registros SPF

Hay dos o más registros TXT que empiezan por v=spf1. El estándar permite exactamente uno.

Importa porque el receptor no elige el mejor ni los suma: descarta SPF por completo, aunque cada uno sea impecable por separado. Suele ocurrir cuando un servicio nuevo añade su línea en vez de editar la que ya estaba.

Qué hacer. Fusiónelos en uno: un v=spf1 al principio, los mecanismos de ambos en medio, un único cierre. Borre después los demás; mientras exista un segundo, SPF sigue sin funcionar.

SPF supera el límite de consultas

Hemos seguido el registro completo, con sus registros incluidos, y hemos contado más de diez consultas.

Importa porque, pasado el límite, la evaluación termina en error y el registro se ignora íntegro. Es un fallo silencioso: el registro sigue ahí, con buen aspecto, y ya no autoriza a nadie, tampoco a sus propios servidores.

Qué hacer. Mire en la tabla de arriba qué bloque cuesta más de lo que aparenta. Quite lo que ya no usa, sustituya a y mx por direcciones fijas y traslade los envíos masivos a un subdominio propio.

El SPF termina en +all

El registro cierra con +all, que declara autorizado a cualquier servidor de internet.

Importa porque anula el sentido del registro y da una falsa sensación de estar cubierto: el dominio «tiene SPF» y la comprobación siempre sale bien, también para quien le suplante.

Qué hacer. Sustituya +all por ~all. Si llevaba años así, es probable que existan vías de envío que nadie ha declarado nunca: revise los informes DMARC antes de pasar a -all.

El SPF termina en ?all

El registro cierra con ?all, el cierre «neutral»: no afirma nada sobre los servidores que no figuran.

Importa porque los receptores tratan «neutral» casi igual que la ausencia de registro. Se hace el trabajo de mantener la lista y no se obtiene el efecto.

Qué hacer. Cambie ?all por ~all: la misma prudencia, con un resultado que los receptores sí utilizan. Más adelante, con los informes DMARC delante, pase a -all.

SPF sin mecanismo final

El registro no termina en ningún mecanismo all.

Importa porque queda sin definir qué debe hacer el receptor con un servidor que no figura en la lista. Cada proveedor decide por su cuenta, y lo que decide suele ser nada.

Qué hacer. Añada ~all al final, después de todos los mecanismos. Compruebe de paso que no queda nada escrito detrás: lo que va después del cierre no se evalúa.

El SPF utiliza ptr

El registro contiene el mecanismo ptr, que autoriza un servidor según su resolución inversa.

Importa porque ptr está desaconsejado desde hace años: varios proveedores grandes no lo evalúan o lo tratan como error, así que los servidores que creía autorizar por esa vía pueden no estarlo en ninguna parte.

Qué hacer. Retírelo y declare esos servidores de otro modo: con ip4: o ip6: si la dirección es fija, con a o mx si son máquinas del propio dominio, con un include si son de un proveedor.

El SPF apunta al vacío

Más de dos de los dominios incluidos no devuelven ningún SPF: la consulta sale, se gasta y vuelve vacía.

Importa porque cada consulta vacía cuenta igual para el límite de diez y porque los receptores estrictos consideran defectuoso el registro completo cuando se acumulan. Casi siempre es el rastro de un servicio dado de baja cuyo include nadie quitó.

Qué hacer. El informe nombra los dominios que no responden. Si ya no usa ese servicio, borre el include. Si lo usa, pida al proveedor la referencia actual: es probable que haya cambiado de nombre.

Registro SPF muy largo

El registro supera los 450 caracteres.

Importa menos que el resto, y conviene decirlo: un registro largo se parte en trozos dentro del DNS y los receptores lo recomponen sin problema. El riesgo está en el camino, porque algunos paneles recortan o reescriben los TXT largos al guardarlos.

Qué hacer. Quite lo que ya no necesite, sobre todo listas de ip4: de servidores retirados, y compruebe tras guardar que el panel lo ha almacenado íntegro.

El SPF remite en círculo

Uno de los registros incluidos remite de vuelta a un dominio que ya estaba en la cadena.

Importa porque la evaluación se interrumpe ahí: lo que quedaba por comprobar no llega a comprobarse y el resultado es un error.

Qué hacer. El informe muestra la cadena completa y el punto donde se cierra el círculo. Suele darse entre un dominio y su subdominio de envíos, cuando cada uno incluye al otro. Uno de los dos tiene que declarar sus servidores directamente.

El dominio incluido tiene varios SPF

Uno de los dominios que usted incluye publica a su vez más de un registro SPF.

Importa porque la regla de «solo uno» rige también dentro: esa rama de su registro queda defectuosa, y el fallo está en la zona DNS de un tercero que probablemente no lo sabe.

Qué hacer. El informe nombra el dominio afectado. Avise al proveedor: es una corrección de un minuto que afecta a todos sus clientes.

Elemento desconocido en el registro SPF

El registro contiene algo que no pertenece al estándar: una errata como incude: o ip: en lugar de ip4:, o una cadena de verificación de otro servicio pegada dentro del SPF.

Importa porque los receptores estrictos dan por defectuoso el registro entero, no solo el elemento raro. La errata pasa desapercibida durante meses porque el registro «está ahí».

Qué hacer. Lea el elemento que indica el informe. Si es una errata, corríjala. Si es la cadena de verificación de otro servicio, sáquela: va en su propio registro TXT.

Preguntas frecuentes

¿Puedo tener dos registros SPF si uno es del dominio y otro de un subdominio?

Sí, y además conviene. La regla de «solo uno» se aplica por nombre: ejemplo.es tiene el suyo y envios.ejemplo.es el suyo, cada uno con sus diez consultas. Lo que no se puede es publicar dos v=spf1 en el mismo nombre.

¿Cuánto tarda en aplicarse un cambio?

Depende del TTL del registro anterior, no del nuevo. Para un cambio delicado, baje antes el TTL a 300 segundos, espere el tiempo del TTL antiguo y cambie entonces.

He añadido el include de mi boletín y el correo normal ha dejado de autenticarse.

Casi con seguridad ha superado el límite de diez consultas. SPF no falla por partes: al pasarse se descarta el registro completo, y con él la autorización de su proveedor de buzones. Libere sitio antes de añadir el servicio.

¿Es suficiente con SPF?

No. SPF comprueba el servidor, no el nombre que el destinatario ve, y se rompe en cuanto alguien reenvía el mensaje. Hacen falta las tres piezas: SPF, DKIM y DMARC, que es la que convierte las otras dos en una instrucción.