“SPF übergibt das Tool“ und „Der Empfänger meldet SPF Fehler“ sind nicht unbedingt widersprüchlich. Das Tool hat möglicherweise die Syntax validiert, eine andere IP getestet oder ein neueres DNS abgefragt. Der Empfänger hat eine bestimmte SMTP Verbindung ausgewertet. Die Diagnose beginnt mit der Rekonstruktion dieser Verbindung und nicht mit der Annahme, dass eines der Ergebnisse falsch sein muss.
Identifizieren Sie, was das Tool tatsächlich bestanden hat
Speichern Sie die Eingaben und die genaue Ausgabe des Tools. Ein Indikator für die Gültigkeit eines Datensatzes ist nicht unbedingt ein SPF Pass für eine Nachricht. Wenn eine Auswertung durchgeführt wurde, notieren Sie die IP-Adresse, Umschlagabsender, HELO ggf. und Abfragezeit. Halten Sie die Unterscheidung sichtbar, wenn Sie den Vorfall anderen Teams melden.
Erfassen Sie dann das vertrauenswürdige Authentifizierungsergebnis oder SMTP Ablehnungsnachweis des Ziels. Behandeln Sie keine vom Absender bereitgestellte Nachricht Authentication-Results Feld als Urteil des Ziels. RFC 8601 erklärt, warum Ergebnisse eine Vertrauensgrenze benötigen.
Vergleichen Sie Identität und Verbindungsadresse
SPF wertet die Verbindung anhand der relevanten SMTP Identität aus, nicht nur anhand der sichtbaren Absenderadresse. RFC 7208 §2.3 Und RFC 7208 §2.4 Beschreiben Sie HELO und MAIL FROM-Prüfungen. Vergleichen Sie die vom Empfänger beobachtete IP und die ausgewertete Domäne mit der Tool-Vorrichtung.
Ein anschaulicher Fall: Eine Anwendung zeigt From billing@example.com an, verwendet aber eine Umschlagidentität unter der Domäne eines Anbieters. Ein Tooltest von example.com kann für die tatsächliche SPF Entscheidung des Empfängers irrelevant sein. In einem anderen Fall verlässt die Anwendung ein anderes Relay als vom Administrator erwartet. Korrigieren Sie das Verständnis der Route, bevor Sie die Autorisierung verlängern.
Wie beschrieben in RFC 7208 §10.3Wenn ein Weiterleiter beteiligt ist, kann der endgültige Empfänger die Verbindung des Weiterleiters sehen und nicht die ursprüngliche sendende IP. Fügen Sie nicht jeden beobachteten Forwarder als pauschale Reparatur zum SPF der Ursprungsdomäne hinzu. Bewerten Sie stattdessen den gesamten indirekten E-Mail-Fluss und andere Authentifizierungsergebnisse.
Vergleichen Sie DNS zu den relevanten Zeiten
Rufen Sie den aktuell anwendbaren Datensatz und die Abhängigkeiten ab. Behalten Sie die Ereigniszeit des Empfängers und alle gleichzeitigen DNS Beweise bei. Ein nach einer Reparatur durchgeführter Test kann nicht beweisen, was der Empfänger zuvor gesehen hat. Ebenso kann sich eine Anbieterabhängigkeit ändern, ohne dass ein lokaler Datensatz bearbeitet werden muss.
Überprüfen Sie die maßgebliche Veröffentlichung, rekursive Antworten und Fehlerbedingungen. Unterscheiden Sie eine alte zwischengespeicherte Richtlinie von einer fehlenden Richtlinie oder einem vorübergehenden DNS Fehler. RFC 7208 Abschnitt 2.6 definiert verschiedene Ergebniskategorien; nicht zusammenbrechen, scheitern, softfail , temperror Und permerror in einer Diagnose zusammengefasst.
Wiederholen Sie den tatsächlichen Pfad
Verwenden Sie einen standardbewussten Evaluator mit den beobachteten Eingaben. Überprüfen Sie den übereinstimmenden Mechanismus, die Qualifizierer, die rekursiven Abhängigkeiten und alle Grenzwerte oder DNS Fehler. Wenn historisches DNS nicht verfügbar ist, kennzeichnen Sie die Wiedergabe als Test des aktuellen Status und nicht als Rekonstruktion des früheren Ereignisses.
Testen Sie beide Adressfamilien, wenn der Absender beide verwenden kann. Vergleichen Sie mehrere betroffene und nicht betroffene Stichproben, um zu sehen, ob der Fehler einer Route, einer Region, einer IP-Familie oder einem Zeitintervall folgt. Hierbei handelt es sich um eine empfohlene Diagnosemethode und nicht um den Anspruch, dass ein bestimmter Anbieter den Datenverkehr auf eine bestimmte Weise verteilt.
Führen Sie die schmalste unterstützte Reparatur durch
Beheben Sie das bestätigte Problem: falsche Umschlagkonfiguration, fehlender autorisierter Bereich, fehlerhafte Richtlinie, fehlerhafte Abhängigkeit oder Routing-Inkonsistenz. Behalten Sie den ursprünglichen Zustand bei und holen Sie die normale Änderungsgenehmigung ein. Erweitern Sie die Richtlinie nicht, nur um einen unerklärlichen Probendurchlauf durchzuführen.
Senden Sie nach der Reparatur die gleiche Anwendungsroute und überprüfen Sie das Ergebnis eines neuen vertrauenswürdigen Empfängers. Überprüfen DMARC separat, da ein roher SPF Durchlauf möglicherweise nicht ausgerichtet und ausgerichtet ist DKIM pass kann DMARC auch dann unterstützen, wenn SPF fehlschlägt. Der Leitfaden zur Ausrichtungsdiagnose deckt diese Unterscheidung ab. Schließen Sie den Vorfall mit dem Unterschied zwischen den alten und neuen Beweisen ab, nicht nur mit einem weiteren grünen Checker-Screenshot.
DNS -Hintergrund: RFC 1035 Abschnitt 3.2.1 definiert die TTL für Ressourcendatensätze; RFC 2308 §5 behandelt das Zwischenspeichern negativer Antworten. RFC 8767 §4 Aktualisiert die TTL-Semantik, um eine veraltete Verwendung zu ermöglichen, wenn die autorisierende Aktualisierung fehlschlägt. Diese beschreiben ausnahmsweise DNS Verhalten und keine universelle Abschlusszeit.
Verwenden Sie einen konkreten Entscheidungsdatensatz
Hypothetischer Vergleich: Ein Prüfer bewertet IP A heute mit example.com ; Der gestrige Empfänger hat IP B gegen bounce.service.example.net ausgewertet. Das sind verschiedene Eingabesätze. Notieren Sie beide IP-/Domänen-/Zeit-Triples und die jeweils verfügbaren DNS Beweise. Wenn historisches DNS fehlt, geben Sie an, dass das ursprüngliche Ergebnis nicht vollständig wiedergegeben werden kann. Beurteilen Sie keines der beiden Werkzeuge allein aufgrund dieser Beobachtungen als fehlerhaft. Hier wurde kein Replay oder DNS Test durchgeführt.