Der All-Mechanismus stimmt immer überein. Sein Qualifikationsmerkmal bestimmt daher was SPF sagt über eine Verbindungsadresse, die es erreicht. Die bekannten Endungen -all , ~all , ?all und +all sind vier verschiedene Authentifizierungsanweisungen, nicht vier garantierte Zustellungsaktionen.
Möglicherweise hat ein früherer Mechanismus bereits ein Ergebnis zurückgegeben. Lesen Sie den gesamten Bewertungspfad, bevor Sie das letzte Wort des Datensatzes interpretieren. RFC 7208 §2.6 Und RFC 7208 §5.1 Definieren Sie diese Semantik.
Vergleichen Sie die vier Enden
Mit -all schlägt ein Absender, der alle Empfänger erreicht, fehl. Die Richtlinie besagt, dass die Adresse für die ausgewertete Identität nicht autorisiert ist. Mit ~all erhält es softfail , eine schwächere negative Aussage anstelle eines Pass. Mit ?all wird neutral empfangen, was bedeutet, dass die Richtlinie keine Autorisierungsaussage für diese Adresse macht. Mit +all erhält es pass.
Unter RFC 7208 §4.6.2, ein unqualifiziertes „All“ hat das Standardqualifikationsmerkmal „+“ und ist daher ebenfalls erfolgreich. Das macht ein „Bare All“ zu einer folgenreichen Erlaubnisentscheidung und nicht zu einem harmlosen Terminator. Sobald alle Übereinstimmungen vorliegen, können spätere Mechanismen keine zusätzlichen Berechtigungen mehr bereitstellen.
Ausgearbeitetes Beispiel: Behalten Sie den autorisierten Absender konstant
Verwenden Sie die synthetische Richtlinie v=spf1 ip4:192.0.2.90 QUALIFIERall. Bei einer Verbindung von 192.0.2.90 stimmt ip4 zuerst überein und gibt pass unter jeder Endung zurück. Für 192.0.2.91 stimmt der erste Mechanismus nicht überein. Das gewählte Ende gibt dann „fail“, softfail , „neutral“ oder „pass“ zurück.
Durch die Änderung von ~all in -all wird das Ergebnis für die erste Adresse in diesem Fixture nicht geändert. Es ändert die Behandlung von Adressen, die noch nicht abgeglichen wurden. Deshalb ist die richtige Bereitschaftsfrage, ob alle legitimen Sendepfade identifiziert wurden, und nicht, ob ein gemeinsamer Absender einen Test bestanden hat.
Eine Richtlinie bestehend aus v=spf1 -all Autorisiert keine Adressen über SPF . Es kann eine nicht sendende Identität ausdrücken, es handelt sich jedoch nicht um eine universelle Anweisung, dass jeder Empfänger jede Nachricht verwerfen muss, die diese Domäne in From anzeigt.
Halten Sie Ergebnis und Handhabung getrennt
SPF gibt ein Authentifizierungsergebnis zurück. Der Empfänger entscheidet anhand lokaler Richtlinien und anderer unten aufgeführter Beweise, was mit der Nachricht geschehen soll RFC 7208 §8.4 Und RFC 7208 §8.5. Ein Fail ist kein Beweis dafür, dass jeder Empfänger die Nachricht abgelehnt hat, und softfail ist kein Versprechen, dass die Nachricht mit einer Warnung zugestellt wird.
SPF softfail und Neutral werden nicht zu übergebenden SPF Pfaden DMARC. Unter RFC 9989 §4.4.2, DMARC erfordert einen Pass mit Ausrichtung für seinen SPF Pfad oder eine separate Weitergabe ausgerichtet DKIM Weg. Eine Nachricht kann daher trotz SPF Fehlers DMARC über DKIM passieren. Umgekehrt kann +all SPF -Pass für eine Adresse erzeugen, ohne deren Inhalt vertrauenswürdig zu machen.
Verwenden Sie +all nicht, um ein Fehler-Dashboard stummzuschalten. Es autorisiert jede Adresse, die es erreicht, für diese Identität und hebt die beabsichtigte Einschränkung auf. Reparieren Sie stattdessen fehlende Absender, falsche Identitäten oder defekte Abhängigkeiten.
Unterscheiden Sie Richtlinienabschlüsse von Bewertungsfehlern
Permerror Und temperror sind keine anderen Schreibweisen für scheitern. Mehrere SPF Einträge, ungültige Syntax oder überschrittene Verarbeitungsgrenzen können eine normale Auswertung verhindern. Temporäre DNS Probleme können zu temperror führen. Das Ersetzen -all durch ~all behebt keinen Fehler, der vor Erreichen des Endes auftritt.
Erfassen Sie das tatsächliche Ergebnis und verfolgen Sie es, bevor Sie eine Änderung vornehmen. Untersuchen Sie bei einem DNS Ausfall die Abhängigkeit und den Resolverpfad. Stellen Sie bei einem nicht erkannten legitimen Absender den Eigentümer und die erwartete Umschlagidentität fest, bevor Sie ihm die Erlaubnis erteilen.
Führen Sie eine strengere Aussage mit Beweisen aus
Inventarisieren Sie regelmäßige, Failover-, IPv6 und seltene Senderouten. Testen Sie die vorgeschlagene Richtlinie anhand dieser Adressen und einer nicht autorisierten Kontrolle. Behalten Sie den vorherigen Datensatz, definieren Sie servicebasierte Rollback-Bedingungen und überprüfen Sie empfangene E-Mails nach der Veröffentlichung.
Wenn die Weiterleitung Teil der legitimen Zustellung ist, überprüfen Sie das umfassendere Authentifizierungsdesign, einschließlich abgestimmter DKIM und Empfängerverhalten. Erlauben Sie unbekannten Weiterleitungen nicht generell, jeden indirekten SPF Pfad passieren zu lassen.
Der praktische Imbiss
Wählen Sie das Qualifikationsmerkmal für die Aussage aus, die Sie über ansonsten nicht übereinstimmende Absender abgeben möchten. Überprüfen Sie zunächst den Bestand und die Fehlerpfade und messen Sie dann Authentifizierung und Zustellung als separate Ergebnisse.
Notieren Sie die nächste Entscheidung
Für 192.0.2.91 im synthetischen Spiel ergeben die vier Enden jeweils Fail/ softfail /Neutral/Pass; 192.0.2.90 bleibt durch das frühere IP4-Match bestehen. Wenn vor einem normalen Ergebnis ein Syntax- oder Abhängigkeitsfehler auftritt, ist die Änderung des Endqualifizierers keine Reparatur. Hierbei handelt es sich um analytische Kontrollflussergebnisse, nicht um Liefertests.