Ein SPF Das Ergebnis „Neutral“ oder „Keine“ authentifiziert den sendenden Host nicht. Beide Ergebnisse können mit einer übermittelten Nachricht koexistieren, daher ist die alleinige Zustellung eine schlechte Diagnose. Die praktische Aufgabe besteht darin, herauszufinden, warum der Prüfer zu diesem Ergebnis gelangt ist und ob es für die tatsächlich verwendete Identität erwartet wird.
Unterscheiden Sie Abwesenheit von einer expliziten Nichtbehauptung
RFC 7208 §2.6.1 definiert „none“ als ein Ergebnis, bei dem keine verwendbare Domänenidentität aus der SMTP Sitzung extrahiert werden kann oder nicht SPF Eintrag wird abgerufen. Unter RFC 7208 §2.6.2„Neutral“ bedeutet, dass die Domain nicht angibt, ob die IP autorisiert ist. Ein Rekord endet in ?all kann Neutralität für eine Quelle erzeugen, die nicht mit einem früheren Mechanismus übereinstimmte. Ein gültiger Datensatz, der sein Ende ohne Übereinstimmung oder Umleitung erreicht, verfügt außerdem über einen impliziten neutralen Standardwert unter RFC 7208 §4.7.
Das ist etwas anderes als pass. Pass autorisiert den verbindenden Host explizit für die ausgewertete Identität. Neutral bedeutet nicht „wahrscheinlich zugelassen“ und keine bedeutet nicht „sicher, da es kein Verbot gibt“. RFC 7208 §8.2 Aus Handhabungsgründen muss „Neutral“ wie „Keine“ behandelt werden. Für die Diagnose der Konfiguration ist es jedoch nützlich, die beiden Beschriftungen getrennt zu halten.
Beginnen Sie mit der beobachteten Identität
Lesen Sie vom Empfänger generierte Authentifizierungsergebnisse von einem System, dem Sie vertrauen. Notieren Sie, ob der Scheck verwendet wurde POST VON oder HELO, die ausgewertete Domain und die verbindende IP. Akzeptieren Sie keine willkürlichen Absenderangaben Authentication-Results Linie als verbindlicher Beweis.
Ein häufiger Untersuchungsfehler besteht darin, die sichtbare Absenderdomäne abzufragen, während die Nachricht eine andere Umschlagdomäne verwendet. Ein gültiger SPF -Eintrag auf example.com sagt nichts über den zurückgegebenen Datensatz aus bounce.example.com. Ein weiterer Fehler besteht darin, nur den Editor eines Registrars abzufragen und nicht die autorisierenden Server, die den Namen tatsächlich bereitstellen.
Wenn Sie kein Ergebnis erhalten, überprüfen Sie den genauen abgefragten Namen und TXT Antwort. Prüfen Sie, ob a v=spf1 Dort ist ein Eintrag vorhanden, ob die Nachricht die beabsichtigte Umschlagidentität verwendet hat und ob die aufgezeichnete Prüfung vor einer kürzlich erfolgten DNS Änderung stattgefunden hat. Eine aktuelle DNS Suche kann den historischen DNS Status nicht selbst wiederherstellen.
Fehlerzustände nicht mit „Keine“ zusammenführen
Unter RFC 7208 §4.5, zwei ausgewählte SPF -Einträge erzeugen permerror, kein harmloser Mangel an Politik. Es kann zu einem vorübergehenden DNS Fehler kommen temperror. Diese Bedingungen erfordern ihre eigenen Untersuchungspfade. Ein Dashboard, das alle nicht bestandenen Ergebnisse unter „fehlender SPF “ gruppiert, kann einen Administrator zur falschen Reparatur verleiten.
Um neutral zu sein, prüfen Sie die Richtlinie der Reihe nach. War ein Fragezeichen als Qualifikationsmerkmal beabsichtigt? Hat eine nicht übereinstimmende Nachricht das Ende eines Datensatzes erreicht, ohne dass ein wirksamer Abschlussmechanismus vorhanden ist? Wenn die Domäne die Richtlinie durch Umleitung delegiert, überprüfen Sie das Ziel und die resultierende Auswertung, anstatt davon auszugehen, dass der Text der obersten Ebene die gesamte Richtlinie darstellt.
Verwenden Sie eine kleine Diagnosematrix
Im Folgenden handelt es sich um synthetische Erwartungen, nicht um Ratschläge zur Produktionskonfiguration:
v=spf1 ip4:192.0.2.10 ?all, ausgewertet für 192.0.2.10 : bestanden.- Der gleiche Datensatz, ausgewertet für 198.51.100.20 : neutral.
v=spf1 ip4:192.0.2.10, ausgewertet für 198.51.100.20 : neutral durch das Standardergebnis.- Kein SPF TXT Eintrag bei einem ansonsten gültigen ausgewerteten Namen: none, vorausgesetzt, die Suche wird ohne einen anderen Fehler abgeschlossen.
Die rein dokumentarischen IP-Adressen unterscheiden die Richtlinienlogik von einem Live-Mandantentest. Wiederholen Sie gleichwertige Tests mit Ihren autorisierten Quellen in einer kontrollierten Umgebung und vergleichen Sie dann die tatsächlichen Beweise des Empfängers.
Reparieren Sie nur die nachgewiesene Ursache
Wenn für die vorgesehene Umschlagdomäne kein Eintrag vorhanden ist, entwerfen Sie eine Richtlinie für die tatsächlichen Absender. Wenn Neutralität beabsichtigt ist, dokumentieren Sie den Grund. Wenn ein Datensatz versehentlich fehlschlägt, entscheiden Sie über die beabsichtigte endgültige Anweisung, nachdem Sie die legitimen Pfade überprüft haben. Ersetzen Sie den Neutralleiter nicht durch einen Universaldurchgang +all: Wenn dies erreicht ist, werden Zuschüsse gewährt, anstatt den Bestand zu reparieren. Frühere Übereinstimmungen oder Fehler können immer noch ergebnisbestimmend sein.
Schließen Sie die Untersuchung mit der ursprünglichen Beobachtung, der identifizierten Ursache, der genehmigten Änderung (falls vorhanden) und einem neuen Nachrichtenergebnis ab. Ein DNS Screenshot ist ein Beweis für die Veröffentlichung; Das Ergebnis einer empfangenen Nachricht ist ein Beweis für eine bestimmte Bewertung. Behalten Sie beides bei, wenn das Geschäft von der Route abhängt.
Nutzen Sie die Beweise für eine Entscheidung
Behalten Sie eine Zeile für Identität/IP/Zeit, genaues Ergebnis, Richtlinien-Snapshot und Ursache bei. Eine abgeschlossene Suche ohne ausgewählten SPF Eintrag ist nicht dasselbe wie eine Zeitüberschreitung oder mehrere ausgewählte Datensätze. Wenn ein Dashboard sie kombiniert, verwenden Sie die zugrunde liegenden Beweise, bevor Sie DNS ändern. Die synthetischen neutralen Fälle demonstrieren den Kontrollfluss, nicht den Authentifizierungserfolg oder die Zustellungssicherheit.