Un SPF un incident qui semble limité à un seul réseau destinataire constitue un problème de comparaison. Déterminez d’abord si ce réseau a évalué la même adresse IP d’envoi, le même domaine d’enveloppe et la même politique DNS que vos contrôles réussis. Un changement d'autorisation général peut masquer la différence tout en augmentant le nombre de personnes autorisées à envoyer via votre domaine.
Construire une comparaison correspondante
Sélectionnez une transaction échouée et une transaction réussie à partir de la même application et de l'heure approximative. Enregistrez l'heure UTC, en connectant l'adresse IPv4 ou IPv6 , SMTP COURRIER DE, HELO nom, réseau du destinataire, réponse SMTP exacte et résultat de l'authentification fiable si le message a été accepté. Un message rejeté lors de SMTP peut ne jamais avoir d'en-tête livré à inspecter. Conservez plutôt le journal des transactions de l’expéditeur. Traitez les identifiants et le contenu des messages comme des preuves opérationnelles restreintes.
SPF évalue normalement le domaine MAIL FROM ; pour un chemin inverse nul, son identité MAIL FROM est construite à l'aide de postmaster et du domaine HELO . L’adresse De visible n’est pas l’instruction de recherche. Un service de transfert peut également modifier l'adresse IP de connexion vue par le destinataire final. RFC 7208 , sections 2.3 à 2.4 et 10.3.
Séparer les classes d'échec
Un échec explicite pointe vers un chemin évalué qui n’a pas autorisé le client. Permerror appelle à une inspection de la syntaxe des politiques, plusieurs Enregistrements SPF, dépendances récursives et limites d'évaluation. Tempérament appelle à une enquête sur des problèmes temporaires de recherche ou de traitement. Aucun signifie qu'aucun domaine évalué utilisable ou qu'aucun enregistrement SPF applicable n'a été trouvé, plutôt qu'une interdiction explicite. Neutre signifie que la politique ne fait aucune affirmation d’autorisation définitive ; softfail exprime une assertion négative plus faible que fail. Un pass SPF non plus. Capturez le résultat avant d’interpréter un ticket générique « problème d’authentification ».
Comparez les réponses DNS faisant autorité avec les réponses récursives et leurs horodatages. Recherchez le nom exact du propriétaire et chaque dépendance atteinte pour cette adresse IP. Les couvertures de limites à dix termes du SPF évaluées comprennent les mécanismes a, mx, ptr et exist et les modificateur de redirection, y compris l'évaluation imbriquée, plutôt que chaque paquet DNS ou fragment TXT . L'ip4, l'ip6 et tous les mécanismes ne consomment pas ce budget à terme ; des limites distinctes peuvent toujours s'appliquer à d'autres travaux DNS . Une analyse statique d'un outil et le chemin réel d'un récepteur peuvent donc être en désaccord. RFC 7208 , sections 4.5 à 4.6.4 et 8.
Travailler sur un exemple contrôlé
Scénario illustratif : l'expéditeur atteint le réseau A via une adresse IPv4 autorisée mais atteint le réseau B via une adresse IPv6 non répertoriée. Le nom et l'adresse de l'application sont identiques. L'intervention utile consiste à vérifier la propriété et l'utilisation prévue de la route IPv6 , puis à l'autoriser de manière stricte, le cas échéant, ou à cesser de l'utiliser. L'ajout du réseau destinataire à SPF résoudrait le mauvais côté de la connexion.
Une deuxième possibilité est le transfert : le réseau B reçoit d'un intermédiaire plutôt que de votre hôte sortant d'origine. N'ajoutez pas de redirecteurs arbitraires à votre stratégie. Vérifiez le chemin de transfert, survivant aligné DKIM et la politique du séquestre. Un résultat SPF satisfaisant peut toujours être non aligné pendant DMARC. RFC 9989 , section 4.4.
Clôturer avec des preuves reproductibles
Effectuez une modification contrôlée avec un propriétaire, une valeur antérieure enregistrée et une condition de restauration. Répétez les tests de correspondance sur l'itinéraire concerné, en incluant les deux familles d'adresses utilisées. Confirmez séparément SPF , l'authentification alignée et la gestion SMTP . Si les mêmes entrées et politiques donnent toujours des résultats différents, préparez un paquet de preuves expurgé pour l’opérateur destinataire. Enregistrez la différence d'implémentation non résolue au lieu de qualifier l'ensemble du réseau de cassé.
Utilisez une feuille de calcul de preuves correspondantes
- Paire échec/contrôle : enregistrez les heures UTC, l'application et le réseau destinataire pour les deux.
- Connexion : comparez la source IPv4 ou IPv6 réelle et tout saut de transfert.
- Identité : comparez MAIL FROM, HELO et le domaine réellement vérifié par le destinataire.
- Politique : conserver les réponses TXT datées et le chemin de dépendance évalué.
- Résultat : conserver fail, softfail , neutral, none, temperror ou permerror exactement, plus la réponse SMTP .
- Action : réparer uniquement une différence vérifiée ; répétez le même itinéraire et conservez les différences non résolues pour les escalader.