Ein SPF Ein Vorfall, der auf ein Empfängernetzwerk beschränkt zu sein scheint, stellt ein Vergleichsproblem dar. Stellen Sie zunächst fest, ob dieses Netzwerk dieselbe Sende-IP, dieselbe Umschlagdomäne und DNS Richtlinie ausgewertet hat wie Ihre erfolgreichen Kontrollen. Eine umfassende Autorisierungsänderung kann den Unterschied verbergen und gleichzeitig die Anzahl der Personen erhöhen, die über Ihre Domain senden dürfen.
Erstellen Sie einen passenden Vergleich
Wählen Sie eine fehlgeschlagene Transaktion und eine erfolgreiche Transaktion aus derselben Anwendung und der ungefähren Zeit aus. Notieren Sie die UTC-Zeit, verbinden Sie IPv4 oder IPv6 -Adresse und SMTP POST VON, HELO Name, Empfängernetzwerk, genaue SMTP Antwort und vertrauenswürdiges Authentifizierungsergebnis, wenn die Nachricht akzeptiert wurde. Eine während SMTP abgelehnte Nachricht verfügt möglicherweise nie über einen zugestellten Header, der überprüft werden muss. Bewahren Sie stattdessen das Transaktionsprotokoll des Absenders auf. Behandeln Sie Identifikatoren und Nachrichteninhalte als eingeschränkte betriebliche Beweise.
SPF wertet normalerweise die MAIL FROM-Domäne aus; Für einen Null-Reverse-Pfad wird seine MAIL FROM-Identität mithilfe von Postmaster und der HELO Domäne erstellt. Die sichtbare Absenderadresse ist nicht die Suchanweisung. Ein Weiterleitungsdienst kann auch die Verbindungs-IP ändern, die der Endempfänger sieht. RFC 7208 , Abschnitte 2.3–2.4 und 10.3.
Trennen Sie die Fehlerklassen
Ein expliziter Fehler weist auf einen ausgewerteten Pfad hin, der den Client nicht autorisiert hat. Permerror fordert eine Überprüfung der Richtliniensyntax, mehrfach SPF Einträge, rekursive Abhängigkeiten und Auswertungsgrenzen. Temperaturfehler fordert die Untersuchung vorübergehender Such- oder Verarbeitungsprobleme. Keine bedeutet, dass keine nutzbare ausgewertete Domain oder kein anwendbarer SPF Eintrag gefunden wurde, und kein explizites Verbot. Neutral bedeutet, dass die Richtlinie keine eindeutige Autorisierungserklärung abgibt; softfail drückt eine schwächere negative Aussage aus als Fail. Es handelt sich auch nicht um einen SPF Pass. Erfassen Sie das Ergebnis, bevor Sie ein generisches „Authentifizierungsproblem“-Ticket interpretieren.
Vergleichen Sie autorisierende DNS Antworten mit rekursiven Antworten und ihren Zeitstempeln. Fragen Sie den genauen Besitzernamen und jede für diese IP erreichte Abhängigkeit ab. Zu den bewerteten Zehn-Term-Limit-Deckungen von SPF gehören A, MX, PTR und Exist-Mechanismen sowie die Umleitungsmodifikator, einschließlich verschachtelter Auswertung, und nicht jedes DNS Paket oder TXT Fragment. IP4, IP6 und alle Mechanismen verbrauchen dieses Laufzeitbudget nicht; Für andere DNS -Arbeiten können weiterhin gesonderte Grenzwerte gelten. Ein statischer Werkzeugscan und der tatsächliche Pfad eines Empfängers können daher nicht übereinstimmen. RFC 7208 , Abschnitte 4.5–4.6.4 und 8.
Arbeiten Sie ein kontrolliertes Beispiel durch
Beispielszenario: Der Absender erreicht Netzwerk A über eine autorisierte IPv4 -Adresse, erreicht Netzwerk B jedoch über eine nicht aufgeführte IPv6 -Adresse. Der Name und die Absenderadresse der Anwendung sehen identisch aus. Der sinnvolle Eingriff besteht darin, den Besitz und die beabsichtigte Nutzung der IPv6 -Route zu überprüfen und sie dann gegebenenfalls eingeschränkt zu autorisieren oder die Nutzung einzustellen. Das Hinzufügen des Empfängernetzwerks zu SPF würde die falsche Seite der Verbindung ansprechen.
Eine zweite Möglichkeit ist die Weiterleitung: Netzwerk B empfängt Daten von einem Vermittler und nicht von Ihrem ursprünglichen ausgehenden Host. Fügen Sie Ihrer Richtlinie keine willkürlichen Weiterleitungen hinzu. Überprüfen Sie den Weiterleitungspfad und achten Sie darauf, dass er ausgerichtet ist DKIM und die Richtlinien des Empfängers. Ein bestandenes SPF -Ergebnis kann immer noch nicht abgeglichen werden DMARC. RFC 9989 , Abschnitt 4.4.
Schließen Sie mit reproduzierbaren Beweisen ab
Führen Sie eine kontrollierte Änderung mit einem Eigentümer, einem gespeicherten vorherigen Wert und einer Rollback-Bedingung durch. Wiederholen Sie die übereinstimmenden Tests über die betroffene Route, einschließlich beider Adressfamilien, sofern verwendet. Bestätigen Sie SPF , angepasste Authentifizierung und SMTP -Verarbeitung separat. Wenn die gleichen Eingaben und Richtlinien immer noch zu unterschiedlichen Ergebnissen führen, bereiten Sie ein geschwärztes Beweispaket für den empfangenden Betreiber vor. Notieren Sie den ungelösten Implementierungsunterschied, anstatt das gesamte Netzwerk als defekt zu bezeichnen.
Verwenden Sie ein Arbeitsblatt mit übereinstimmenden Beweisen
- Fehler/Kontrollpaar: UTC-Zeiten, Anwendung und Empfängernetzwerk für beide aufzeichnen.
- Verbindung: Vergleichen Sie die tatsächliche IPv4 oder IPv6 -Quelle und jeden Weiterleitungs-Hop.
- Identität: Vergleichen Sie MAIL FROM, HELO und die Domäne, die der Empfänger tatsächlich überprüft hat.
- Richtlinie: Behalten Sie datierte TXT Antworten und den ausgewerteten Abhängigkeitspfad bei.
- Ergebnis: Fail, softfail , Neutral, None, temperror oder permerror genau beibehalten, plus die SMTP Antwort.
- Aktion: Reparieren Sie nur einen überprüften Unterschied. Wiederholen Sie den gleichen Weg und behalten Sie ungelöste Differenzen zur Eskalation bei.