Validar un registro SPF significa comprobarlo frente a las reglas que los servidores de correo receptores realmente aplican: la especificación de Sender Policy Framework (RFC 7208). Un registro puede parecer correcto y aun así ser rechazado, así que esto es lo que significa "válido" y cómo corregir los fallos que este validador encuentra.
Qué significa "válido" según la RFC 7208
Un registro SPF válido satisface cada una de estas condiciones a la vez: es el único registro TXT v=spf1 del dominio, empieza con la etiqueta v=spf1, usa solo mecanismos y cualificadores reconocidos, se resuelve en diez consultas DNS o menos, no produce más de dos consultas nulas y termina con un cualificador all. Si falta alguna, los receptores pueden devolver un PermError y tratar el registro como si nunca se hubiera publicado.
Reglas de sintaxis que el validador aplica
- Un solo registro. La RFC 7208 permite exactamente un registro
v=spf1por dominio. Un segundo es un PermError automático: ambos se ignoran. - Orden correcto. La etiqueta de versión
v=spf1debe ir primero y el mecanismoalldebe ir al final. - Solo mecanismos y cualificadores válidos. Los mecanismos permitidos son
include,a,mx,ip4,ip6,existsyall; cada uno puede llevar un cualificador+,-,~o?. Erratas comoip:oincludes:fallan. - Longitud de la cadena. Cualquier cadena de caracteres del registro TXT debe mantenerse dentro de los 255 caracteres, y el registro completo dentro de los 512 bytes, o DNS lo trunca.
Los límites de 10 consultas y 2 consultas nulas
Dos límites numéricos capturan la mayoría de los registros de "sintaxis válida, pero fallan igual". El primero es el conocido tope de diez mecanismos que consultan el DNS por evaluación: cada include, a, mx, ptr y exists cuenta, y los includes anidados cuentan de forma recursiva. El segundo, menos conocido, son las consultas nulas: no más de dos mecanismos pueden resolverse en una respuesta DNS vacía. Rebase cualquiera de los dos y el resultado es un PermError. Si su registro supera el límite de diez consultas, AutoSPF aplana los includes en un registro compacto que valida limpiamente y vuelve a escanear cada 15 minutos; consulte demasiadas consultas DNS para los detalles.
Mecanismos obsoletos y arriesgados
El validador avisa sobre dos cosas que son técnicamente analizables pero que deberían evitarse. El mecanismo ptr está obsoleto según la RFC 7208 (§5.5) porque es lento y poco fiable: sustitúyalo por ip4/ip6 o un include. Y +all autoriza a todo internet a enviar en nombre de su dominio, anulando por completo el propósito de SPF; un registro válido debería terminar en -all o ~all.
Cómo corregir un registro SPF inválido
La mayoría de los fallos de validación se corresponden con una de cuatro correcciones, y nuestra guía sobre cómo solucionar la validación de SPF fallida cubre cada una en detalle:
- ¿Dos registros SPF? Combine todos los remitentes en un único registro
v=spf1. - ¿Más de 10 consultas? Sustituya los includes pesados en consultas por entradas
ip4/ip6, o aplane el registro automáticamente con AutoSPF. - ¿
ptrobsoleto? Elimínelo y autorice esos hosts por IP o include en su lugar. - ¿Cualificador ausente o incorrecto? Asegúrese de que el registro empieza por
v=spf1y termina en-all(o~allmientras hace pruebas).
Reconstruir desde cero suele ser más fácil que parchear: el generador de registros SPF gratuito produce un registro sintácticamente limpio que puede validar aquí en un solo paso.
Dónde se sitúa SPF junto a DKIM y DMARC
Un registro SPF válido es necesario pero no suficiente. DKIM firma el cuerpo del mensaje y DMARC vincula SPF y DKIM con el dominio From visible y fija la política de aplicación. Después de comprobar su registro SPF y de que valide, confirme los otros dos con el verificador de DMARC y la consulta de DKIM gratuitos. Vuelva a validar SPF siempre que añada o elimine un servicio de envío, y audítelo al menos una vez por trimestre; y recuerde que cada subdominio que envía correo necesita su propio registro válido.