Eventuell bietet sich eine alte DNS Schnittstelle an ein Rekord Typ beschriftet SPF. Diese Bezeichnung kann sich auf den historischen Ressourceneintrag vom Typ 99 beziehen, bei dem es sich nicht um das Veröffentlichungsformat handelt, das von der aktuellen SPF Spezifikation Version 1 gefordert wird. RFC 7208 §3.1 Erfordert SPF Richtlinie in TXT , DNS Typ 16, und hat den früheren Ansatz des alternativen Typs eingestellt.
Für einen Administrator, der eine ältere Domäne verwaltet, besteht die nützliche Aufgabe in einer Kompatibilitätsbereinigung: Stellen Sie fest, was tatsächlich bereitgestellt wird, korrigieren Sie TXT und identifizieren Sie alle Altsysteme, die noch vom Typ 99 abhängen, bevor Sie veraltete Daten entfernen.
Bestätigen Sie den Kabeltyp
Ein Produkt kann „ SPF “ als benutzerfreundliches Konfigurationsetikett verwenden, während es tatsächlich TXT Daten erstellt. Eine andere Schnittstelle kann tatsächlich Typ 99 erzeugen. Treffen Sie Ihre Entscheidung nicht allein aufgrund des Menütexts. Fragen Sie TXT explizit ab und fragen Sie den Typ 99 separat ab, sofern Ihr DNS Tool dies unterstützt. Speichern Sie die Antworttypen, den Besitzernamen, die Werte und TTLs.
Die SPF Richtlinie gehört zum ausgewerteten Domänennamen. Eine TXT Richtlinie im Stammverzeichnis deckt nicht automatisch eine separate Umschlag-Subdomäne ab. Stellen Sie sicher, dass die überprüfte Domäne mit einer echten Absenderidentität übereinstimmt, bevor Sie zu dem Schluss kommen, dass ein fehlendes TXT Ergebnis ein E-Mail-Problem erklärt.
Verstehen Sie, warum eine doppelte Veröffentlichung nicht das Ziel ist
Das Historische RFC 4408 §12 zeichnet die Zuteilung des SPF Typs 99 auf; Diese experimentelle Spezifikation ermöglichte einen alternativen Ressourcendatensatztyp. RFC 7208 §3.1 erklärt, dass der Übergangsansatz kein zuverlässiges gemeinsames Bereitstellungsmodell hervorbrachte und TXT nur für SPF Version 1 ausgewählt hat. Die Beibehaltung zweier abweichender Kopien verbessert die moderne SPF Bewertung nicht; Es entsteht eine andere Konfiguration, die Menschen möglicherweise inspizieren und missverstehen.
Ein Datensatz vom Typ 99 allein reicht daher für eine standardkonforme Veröffentlichung SPF Version 1 nicht aus. Ein Richtig TXT Eintrag ist die operative Priorität. Wenn TXT und Typ 99 nicht übereinstimmen, wählen Sie nicht den strengeren Wert aus. Rekonstruieren Sie die beabsichtigte Absenderrichtlinie anhand der aktuellen Diensteigentümer- und Anbieteranweisungen.
Planen Sie eine konservative Migration
Beginnen Sie mit dem Exportieren des vorhandenen DNS Status. Wenn TXT nicht vorhanden ist, entwerfen und validieren Sie die richtige Richtlinie, bevor Sie sie veröffentlichen. Wenn TXT bereits vorhanden ist, bestätigen Sie, dass es sich unten um den einzigen anwendbaren SPF TXT Eintrag handelt RFC 7208 §4.5 und wertet richtig aus. Erstellen Sie keine weitere TXT Richtlinie, nur weil Typ 99 vorhanden ist.
In einem synthetischen Beispiel bedient eine Domäne den Typ 99, der Folgendes enthält v=spf1 ip4:192.0.2.10 -all hat aber keinen SPF TXT Eintrag. Eine moderne TXT-basierte Auswertung bezieht ihre Richtlinie nicht aus diesem Typ-99-Wert. Durch die Veröffentlichung einer genehmigten gleichwertigen TXT Richtlinie wird das fehlende Standardveröffentlichungsformat behoben. Die Adresse dient nur der Dokumentation und darf nicht in die Produktion kopiert werden.
Bevor Sie Typ 99 entfernen, überprüfen Sie die interne Mail-Software, DNS Automatisierung, Überwachungsskripte und Änderungsverfahren auf veraltete Erwartungen. Ein lokales Tool kann es dennoch abfragen, auch wenn der Standard dies nicht erfordert. Aktualisieren Sie diese Abhängigkeiten bewusst und entfernen Sie dann den veralteten Datensatz aus den Änderungskontrollen der Organisation. Hierbei handelt es sich um eine Migrationsvorsichtsmaßnahme und nicht um eine Empfehlung, Typ 99 auf unbestimmte Zeit beizubehalten.
Überprüfen Sie DNS und tatsächliche E-Mails
Überprüfen Sie maßgebliche TXT Antworten nach der Veröffentlichung und berücksichtigen Sie rekursive Caches. Testen Sie echte Nachrichten von den beibehaltenen Sendediensten an vertrauenswürdigen Empfängern und notieren Sie dabei die verwendete SMTP Identität und das SPF Ergebnis. Ein Receiver-Reporting-Durchlauf für eine andere vom Anbieter kontrollierte Umschlagdomäne beweist nicht, dass die TXT Richtlinie der korrigierten Domäne ausgeübt wurde.
Aktualisieren Sie die Runbooks auf TXT Typ 16 und erfassen Sie den erwarteten Besitzernamen. Wenn die Benutzeroberfläche des Anbieters weiterhin ein SPF -Label verwendet, dokumentieren Sie, was dadurch erstellt wird. Dadurch wird verhindert, dass das gleiche Problem während einer Registrarübertragung oder einer DNS-Anbietermigration erneut auftritt.
Definieren Sie den Abschlussnachweis
Behalten Sie die Vorher-Nachher DNS Antworten, die Genehmigung der Absenderrichtlinien, die Bestandsaufnahme veralteter Abhängigkeiten und repräsentative Nachrichtentests bei. Ziel ist eine gepflegte SPF Richtlinie der Version 1 im erforderlichen Format, wobei alte Tools keine widersprüchlichen Beweise mehr liefern.
Nutzen Sie die Beweise für eine Entscheidung
Behalten Sie für das reine Typ99-Beispiel separate Abfrageergebnisse für TXT und Typ99 bei. Unter der Annahme einer gültigen Identität und keinem Suchfehler findet eine standardkonforme SPF Prüfung keine TXT Richtlinie und gibt keine zurück; Typ 99 wird nicht ausgeliehen. Fordern Sie nach einer genehmigten TXT Änderung vor dem Abschluss ein Muster mit dieser genauen Identität an. Hierbei handelt es sich um erwartetes Protokollverhalten, nicht um eine gemessene Migration.