Aplatissement SPF est un moyen de remplacer certaines autorisations dépendantes du DNS par des plages d'adresses explicites. Cela peut rendre une évaluation moins dépendante des recherches imbriquées. Cela peut également vous permettre de conserver une copie du réseau changeant de quelqu'un d'autre. Une décision utile consiste donc à comparer le dossier proposé et le processus qui permettra de le maintenir correct.
Établir la contrainte réelle
Commencez par le domaine d'enveloppe exact utilisé par l'application concernée, et pas simplement par le domaine du site Web de l'entreprise. Récupérez le présent enregistrement, ses dépendances et les adresses d'envoi représentatives. Exécutez une évaluation conforme aux normes avec ces entrées et conservez la trace. Une étiquette disant « trop de recherches » ne suffit pas pour décider quoi remplacer.
RFC 7208 section 4.6.4 les limites évaluent les termes dépendants du DNS à l’échelle mondiale à travers la récursivité. Les mécanismes explicites ip4 et ip6 sortent de ce budget à terme. C'est l'avantage potentiel de la recherche ; ce n'est pas une promesse que chaque enregistrement aplati soit petit, correct ou rapide.
Supprimez d’abord les autorisations dont les propriétaires d’entreprise confirment qu’elles sont obsolètes. Vérifiez si une application distincte peut utiliser un sous-domaine d'enveloppe correctement configuré. Ni le nettoyage ni la segmentation ne doivent être effectués aveuglément : répertoriez les messages concernés et confirmez que le fournisseur prend en charge l'identité proposée. Utilisez le inventaire des expéditeurs se connecter un enregistrement accès à un vrai service.
Comparez le sens, pas seulement les listes d'adresses
Sous RFC 7208 §5.2, une inclusion est une évaluation d'une autre politique, pas un fichier texte de réseaux à copier. Les qualificatifs, l'ordre, les inclusions imbriquées, la redirection et les macros peuvent affecter son résultat. Un convertisseur doit conserver l'autorisation prévue pour les entrées prises en charge ou déclarer explicitement ce qu'il ne peut pas représenter. Rejetez une conversion qui collecte simplement toutes les valeurs d'apparence IP à partir d'une arborescence.
Pour chaque remplacement proposé, demandez quelle politique en amont il représente, quelles entrées ont été testées, si IPv6 est couvert et comment les changements sont détectés. Conservez la documentation originale des dépendances et du fournisseur à côté de la sortie générée. Évitez d'élargir les réseaux adjacents à une plage plus large simplement pour raccourcir le texte, à moins que cette plage entière ne soit autorisée de manière indépendante.
Rendre visible le coût de maintenance
Il s’agit d’une décision illustrative et non d’un déploiement testé. Un expéditeur de facturation fait référence à une stratégie de fournisseur qui autorise actuellement deux plages. Une copie aplatie contient ces plages. Demain le prestataire en ajoute un troisième. La dépendance d'origine peut exposer la nouvelle autorisation via DNS ; la copie ne le contiendra pas jusqu'à ce qu'une actualisation réussie publie une mise à jour. Le problème inverse se produit lorsque le fournisseur retire une plage mais que la copie la conserve.
Attribuez à quelqu'un la responsabilité de la fraîcheur, des actualisations échouées, des changements importants inattendus et de la restauration d'urgence. Demandez une alerte lorsque le processus de génération s'arrête, plutôt que uniquement lorsque l'enregistrement publié est syntaxiquement valide. Un enregistrement périmé valide peut toujours être un mauvais enregistrement.
Testez un candidat avant son remplacement
Conservez l'enregistrement précédent et produisez une différence explicite avant et après. Testez les expéditeurs connus, une adresse non autorisée, chaque famille IP pertinente et le résultat final sans correspondance. Inspectez la réponse TXT réelle, y compris sa taille et les limites des chaînes. RFC 7208 §3.3 et RFC 7208 §3.4 expliquer pourquoi le fractionnement d'une valeur TXT en chaînes de caractères ne supprime pas la nécessité de gérer la réponse DNS globale.
Utilisez un test d’envoi contrôlé après publication approuvée. Enregistrez le résultat de l'authentification du système de réception et l'identité de l'enveloppe qu'il a évaluée. N'assimilez pas un SPF amélioration avec DMARC alignement ou placement garanti dans la boîte de réception.
Choisissez un modèle opérationnel que vous pouvez pérenniser
Conservez la politique basée sur les dépendances lorsque son évaluation est acceptable et que son appropriation continue est plus claire. Envisagez l'aplatissement uniquement avec une couverture sémantique démontrée, un mécanisme d'actualisation fiable, des alertes et un plan de sortie. Un nombre de recherches plus petit constitue une preuve utile, mais pas la décision d'acceptation complète. Pour la maintenance après l'adoption, continuez avec SPF aplati et rassis.
Enregistrez la prochaine décision
Pour une conversion hypothétique, répertoriez les constructions en amont prises en charge, l'heure de l'instantané source, les identités/IP testées, les résultats de terminal attendus et qui détecte les plages ajoutées ou retirées. Si une autorisation macro-dépendante ne peut pas être représentée pour les entrées prévues, le candidat n'est pas prêt simplement parce que son nombre de recherches est plus petit. Aucune conversion, changement DNS ou test d'envoi n'a été exécuté pour cet article.