SPF beantwortet eine enge Frage: Ist der Verbindungsserver berechtigt, die in einer bestimmten SMTP Identität dargestellte Domäne zu verwenden? Es beginnt nicht mit dem Absendernamen, der in einem Posteingang angezeigt wird. Diese Unterscheidung erklärt, warum die Änderung des falschen DNS Eintrags dazu führen kann, dass ein Authentifizierungsproblem unberührt bleibt.
Für einen normalen, nicht leeren Reverse-Pfad ist die relevante Identität die Domäne in SMTP POST VON. Bei der Adresse kann es sich um eine vom Anbieter verwaltete Bounce-Adresse und nicht um den sichtbaren Autor handeln. Ein separates HELO Es kann auch eine Überprüfung erfolgen. Wenn MAIL FROM leer ist, erstellt SPF seine MAIL FROM-Identität mithilfe der HELO Domäne und des lokalen Teils Postmaster. Diese Identitätsregeln sind in definiert RFC 7208 §2.3 Und RFC 7208 §2.4.
Folgen Sie dem Umschlag durch eine Lieferung
Stellen Sie sich eine Anwendung vor, die eine Rechnung sendet. Die SMTP Verbindung stammt von 192.0.2.44 , ihr MAIL FROM lautet receipts@bounce.example.com “ und im Nachrichtenheader steht „From: billing@example.com “. Hierbei handelt es sich um synthetische Werte, die der Dokumentation vorbehalten sind, nicht um ein Bereitstellungsrezept.
Der Empfänger wertet die verbindende IP anhand der SPF -Richtlinie unter bounce.example.com aus. SPF Richtlinie von example.com wird nicht ausgewählt, nur weil diese Domäne in „Von“ erscheint. Eine Richtlinie beim Elternteil autorisiert sein Kind nicht automatisch.
Angenommen, bounce.example.com veröffentlicht v=spf1 ip4:192.0.2.44 -all. Der IP4-Mechanismus stimmt überein und das Ergebnis ist bestanden. Wenn die Verbindungsadresse 192.0.2.45 wäre, würde sie nicht übereinstimmen; Die Auswertung würde -all erreichen und fehlschlagen. Keines der Ergebnisse sagt aus, ob die Rechnung echt ist oder ob das Konto, von dem sie gesendet wurde, kompromittiert wurde.
Identifizieren Sie Beweise, denen Sie vertrauen können
Bitten Sie um die ursprünglich empfangene Nachricht und nicht um einen Screenshot des Anzeigenamens. Notieren Sie den Empfänger, die Empfangszeit, die Verbindungs-IP, die ausgewertete SMTP Identität und SPF Ergebnis. Unter RFC 8601 §7.1, sind die vertrauenswürdigen Authentifizierungsergebnisse oder Protokolle des Empfängers ein stärkerer Beweis als ein Header, der von einem beliebigen Absender bereitgestellt wird.
Unter RFC 5321 §4.4, ein geliefert Return-Path kann dabei helfen, den Absender des Umschlags zu ermitteln, es handelt sich jedoch eher um eine Zustellungsspur als um einen Befehl, den Sie sicher bearbeiten können, um SPF zu ändern. Gateways, erneute Übermittlung und Weiterleitung können zu einer weiteren SMTP Transaktion führen. Diagnostizieren Sie die Transaktion, bei der der fehlerhafte Empfänger seine Prüfung durchgeführt hat.
Führen Sie ein kurzes Identitätsarbeitsblatt: sichtbar Von der Domäne; MAIL FROM-Domäne; HELO -Name; IP verbinden; SPF Eintrag damals beobachtet; Ergebnis; und alle ausgerichtet DKIM Ergebnis. Es geht darum, zu verhindern ein Rekord Editor vom ersten Diagnoseschritt ab.
Behandeln Sie Bounces und Weiterleitungen getrennt
Bei bestimmten Lieferbenachrichtigungen ist ein leerer Rückwärtspfad normal. Behandeln Sie es nicht als fehlenden Beweis und ersetzen Sie es durch die sichtbare From-Domäne. Erfassen Sie HELO und wenden Sie stattdessen die Nullpfadregel an.
Die Weiterleitung bringt ein anderes Problem mit sich. Der nächste Empfänger sieht die Verbindungs-IP des Weiterleiters, die möglicherweise nicht von der ursprünglichen Umschlagdomäne autorisiert ist. Durch das Umschreiben des Umschlags kann sich die überprüfte Identität ändern. Ein Pass für die umgeschriebene Identität wird nicht automatisch mit dem sichtbaren Autor abgeglichen. Untersuchen Sie die gesamte Route und alle verbleibenden Ausrichtungen DKIM Signatur anstatt jeden Spediteur zu Ihrer Police hinzuzufügen.
Verbinden Sie SPF mit der Geschäftsentscheidung
DMARC fügt einen Identitätsvergleich hinzu: Ein übergebenes SPF Ergebnis muss mit der Autorendomäne übereinstimmen, um deren SPF Pfad zu erfüllen. Ein separater, ausgerichteter DKIM Durchgang kann DMARC erfüllen, selbst wenn SPF nicht tut. RFC 9989 beschreibt diese Beziehung.
Bewerten Sie das Rechnungsbeispiel Ausrichtung gemäß den geltenden Modus- und Organisationsdomänenerkennungsregeln; Gehen Sie nicht davon aus, dass ein gemeinsames Textsuffix die Ausrichtung in jedem Namespace beweist. Eine strikte SPF Anpassung erfordert eine genaue Domänengleichheit RFC 9989 §3.2.10.2; Die entspannte Erkennung von Organisationsdomänen ist in angegeben RFC 9989 §4.10.2.
Bevor Sie eine Änderung genehmigen, fragen Sie den Dienstinhaber, welche Umschlagidentität das Produkt unterstützt und wer sein DNS kontrolliert. Behalten Sie den vorherigen Datensatz bei, nehmen Sie die kleinste autorisierte Änderung vor und senden Sie eine neue repräsentative Rechnung über den betroffenen Weg. Schließen Sie das Problem erst, wenn die beobachtete Identität, das Ergebnis und die erforderliche Ausrichtung dem beabsichtigten Ergebnis entsprechen.
Der praktische Imbiss
Beginnen Sie mit dem SMTP -Umschlag und der Verbindungs-IP. Das Bearbeiten einer Domain, die SPF nie ausgewertet hat, ist keine Reparatur, selbst wenn ein Tool zur Datensatzprüfung grün wird.
Halten Sie die Entscheidung reproduzierbar
Behalten Sie für die Rechnungsfixierung die Verbindungs-IP 192.0.2.44 , die MAIL FROM-Domäne bounce.example.com und die sichtbare Autorendomäne example.com als separate Felder bei. Eine übergeordnete TXT -Bearbeitung ist kein Beweis für einen reparierten untergeordneten Scheck. Erfassen Sie für eine weitergeleitete Kopie eine neue Transaktionszeile, anstatt die ursprüngliche IP weiterzuleiten. Hierbei handelt es sich um hypothetische Eingaben, nicht um ausgeführte SPF oder Lieferbeobachtungen.