Limites de recherche SPF: la trace comprend et dépannage en toute sécurité
Inspecter les termes de déclenchement du DNS, séparer une estimation budgétaire statique du résultat d'un message et vérifier le service d'envoi avant d'éditer le SPF.
Commencez par le chemin d'envoi qui a échoué
Un avertissement SPF devient plus facile à examiner lorsque vous savez quel service a envoyé le message. Enregistrez le fournisseur, le temps d'envoi, la réponse du destinataire et le domaine de l'expéditeur d'enveloppe. L'adresse visible From est un contexte utile, mais ce n'est pas automatiquement le domaine SPF évalué. Gardez le message original ou le journal du fournisseur disponible. Un changement au mauvais domaine peut laisser le chemin échoué intact tout en perturbant un service différent. Utilisez un petit dossier de preuve avant d'ouvrir le vérificateur du budget de recherche SPF : ce qui s'est passé, quelle identité a été vérifiée et quel résultat le système de réception a signalé.
Compter les termes, pas tous les paquets DNS
Le RFC 7208 fixe une limite de dix termes entraînant une DNS lors de l'évaluation SPF. Les mécanismes et modificateurs pertinents incluent, a, mx, ptr, existe et redirection. Les mécanismes littéraires ip4 et ip6 n'utilisent pas ce terme. Ce n'est pas simplement un compte de chaque paquet DNS que votre ordinateur envoie. La mise en cache DNS, les recherches d'adresses et les limites de protocole supplémentaires compliquent cette comparaison. Le vérificateur affiche explicitement son modèle de nombre de termes. Lisez son explication avant de traiter un certain nombre de demandes TXT ou un compte de réseau de navigateur comme la même chose que le budget d'évaluation SPF.
| Durée | Utilise le budget ? | Interprétation |
|---|---|---|
| ip4 / ip6 | Numéro | Adresse ou réseau littéraire |
| a / mx / ptr / existe | Oui | Évaluation dépendante du DNS |
| inclure | Oui | Évaluer également les termes de la politique incluse |
| redirection | Après | Continuer avec une autre politique |
| Tous | Numéro | Correspondance; les mécanismes ultérieurs sont inaccessibles |
Il s'agit d'un budget à terme d'évaluation, pas d'un compte de chaque paquet réseau DNS. Les estimations statiques ont des limites.
Essayez une politique de collage avec une limitation connue
Utilisez le mode coller avec l'enregistrement de démonstration: v=spf1 ip4:192.0.2.0/24 mx include:_spf.example.com ~all. Le vérificateur rapporte trois termes DNS locaux : a, mx et include. L'entrée ip4 contribue à zéro. Il signale également une estimation incomplète et zéro demande TXT parce que le mode coller ne récupère pas la politique incluse. Ces domaines et adresses exemples décrivent une configuration fictive; ne publiez pas l'enregistrement comme votre propre politique d'autorisation. Le résultat utile est un inventaire local, pas la preuve que l'intégralité du chemin d'envoi se situe dans la limite du protocole.
Suivent des politiques ayant une portée claire
Si vous contrôlez le domaine enquêté, le mode live peut lire sa politique publique TXT et suivre les domaines littéralement inclus ou rediriger. Cela partage les domaines interrogés avec Google Public DNS, comme l'explique l'outil. Revoir les lignes de politiques qui en résultent, en particulier celles qui sont répétées, y compris les succursales non réglées. La mise en oeuvre résume les branches avec prudence; un expéditeur réel peut s'arrêter avant de visiter chaque branche. Les macros, les cycles récursifs ou les limites de sécurité rendent l'estimation incomplète. Une somme statique élevée est une raison d'étudier une voie d'évaluation spécifique, plutôt que de prouver que tout message légitime doit échouer.
Faire correspondre chaque autorisation à un service actuel
Faire un inventaire court reliant chaque gamme d'adresses à un expéditeur réel : service de boîte aux lettres, plate-forme de newsletter, système de support ou fournisseur de transaction. Demandez à l'administrateur responsable ou consultez les instructions du fournisseur lorsqu'une entrée n'a pas de propriétaire clair. Un domaine inconnu n'est pas une raison suffisante pour le supprimer. Inversement, un nom de fournisseur reconnaissable ne prouve pas que chaque intégration historique est toujours nécessaire. Inscrivez pourquoi une entrée est conservée ou retirée. Cet inventaire facilite le diagnostic d'un incident ultérieur et permet d'éviter de modifier une politique uniquement pour obtenir un nombre plus petit affiché.
Ne pas aplatir la question d'entretien
Le remplacement du fournisseur inclut des plages IP copiées peut changer qui tient la liste d'autorisation. Un nombre de termes plus restreint peut sembler attrayant alors que la liste copiée devient obsolète lorsque le fournisseur change son infrastructure. Évaluer toute réécriture proposée en fonction de la configuration documentée du fournisseur et de votre processus de changement. Conservez la politique antérieure, le remplacement prévu et les services touchés ensemble. Le vérificateur ne produit pas de politique aplatie approuvée par le fournisseur ni ne teste chaque adresse d'envoi. Il ne peut pas décider qu'un changement de politique est sûr simplement parce que le texte édité analyse et son nombre local est inférieur.
Utiliser les preuves de messages reçus aux côtés du DNS
Inspectez un message de test en utilisant l'analyseur d'en-tête d'email, puis identifiez le champ Authentification-Résultats ajouté par un système de réception auquel vous faites confiance. Le RFC 8601 explique l'importance de cette limite de confiance; une ligne collée peut elle-même être un contenu peu fiable. Comparez l'identité SPF déclarée avec la police que vous avez inspectée. Enregistrez également le domaine de signature DKIM et le sélecteur où il est présent. Le vérificateur d'enregistrement DKIM peut inspecter la clé publique sélectionnée, mais la publication clé ne vérifie pas la signature sur ce message. Une observation DNS et une réponse d'observation de message sont liées, différentes questions.
Vérifier les services modifiés et conserver un dossier
Après un changement de configuration autorisé, tester chaque service d'envoi affecté à travers son workflow normal. Comparer les données probantes des bénéficiaires et les registres des fournisseurs avec les données de base plutôt que de se fier à un message réussi provenant d'un service différent. Sauvez les anciens et les nouveaux dossiers, l'heure du changement et les vérifications effectuées. La configuration du DNS et du fournisseur peut évoluer après votre inspection, de sorte qu'un résultat daté est plus utile qu'un label permanent -SPF est bon. Si une erreur persiste, examinez sa réponse exacte et son identité au lieu de supprimer des termes à plusieurs reprises. L'autorisation SPF seule ne garantit pas le placement de la boîte de réception.