SPF redirigir delega la decisión de autorización restante a otra política. Está diseñado para situaciones en las que varios dominios deben compartir políticas y autorizaciones gestionadas de forma centralizada, a menudo dentro de una organización administrativa.
No es un alias para incluir y, después de -all no es una copia de seguridad. Comprender cuándo se ejecuta la redirección es esencial antes de consolidar registros. RFC 7208 sección 6.1 define su comportamiento.
Establecer la condición de delegación
Cuando ningún mecanismo coincide, ningún error anterior ha terminado la evaluación y hay una redirección presente, SPF evalúa el destino de la redirección. La IP de conexión y el remitente permanecen iguales, mientras que el dominio bajo evaluación se convierte en el objetivo. La evaluación resultante proporciona el resultado: la falta SPF en el objetivo se convierte en permerror en lugar de ninguno.
Si algún mecanismo completo está presente en el registro externo, se ignora la redirección. La colocación de redireccionamiento ante todo no lo rescata. Escriba redirigir al final para mayor claridad, pero recuerde que es un modificador y no un mecanismo de coincidencia de izquierda a derecha.
Un mecanismo local puede preceder a la delegación. Por ejemplo, un permiso ip4 explícito puede coincidir antes de consultar la política compartida. Decidir si se prevén tales excepciones; de lo contrario, una política supuestamente central puede no ser toda la historia de la autorización.
Ejemplo resuelto: dos dominios, una política administrada
Suponiendo una sintaxis válida, una seleccionada Registro SPF por nombre y recuperación exitosa DNS , en este dispositivo sintético, east.example.com y west.example.com publican cada uno v=spf1 redirect=policy.example.com. El objetivo compartido publica v=spf1 ip4:192.0.2.30 -all.
Para 192.0.2.30 , cada política externa delega, el ip4 objetivo coincide y el resultado es aprobado. Para 192.0.2.31 , el objetivo alcanza -all y el resultado delegado es fallido. Si el objetivo registro TXT desaparece, las evaluaciones que requieren la redirección producen permerror .
Ahora cambie la política del este a v=spf1 ip4:198.51.100.8 redirect=policy.example.com. Esa dirección adicional pasa localmente, aunque el destino compartido no lo autorice. Por lo tanto, una auditoría de políticas centrales debe leer cada registro de delegación en lugar de revisar sólo el objetivo.
Compare el mismo objetivo en incluir
Si la política exterior en cambio contiene v=spf1 include:policy.example.com ~all, un pase infantil coincide con el incluido. Un fracaso infantil no proporciona el resultado final; el procesamiento se reanuda y el ~all produce softfail .
La redirección lleva el resultado de la política objetivo cuando se invoca. Incluir pregunta si el objetivo pasa y luego continúa bajo la política externa cuando no lo hace. Elija la construcción que coincida con el modelo de propiedad en lugar de traducirlas mecánicamente.
Auditar reglas sensibles al contexto
Redirigir cambia el dominio de evaluación actual manteniendo la entrada del remitente. Por lo tanto, las macros y los mecanismos relativos al dominio pueden depender del dominio o valor del remitente que utilicen. Una política que funciona para un dominio no es automáticamente segura para otro.
Para un servicio de envío de terceros, utilice el mecanismo de integración que admite su documentación actual. RFC 7208 advierte que la redirección a través de límites administrativos puede no comportarse de manera confiable, especialmente cuando la política de destino depende de partes locales. No reemplace una inclusión documentada con una redirección simplemente para acortar el registro visible.
Operar la política compartida de forma segura
Inventario de todos los dominios dependientes y excepciones locales. Asigne un propietario responsable al objetivo compartido. Antes de cambiarlo, pruebe un remitente permitido y uno no permitido para cada contexto de política distinto, incluido IPv6 cuando se utilice. Conserve juntos los registros originales de delegación y compartidos.
Bajo RFC 7208 §4.1 y RFC 7208 §4.6.4, los términos redireccionados y anidados alcanzados consumen el presupuesto de términos DNS SPF . Detecte bucles y crecimiento de dependencia mediante la evaluación en lugar de depender de la corta longitud de cada registro local. Después de un cambio, inspeccione las respuestas autorizadas y recursivas y pruebe el correo recibido del representante.
La conclusión práctica
La redirección es una centralización útil cuando realmente desea una política compartida. Mantenga todo fuera del registro de delegación, audite las excepciones locales y pruebe el contexto del remitente que sobrevive a la delegación.
Mantenga la decisión reproducible
Para east.example.com , la excepción local 198.51.100.8 pasa sin invocar el objetivo compartido; por lo tanto, una interrupción de destino compartido no tiene por qué afectar esa ruta exacta. Una fuente diferente que requiera redirección puede encontrar el error de destino. Registre el registro externo, la entrada del remitente, el objetivo alcanzado y el resultado esperado juntos antes de aprobar la centralización. No se realizó ningún cambio de política compartida ni prueba de interrupción.