Zwei SPF Richtlinien mit demselben DNS Namen werden nicht zu einer größeren Liste autorisierter Absender zusammengefasst. Wann SPF Eintrag Die Auswahl gibt mehr als einen anwendbaren Datensatz zurück, die Auswertung endet mit permerror unter RFC 7208 §4.5. Bei der Reparatur handelt es sich um eine zusammenhängende Richtlinie, nicht um einen dritten TXT Eintrag.
Der schwierige Teil besteht darin, zu entscheiden, welche Berechtigungen noch gehören. Durch das Kopieren aller Mechanismen in eine einzige Zeile kann der Syntaxfehler behoben werden, während veraltete Anbieter, übermäßige Netzwerke und ein Problem mit der Suchbeschränkung erhalten bleiben.
Bestätigen Sie, was tatsächlich dupliziert wird
Abfrage TXT Datensätze in der genauen Domäne, die für die SPF Prüfung verwendet wird. Andere TXT Einträge, wie z. B. Domänenverifizierungstoken, sind nicht automatisch SPF Einträge und sollten im Rahmen dieser Reparatur nicht gelöscht werden. Unterscheiden Sie mehrere Ressourcendatensätze von mehreren in Anführungszeichen gesetzten Zeichenfolgen innerhalb eines TXT -Datensatzes. Unter RFC 7208 §3.3, Zeichenfolgen innerhalb eines Datensatzes werden verkettet; Separate SPF Einträge gibt es nicht.
Speichern Sie die vollständige DNS Antwort, TTL und autoritative Serverinformationen. Bestätigen Sie die entsprechende Zone und den Namen des Eigentümers, bevor Sie etwas ändern. Ein Anbieter kann den Zonennamen automatisch an ein Hostfeld anhängen, sodass ein scheinbar korrekter Editoreintrag beim falschen Namen landet.
Rekonstruieren Sie den beabsichtigten Sendersatz
Erstellen Sie pro Mechanismus eine Zeile mit vier Feldern: Geschäftsdienst, verantwortlicher Eigentümer, Konfiguration des unterstützenden Anbieters und Nachweis des aktuellen Sendens. Identifizieren Sie bei expliziten IP-Bereichen, wer die Adressen verwaltet und warum dieser Bereich benötigt wird. Überprüfen Sie für Includes die aktuellen Anweisungen und rekursiven Richtlinienabhängigkeiten des Anbieters. Behandeln Sie einen unbekannten Mechanismus als eine Frage, die es zu lösen gilt, und nicht als eine Erlaubnis, die Sie für immer behalten können.
Trennen Sie Absender, die diese Umschlagdomäne verwenden, von Diensten, die ihre eigene Umschlagdomäne verwenden. Die sichtbare Absenderadresse eines Anbieters reicht nicht aus, um zu beweisen, dass sein Datenverkehr hier eine SPF Einbindung benötigt. Ebenso bedeutet die Abwesenheit während eines kurzen Beobachtungszeitraums keinen Rücktritt: Rechnungen oder saisonale Kampagnen werden möglicherweise unregelmäßig ausgeführt.
Erstellen Sie eine geordnete Richtlinie
Behalten Sie die ausgewählten Berechtigungen und eine absichtliche endgültige Richtlinie bei. Verketten Sie nicht ganze Datensätze und lassen Sie einen zweiten übrig v=spf1 Token oder ein alle Mechanismus in der Mitte. Unter RFC 7208 §5.1, ein frühes alle stimmt mit jeder verbleibenden Quelle überein, sodass spätere Mechanismen nicht erreichbar sind.
Beispielhafter Ausgangszustand: Ein Datensatz ist v=spf1 ip4:192.0.2.10 -all; ein anderer ist v=spf1 ip4:198.51.100.20 ~all. Wenn es sich bei beiden reinen Dokumentationsadressen um bestätigte, aktuelle Absender handelt, ist eine mögliche zusammengeführte Richtlinie möglich v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 ~all. Die Auswahl des endgültigen Qualifikationsturniers erfordert eine eigene Routing-Überprüfung. Wenn der zweite Absender eingestellt würde, würde durch die Zusammenführung unnötige Autorität erhalten bleiben.
Bewerten Sie die vollständige Richtlinie, einschließlich verschachtelter Einschlüsse und Weiterleitungen. Unter RFC 7208 §4.6.4, RFC 7208 legt während der Auswertung eine Grenze von zehn Begriffen fest, die eine Suche verursachen; Es reicht nicht aus, nur sichtbare Include-Anweisungen zu zählen. Explizit IP4 Und IP6 Mechanismen selbst verbrauchen dieses Laufzeitbudget nicht, aber das Ersetzen verwalteter Includes durch kopierte IP-Listen führt zu einer Wartungspflicht.
Bereitstellung ohne einen längeren unklaren Zustand
Bevorzugen Sie eine atomare Aktualisierung DNS -Eintragssatzes, wenn der Anbieter dies unterstützt: Ersetzen Sie die konkurrierenden Richtlinien durch den genehmigten einzelnen Eintrag in einer Änderung. Wenn die Schnittstelle separate Änderungen erfordert, planen Sie die Reihenfolge und berücksichtigen Sie das vorübergehende Risiko fehlender oder doppelter Richtlinien. Erstellen Sie keinen „temporären“ zusätzlichen SPF Eintrag und lassen Sie ihn zur Weitergabe übrig.
Überprüfen Sie verbindliche Antworten und dann relevante rekursive Antworten. Zwischengespeicherte alte Antworten behalten ihre vorherigen Aktualitätsintervalle; RFC 8767 §4 Ermöglicht auch die qualifizierte Verwendung veralteter Antworten nach Ablauf. TTL ist keine garantierte globale Widerrufsfrist. Senden Sie repräsentative Nachrichten von jedem beauftragten Dienst und bestätigen Sie die ausgewertete Identität und das Ergebnis bei einem vertrauenswürdigen Empfänger. Testen Sie auch eine unübertroffene Quelle unter Ihrer Kontrolle, damit ein versehentlicher universeller Durchgang nicht mit Erfolg verwechselt wird.
Bewahren Sie die Reinigungsbelege auf
Der Änderungsdatensatz sollte jeden beibehaltenen und entfernten Mechanismus, die Suchauswertung, den DNS Status vorher und nachher und die Testergebnisse erläutern. Eine Warnung wegen doppelter Datensätze wird nur geschlossen, wenn ein ausgewählter SPF Datensatz vorhanden ist und die Richtlinie den überprüften Absendersatz angibt. Dadurch wird aus einer einmaligen DNS Reparatur ein wartbarer Autorisierungsbestand.
Notieren Sie die Entscheidung und ihre Grenzen
Für das Beispiel mit zwei Adressen sollte ein Berechtigungsarbeitsblatt jede Eigentümerentscheidung und erwartete Übereinstimmung getrennt vom endgültigen Qualifikationsmerkmal speichern. Das zusammengeführte ~all Beispiel gibt immer noch softfail für eine nicht übereinstimmende Adresse zurück; Es handelt sich nicht um eine Empfehlung, eine bisherige -all abzuschwächen. Das Ändern dieses Qualifikationsmerkmals erfordert eine explizite Entscheidung. Für diese Abbildung wurde kein DNS Update oder Übermittlungstest durchgeführt.