SPF rediriger délègue la décision d’autorisation restante à une autre stratégie. Il est conçu pour les situations dans lesquelles plusieurs domaines doivent partager une autorisation et une politique gérées de manière centralisée, souvent au sein d'une seule organisation administrative.
Ce n'est pas un alias pour include et ce n'est pas une sauvegarde après -all . Comprendre quand la redirection s'exécute est essentiel avant de consolider les enregistrements. RFC 7208 section 6.1 définit son comportement.
Établir la condition de délégation
Lorsqu'aucun mécanisme ne correspond, qu'aucune erreur antérieure n'a mis fin à l'évaluation et qu'une redirection est présente, SPF évalue la cible de la redirection. L'adresse IP de connexion et l'expéditeur restent les mêmes, tandis que le domaine évalué devient la cible. L'évaluation qui en résulte fournit le résultat, le SPF manquant au niveau de la cible devenant permerror plutôt que rien.
Si un mécanisme all est présent dans l’enregistrement externe, la redirection est ignorée. Le placement de la redirection avant tout ne le sauve pas. Écrivez redirect à la fin pour plus de clarté, mais rappelez-vous qu'il s'agit d'un modificateur plutôt que d'un mécanisme de correspondance de gauche à droite.
Un mécanisme local peut précéder la délégation. Par exemple, une autorisation ip4 explicite peut correspondre avant que la politique partagée ne soit consultée. Décider si de telles exceptions sont envisagées ; sinon, une politique soi-disant centrale ne constitue peut-être pas toute l’histoire de l’autorisation.
Exemple concret : deux domaines, une stratégie gérée
En supposant une syntaxe valide, une sélection Enregistrement SPF par nom et récupération DNS réussie, dans cet appareil synthétique, east.example.com et west.example.com publient chacun v=spf1 redirect=policy.example.com. La cible partagée publie v=spf1 ip4:192.0.2.30 -all.
Pour 192.0.2.30 , chaque politique externe délègue, l'adresse IP4 cible correspond et le résultat est réussi. Pour 192.0.2.31 , la cible atteint -all et le résultat délégué est un échec. Si la cible Enregistrement TXT disparaît, les évaluations nécessitant la redirection produisent permerror .
Maintenant, changez la politique Est en v=spf1 ip4:198.51.100.8 redirect=policy.example.com. Cette adresse supplémentaire passe localement, même si la cible partagée ne l'autorise pas. Un audit de politique centrale doit donc lire chaque dossier de délégation plutôt que d’examiner uniquement la cible.
Comparez la même cible sous inclure
Si la stratégie externe contient à la place v=spf1 include:policy.example.com ~all, un pass enfant correspond à l'inclusion. Un échec enfant ne fournit pas le résultat final ; le traitement reprend et le ~all externe produit softfail .
La redirection transporte le résultat de la politique cible lorsqu'elle est invoquée. Include demande si la cible réussit, puis continue sous la stratégie externe si ce n'est pas le cas. Choisissez la construction qui correspond au modèle de propriété au lieu de traduire mécaniquement entre eux.
Auditer les règles contextuelles
La redirection modifie le domaine d'évaluation actuel tout en conservant l'entrée de l'expéditeur. Les macros et les mécanismes relatifs au domaine peuvent donc dépendre du domaine ou de la valeur de l'expéditeur qu'ils utilisent. Une politique qui fonctionne pour un domaine n'est pas automatiquement sûre pour un autre.
Pour un service d’envoi tiers, utilisez le mécanisme d’intégration pris en charge par sa documentation actuelle. RFC 7208 prévient que la redirection au-delà des frontières administratives peut ne pas se comporter de manière fiable, en particulier lorsque la politique cible dépend de parties locales. Ne remplacez pas une inclusion documentée par une redirection simplement pour raccourcir l'enregistrement visible.
Gérer la politique partagée en toute sécurité
Inventoriez tous les domaines dépendants et les exceptions locales. Attribuez un propriétaire responsable à la cible partagée. Avant de le modifier, testez un expéditeur autorisé et un expéditeur non autorisé pour chaque contexte de stratégie distinct, y compris IPv6 lorsqu'il est utilisé. Conservez ensemble les enregistrements de délégation et partagés originaux.
Sous RFC 7208 §4.1 et RFC 7208 §4.6.4, la redirection et les termes imbriqués atteints consomment le budget de termes SPF DNS . Détectez les boucles et la croissance des dépendances grâce à l’évaluation plutôt que de vous fier à la courte longueur de chaque enregistrement local. Après un changement, inspectez les réponses faisant autorité et récursives et testez le courrier reçu du représentant.
Les plats pratiques à emporter
La redirection est une centralisation utile lorsque vous souhaitez vraiment une politique partagée. Gardez tout hors du dossier de délégation, auditez les exceptions locales et testez le contexte de l'expéditeur qui survit à la délégation.
Gardez la décision reproductible
Pour east.example.com , l'exception locale 198.51.100.8 est transmise sans appeler la cible partagée ; une panne de cible partagée n’a donc pas besoin d’affecter ce chemin exact. Une autre source nécessitant une redirection peut rencontrer l’erreur cible. Enregistrez ensemble l’enregistrement externe, les entrées de l’expéditeur, l’objectif atteint et le résultat attendu avant d’approuver la centralisation. Aucune modification de stratégie partagée ni test de panne n’a été effectué.