Les ip4 et ip6 SPF des mécanismes comparent l'adresse de connexion avec une adresse publiée ou CIDR réseau. Elles sont simples lorsque vous contrôlez des serveurs sortants stables, mais une petite erreur de préfixe peut accorder l'autorisation à bien plus d'infrastructures que prévu.
Utilisez l’adresse que le destinataire voit réellement. L'adresse d'interface privée d'un serveur, l'adresse d'un site Web et la portée réseau générale d'un compte cloud ne remplacent pas la source SMTP sortante.
Choisissez la portée justifiée la plus étroite
ip4:192.0.2.70 identifie une adresse IPv4 car le préfixe omis est par défaut /32. ip6:2001:db8::70 de la même manière, la valeur par défaut est /128. Un préfixe /24 IPv4 représente 256 adresses, tandis qu'un préfixe /64 IPv6 couvre un énorme espace d'adressage. La taille du réseau n’est pas une raison pour l’autoriser ; le contrôle et le besoin opérationnel le sont.
RFC 7208 section 5.6 définit les règles de correspondance et de préfixe. Utilisez des adresses complètes et une notation CIDR appropriée. Une valeur abrégée telle que 192.0.2. n'est pas un remplacement valide pour 192.0.2.0/24 .
Exemple concret : les tests de limites détectent les subventions larges
Considérez la politique synthétique v=spf1 ip4:192.0.2.64/28 ip6:2001:db8:1::/64 -all. La plage IPv4 s'étend de 192.0.2.64 à 192.0.2.79 . Une adresse de connexion de 192.0.2.70 correspond ; 192.0.2.80 ne le fait pas et atteint -all si rien d'autre ne correspond.
L'adresse IPv6 2001:db8:1::25 correspond au /64. L'adresse 2001:db8:2::25 ne le fait pas. Ces adresses de documentation réservées servent à raisonner sur la politique, et non aux expéditeurs réels.
Pour une véritable plage proposée, créez les mêmes tests de limites et listez qui contrôle chaque segment inclus. Si le seul expéditeur approuvé est un hôte, comparez l’ensemble d’autorisations avec un mécanisme à adresse unique avant d’approuver le préfixe plus large.
Vérifiez les familles de réseaux et les chemins de sortie
Une source IPv6 native nécessite une autorisation IPv6 . RFC 7208 RFC 7208 §5 nécessite séparément que les adresses IPv6 mappées IPv6 soient vérifiées comme IPv4 ; cela ne fait pas qu'une plage ip4 couvre IPv6 natif. Un système qui commence à utiliser IPv6 peut soudainement atteindre la fin de la stratégie même si ses messages IPv4 continuent de passer. Obtenez des preuves de messages reçus ou des enregistrements d'infrastructure sortante pour les deux familles réellement utilisées.
Tenez également compte du NAT, des passerelles de basculement, des relais régionaux et des tâches planifiées. Un test à partir d'un seul nœud actif peut manquer une route de secours. Ne résolvez pas l’incertitude en autorisant un fournisseur d’hébergement complet. Établissez plutôt l’ensemble de sorties pris en charge et la propriété.
Comprendre le compromis en matière de maintenance
Sous RFC 7208 §4.6.4, ip4 et ip6 ne consomment pas le budget des dix termes provoquant les requêtes DNS lors de l'évaluation du mécanisme. Le destinataire doit encore obtenir le Enregistrement SPF, et la taille et l’exactitude des politiques comptent toujours. Un record avec des centaines de plages copiées n'est pas automatiquement maintenable simplement parce que ces termes ne comptent pas dans cette limite.
Lorsqu'un fournisseur recommande une inclusion, son remplacement par un instantané des adresses IP vous rend responsable des modifications futures. Enregistrez comment les modifications seront détectées, qui les approuvera et comment les adresses obsolètes seront supprimées. Les autorisations obsolètes peuvent à la fois perturber le courrier légitime et conserver l'accès à l'infrastructure que vous n'utilisez plus.
Publier avec une autorisation différente
Conservez l’ancien enregistrement et expliquez les plages exactes ajoutées et supprimées. Validez l'intégralité de l'enregistrement SPF proposé, testez les adresses d'expéditeur connues et les adresses non autorisées à proximité, et vérifiez la réponse TXT publiée. Envoyez ensuite des messages représentatifs via les chemins normaux et de basculement.
Si une adresse se trouve de manière inattendue en dehors de la plage approuvée, étudiez l'itinéraire avant de l'élargir. Une sortie inattendue peut révéler une erreur de configuration ou un expéditeur non approuvé plutôt qu'une autorisation manquante.
Les plats pratiques à emporter
Un mécanisme d'adresse n'est explicite que lorsque sa propriété et ses limites sont explicites. Utilisez les sorties observées, testez les limites de la plage et traitez les futurs changements d’adresse dans le cadre du cycle de vie des autorisations.
Enregistrer la décision et ses limites
Pour le luminaire /28, enregistrez 192.0.2.63 comme extérieur, .64 et .79 comme intérieur et .80 comme extérieur. La correspondance de préfixe SPF inclut toutes les adresses du bloc, pas seulement le sous-ensemble d'adresses d'hôte conventionnel. Si seulement 0,70 est justifié, comparez /32 avec /28 : ce dernier accorde 16 adresses, pas une. Il s'agit d'exemples d'adhésion calculés et non de tests SPF exécutés.