Publicar un registro SPF no protege nada si ese mismo registro supera un umbral que casi nadie verifica. La causa más frecuente de fallo SPF rara vez es su ausencia total. Viene de un registro mal construido, que supera el límite de 10 consultas DNS fijado por la RFC 7208 sin que nada avise al remitente antes del incidente. Un registro SPF válido contiene la lista de servidores autorizados a enviar emails para un dominio; más allá de 10 consultas DNS necesarias para evaluarlo, el servidor receptor devuelve un error PermError que invalida la autenticación para la totalidad de los mensajes del dominio, no solo para el remitente que sobra.
Lo que un registro SPF autoriza realmente
Un registro SPF (Sender Policy Framework) es un registro DNS de tipo TXT publicado en un dominio, que lista las direcciones IP autorizadas a enviar emails en su nombre. Un servidor receptor, Gmail u Outlook por ejemplo, consulta ese DNS y compara la IP de conexión con esa lista. El SPF verifica concretamente el MAIL FROM, también llamado Return-Path, la dirección técnica de los rebotes y las NDR, y no la dirección que se muestra en el campo «De:» del cliente de correo. Esta distinción deja una brecha abierta al spoofing visual.
Los mecanismos que componen el registro SPF
La sintaxis SPF se apoya en una serie de mecanismos que, encadenados, definen quién tiene derecho a enviar. ip4: y ip6: declaran directamente un rango de direcciones, sin consultar el DNS una segunda vez. a y mx verifican que la IP emisora corresponde al registro A o a los servidores MX del dominio citado. include: delega la verificación al registro SPF de otro dominio, típicamente el de un proveedor de envío (ESP, CRM, herramienta de facturación). ptr realiza una resolución inversa, hoy desaconsejada por la propia RFC 7208 por su lentitud. exists comprueba la existencia de un registro A construido dinámicamente. El modificador redirect, en cambio, no se añade a la lista: sustituye por completo la evaluación por la de otro registro, algo así como una redirección HTTP aplicada al DNS. Cada uno de estos mecanismos, salvo ip4 e ip6, consume una consulta DNS distinta en el momento de la evaluación. Un include: puede contener a su vez otros include: anidados, sin que la línea visible lo deje adivinar. El orden de escritura también importa: el servidor receptor evalúa los mecanismos de izquierda a derecha y se detiene en el primero que coincide con la IP emisora. Colocar los servidores internos más utilizados al principio del registro no cambia el resultado final. Solo acelera la evaluación en dominios con alto volumen de envío.
Los calificadores -all, ~all, ?all: qué pasa con un email no conforme
Un registro SPF siempre termina con un calificador que fija el destino de un email enviado desde una IP ausente de la lista. -all (fail estricto) pide al servidor receptor que rechace el mensaje. ~all (softfail) pide que lo acepte pero lo marque como sospechoso, a menudo enrutándolo hacia el spam. ?all (neutral) no da ninguna instrucción clara, lo que equivale a dejar que cada proveedor de correo decida por su cuenta. Un último calificador, +all, autoriza explícitamente a cualquier IP a enviar en nombre del dominio; solo tiene sentido para desactivar voluntariamente el SPF en fase de pruebas, nunca en producción. Gmail y Microsoft 365 tratan el softfail con una tolerancia que disminuye cada año. Un dominio todavía configurado en ~all por prudencia suele acabar migrando a -all una vez que DKIM y DMARC están en marcha; sin ese paso, el SPF se limita a sugerir desconfianza en lugar de zanjarla.
Un registro SPF comentado línea por línea
Tomemos un ejemplo representativo de un dominio que envía tanto desde sus propios servidores como a través de un ESP externo:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net mx -all
v=spf1 declara la versión del protocolo, siempre idéntica. ip4:203.0.113.10 autoriza directamente el servidor de correo interno de la empresa, sin coste de lookup. include:_spf.google.com delega la autorización en los servidores de Google Workspace, usados aquí para los emails de los empleados. include:sendgrid.net hace lo mismo para las campañas enviadas vía SendGrid. mx añade automáticamente los servidores MX del dominio a la lista de remitentes válidos. -all cierra el registro en fail estricto: cualquier IP ausente de esta lista ve su mensaje rechazado. Este registro ya consume 3 lookups de los 10 permitidos (los dos include: y el mx), sin contar que cada include: puede a su vez disparar varias subconsultas una vez resuelto.
El límite de 10 lookups DNS y el error PermError
La RFC 7208, sección 4.6.4, fija dos topes distintos sobre la evaluación de un registro SPF. El primero, el más conocido, limita a 10 el número de consultas DNS disparadas por los mecanismos include, a, mx, ptr, exists y el modificador redirect; ip4 e ip6 no cuestan ninguna, ya que la dirección está escrita directamente en el registro. El segundo tope, menos documentado, limita a 2 el número de «void lookups» tolerados: una consulta DNS que vuelve sin respuesta (NXDOMAIN), generalmente causada por un include: que apunta a un dominio mal escrito o a un proveedor dado de baja cuyo registro fue eliminado (AutoSPF, marzo de 2026). Superar cualquiera de los dos límites produce el mismo veredicto: PermError. El servidor receptor detiene entonces la evaluación y trata la autenticación como un fallo, para la totalidad de los mensajes del dominio, incluidos los enviados desde una IP perfectamente legítima y documentada tres líneas más arriba en el registro.
El aplanamiento SPF, conocido también como SPF flattening, resuelve este exceso sustituyendo cada include: por la lista bruta de direcciones IP que designa. La evaluación entonces solo cuesta un único lookup, sea cual sea el número de proveedores de envío citados al principio. Proveedores especializados en deliverability como dmarcian o PowerDMARC documentan esta técnica y ofrecen servicios que recalculan el registro cada vez que cambia una IP del lado del proveedor. El procedimiento tiene su propio tope: una cadena TXT DNS está limitada a 255 caracteres por segmento. Un registro aplanado que lista decenas de direcciones IP directamente a veces acaba acercándose peligrosamente a ese límite, lo que obliga a dividirlo en varias cadenas concatenadas.
Ahí está el escenario clásico en un equipo de growth: las campañas acaban en spam, sin que llegue ninguna explicación desde el SaaS de emailing utilizado, que sin embargo muestra «SPF configurado». El dashboard verifica la existencia y la sintaxis del registro. Nunca recalcula el número de lookups una vez resueltos en cascada todos los include:. Un dominio que ha ido acumulando Google Workspace, un ESP transaccional, una herramienta de marketing automation y un CRM puede superar el límite sin que ninguna de esas integraciones, vista por separado, parezca responsable.
Verificar el registro SPF antes de que se rompa
Verificar el registro SPF no requiere ninguna herramienta de pago. El método más directo se desarrolla en tres pasos:
- Consultar el DNS por línea de comandos con
dig txt tudominio.com(onslookup -type=txt tudominio.comen Windows) para leer el registro tal como está realmente publicado, no tal como se introdujo en la interfaz del registrar. - Pasar ese registro por un verificador SPF online que resuelva cada
include:anidado y muestre el recuento total de lookups, en lugar de contar los mecanismos a mano. - Repetir este control cada vez que se añada un nuevo servicio de envío (ESP, herramienta de facturación, plataforma de selección de personal que envía emails a candidatos) y no solo en el momento de la configuración inicial.
Google Postmaster Tools es la herramienta de referencia del lado de Gmail. El SNDS hace lo mismo en Microsoft para el seguimiento de reputación IP. Ambos muestran un historial de autenticación. Ninguno de los dos avisa de un exceso de lookups antes de que produzca un PermError real en un envío real.
El doble registro y los errores más frecuentes
Un dominio no debe publicar más que un único registro SPF. Tener dos, a menudo porque una agencia añadió el suyo sin eliminar el que ya existía, produce un nuevo PermError: la RFC 7208 no prevé ninguna fusión automática entre dos registros TXT de tipo SPF. El otro error recurrente consiste en olvidar un proveedor de envío externo en la lista, una herramienta de encuestas o una plataforma de selección que envía emails transaccionales en nombre del dominio sin haber sido nunca añadida al registro. Estos mensajes fallan silenciosamente hasta que un cliente avisa de que no ha recibido nada.
El reenvío de email hace fallar el SPF: lo que hace (y no hace) SRS
Un email reenviado rompe casi siempre el SPF, por construcción del propio protocolo. El servidor que retransmite el mensaje nunca aparece en el registro SPF del dominio de origen, así que la autenticación falla del lado del destinatario final. El Sender Rewriting Scheme (SRS) corrige este caso concreto reescribiendo la dirección MAIL FROM del mensaje con el dominio del servidor relay, que sí está autorizado en su propio SPF (documentación de Microsoft Learn, septiembre de 2025). Este mecanismo tiene un punto ciego documentado por el propio Microsoft: el SPF valida entonces el dominio del relay, mientras que el campo «From» visible para el destinatario sigue mostrando el dominio de origen.
La documentación de Microsoft lo deja claro: SRS no resuelve el caso de los mensajes reenviados que fallan en DMARC, ya que este protocolo exige una alineación entre el dominio validado por SPF (o DKIM) y el dominio mostrado en el campo From.
Un mensaje puede así pasar el SPF gracias a SRS y aun así fallar en DMARC reject, por falta de alineación entre los dos dominios verificados.
SPF, DKIM y la alineación DMARC: el mecanismo que protege de verdad la reputación
SPF y DKIM no le dicen lo mismo al servidor receptor. SPF valida el MAIL FROM, DKIM firma criptográficamente el mensaje completo. DMARC añade una capa que los dos protocolos ignoran por separado: la alineación, es decir, la verificación de que el dominio autenticado por SPF o DKIM corresponde efectivamente al dominio mostrado en el campo «From» que lee el usuario. Sin esa alineación, un mensaje puede validar el SPF a través de un ESP externo y a la vez mostrar un dominio de remitente completamente distinto, que es exactamente el esquema de un ataque de phishing por suplantación. Este triple control condiciona el complaint rate y la lucha contra el spam y el phishing tanto en Gmail como en Outlook.
Un registro SPF limpio no compensa una lista llena de direcciones muertas: una campaña enviada a direcciones inexistentes dispara el hard bounce rate, lo que degrada la sender reputation que el SPF y el DKIM se supone que protegen, por muy cuidada que esté la configuración DNS. Verificar la lista antes del envío, una práctica básica de list hygiene, sale más barato en términos de reputación que filtrar a posteriori los Enhanced Status Codes 5.1.1 devueltos por los servidores de destino una vez lanzada la campaña. El DMARC cierra el círculo: sin él, SPF y DKIM siguen siendo dos verificaciones aisladas, sin ningún vínculo garantizado con la dirección que el destinatario realmente mira.
Un dominio correctamente autenticado nunca se nota: no aparece en ningún informe de incidente, precisamente porque nadie necesita hablar de él.
