Ein SPF pass antwortet, ob eine sendende IP für die ausgewertete SPF Identität autorisiert wurde. DMARC stellt eine zusätzliche Frage: Stimmt diese authentifizierte Identität mit der Domäne in From überein? Ein Gesamtbericht kann daher einen reinen SPF Bestand und einen SPF-bezogenen DMARC Fehler anzeigen, ohne sich selbst zu widersprechen.
Identifizieren Sie die SPF authentifizierte Domäne
Referenzen: RFC 9990 §3.1.1.13, RFC 7208 §2.4, RFC 9989 §4.4.2.
Lesen Sie auth_results/spf/domain und das Ergebnis zusammen. Untersuchen Sie Identifier/Header_From, alle Envelope_From und den gemeldeten Bereich. Gehen Sie nicht davon aus, dass SPF die sichtbare Von-Domäne überprüft hat. RFC 7208 definiert die POST VON Identität, während RFC 9989 verwendet diese Identität für den Beitrag von SPF zum DMARC .
Für einen Null-Reverse-Path definiert SPF eine MAIL FROM-Identität unter Verwendung von postmaster am HELO Domain. Dieser Sonderfall sollte nicht zur Regel werden, dass jeder unabhängige HELO Durchgang DMARC erfüllt. Aktuell RFC 9990 Berichterstattung erlaubt mfrom als SPF Geltungsbereich; Ältere Berichtsformate können unterschiedliche Felder offenlegen und erfordern eine explizite Interpretation.
Wenden Sie den richtigen Ausrichtungsmodus an
Referenzen: RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
Strenger SPF Ausrichtung erfordert, dass die authentifizierte Domäne genau mit der Autorendomäne übereinstimmt. Die entspannte Ausrichtung ermöglicht die Beziehung, die durch die geltenden Organisationsdomänenregeln definiert ist. Berechnen Sie es nicht einfach durch Entfernen einer festen Anzahl von Labels: Öffentliche Suffix- und Policy-Discovery-Details sind wichtig.
Der SPF Wert unter row/policy_evaluated drückt das DMARC-bezogene Ergebnis aus, kein Duplikat des rohen SPF Ergebnisses. Ein einfacher Fehler oder Fehler kann nicht zu einem erfolgreichen SPF Pfad werden, nur weil die Domänennamen einander ähneln. Die Authentifizierung muss erfolgreich sein und übereinstimmen.
Arbeiten Sie durch zwei kontrastierende Reihen
Referenzen: RFC 9989 §5.3.5.
Gehen Sie von anwendbaren gültigen Richtlinien, abgeschlossenen Prüfungen und unabhängigen Organisationsdomänen für brand.example und vendor.example aus. Die synthetische Zeile A verwendet header_from= brand.example , MAIL FROM= vendor.example und raw SPF =pass. Die unabhängige Identität stimmt nicht überein, daher wird „policy_evaluated/ spf=fail erwartet. Das Hinzufügen einer Anbieter-IP zum SPF von brand.example ändert nichts an der Identität, die diese Route tatsächlich auswertet.
Die synthetische Zeile B verwendet header_from= brand.example und MAIL FROM= bounce.brand.example mit rohem SPF =pass. Gehen Sie davon aus, dass die entsprechende Organisationsdomänenerkennung sie zusammenfügt. Eine lockere SPF Ausrichtung kann erfolgreich sein, während eine strikte SPF Ausrichtung fehlschlägt, weil die Namen unterschiedlich sind. Hierbei handelt es sich um beispielhafte Feldbefestigungen, nicht um beobachteten Verkehr.
Überprüfen Sie die Ausrichtung beider Reihen DKIM bevor ich zu dem Schluss kam, dass DMARC insgesamt gescheitert sei. Ein Pass ausgerichtet DKIM Signatur kann den erfolgreichen DMARC Pfad unabhängig von SPF bereitstellen.
Wählen Sie eine Reparatur, die die fehlerhafte Ebene ändert
Referenzen: RFC 7208 §10.3.
Wenn Raw- SPF fehlschlägt, untersuchen Sie die Autorisierung und den Verbindungspfad für die tatsächlich ausgewertete Domäne. Wenn Roh- SPF erfolgreich ist, aber nicht ausgerichtet ist, prüfen Sie eine unterstützte benutzerdefinierte MAIL FROM-Konfiguration oder einen anderen ausgerichteten Authentifizierungspfad. Fügen Sie nicht ständig IPs zu einer nicht verwandten Domäne hinzu SPF Eintrag.
Bestätigen Sie Änderungen anhand kontrollierter empfangener E-Mails und späterer Berichtsnachweise, wobei sowohl rohe als auch abgeglichene Ergebnisse erhalten bleiben. Durch die Weiterleitung kann sich die Verbindungs-IP ändern. Testen Sie daher relevante Routen und vermeiden Sie es, SPF allein als Garantie für die Zustellung zu betrachten. Schließen Sie die Untersuchung mit der bewerteten Identität, dem Ausrichtungsmodus und dem nachgewiesenen Ergebnis ab.
Behalten Sie die Roh-zu-Alignment-Testfälle bei
Vier teilweise synthetische Karten teilen sich die Richtlinie header_from= brand.example p=reject und Epochenintervall 1704067200–1704153600. A verwendet MAIL FROM= vendor.example mit reinem SPF -Pass und ohne DKIM Signaturen: ausgerichtetes SPF und DMARC schlagen fehl. B verwendet MAIL FROM= bounce.brand.example mit reinem SPF Pass und ohne DKIM : Unter einer explizit angenommenen gemeinsamen Organisationsdomäne übergibt der entspannte Modus SPF -Ausrichtung und DMARC . Die gleiche B-Eingabe im strikten Modus schlägt bei beiden fehl. Ein vierter Fall stellt die unabhängige SPF Identität von A wieder her, fügt jedoch die Weitergabe DKIM für brand.example /selector billing1: DMARC durch DKIM hinzu.
Die bereitgestellte lokale Identitätsübung reproduziert alle vier Ergebnisse der bereitgestellten Identitäten, Ergebnisse und Ausrichtungsmodi. Es verwendet eine explizite Organisationsdomänenzuordnung, keine DNS Tree-Walk-Implementierung. Außerdem wird keine echte Null-Reverse-Path-Nachricht getestet. Die obige Nullpfad-Anleitung basiert auf der Spezifikation. Für das tatsächliche Verhalten von Anbieter und Empfänger sind weiterhin Belege für empfangene Nachrichten erforderlich.
Halten Sie die Übung im Rahmen
Bei den Beispielen handelt es sich um Teilfeldprojektionen, nicht um schemagültige Berichte oder gemessenen Datenverkehr. Lokale Prüfungen nutzen explizit bereitgestellte Authentifizierungsergebnisse und Organisationsbeziehungen; Sie führen keine DNS Erkennung, SPF -Bewertung, kryptografische Überprüfung, Berichtsaufnahme oder Empfängerzustellungstests durch. Bewahren Sie den Originalbericht und vertrauenswürdige Nachrichtenbeweise auf, bevor Sie eine Produktionsänderung vornehmen.