En gammel DNS grænseflade kan tilbyde en rekord type mærket SPF. Denne etiket kan referere til den historiske type 99-ressourcepost, som ikke er det udgivelsesformat, der kræves af den aktuelle SPF version 1-specifikation. RFC 7208 §3.1 kræver SPF politik i TXT , DNS type 16, og afbrød den tidligere alternative type tilgang.
For en administrator, der vedligeholder et ældre domæne, er den nyttige opgave en kompatibilitetsoprydning: fastlæg, hvad der rent faktisk serveres, gør TXT korrekt, og identificer eventuelle ældre systemer, der stadig er afhængige af type 99, før du fjerner forældede data.
Bekræft ledningstypen
Et produkt kan bruge " SPF " som en venlig konfigurationsetiket, mens det rent faktisk opretter TXT data. En anden grænseflade kan virkelig skabe type 99. Beslut ikke fra menuens ordlyd alene. Forespørg eksplicit TXT , og hvor dit DNS værktøj understøtter det, forespørgstype 99 separat. Gem svartyper, ejernavn, værdier og TTL'er.
SPF politikken hører til det vurderede domænenavn. En TXT politik ved roden dækker ikke automatisk et separat konvolut-underdomæne. Sørg for, at domænet, der inspiceres, matcher en reel afsenderidentitet, før du konkluderer, at et manglende TXT resultat forklarer et mailproblem.
Forstå hvorfor dobbelt udgivelse ikke er målet
Det historiske RFC 4408 §12 registrerer tildelingen af SPF type 99; at eksperimentel specifikation tillod en alternativ ressource-registreringstype. RFC 7208 §3.1 forklarer, at overgangstilgangen ikke gav en pålidelig fælles implementeringsmodel og valgte kun TXT til SPF version 1. Vedligeholdelse af to divergerende kopier forbedrer ikke moderne SPF evaluering; det skaber en anden konfiguration, som folk kan inspicere og misforstå.
En type 99-record alene er derfor utilstrækkelig til standard-overensstemmende SPF version 1-publicering. En korrekt TXT post er den operationelle prioritet. Hvis TXT og type 99 er uenige, skal du ikke vælge den værdi, der ser strengere ud. Rekonstruer den tilsigtede afsenderpolitik ud fra nuværende tjenesteejerskab og udbyderinstruktioner.
Planlæg en konservativ migration
Start med at eksportere den eksisterende DNS tilstand. Hvis TXT er fraværende, skal du designe og validere den korrekte politik, før du udgiver den. Hvis TXT allerede eksisterer, skal du bekræfte, at det er den eneste gældende SPF TXT post under RFC 7208 §4.5 og vurderer korrekt. Opret ikke en anden TXT politik, blot fordi type 99 eksisterer.
I et syntetisk eksempel tjener et domæne type 99 indeholdende v=spf1 ip4:192.0.2.10 -all men har ingen SPF TXT registrering. En moderne TXT-baseret evaluering henter ikke sin politik fra den type 99-værdi. Udgivelse af en godkendt tilsvarende TXT politik adresserer det manglende standardudgivelsesformat. Adressen er kun til dokumentation og må ikke kopieres til produktion.
Før du fjerner type 99, skal du kontrollere intern mailsoftware, DNS automatisering, overvågningsscripts og ændringsprocedurer for ældre forventninger. Et lokalt værktøj kan stadig forespørge det, selvom standarden ikke kræver det. Opdater disse afhængigheder bevidst, og fjern derefter den forældede registrering under organisationens ændringskontroller. Dette er en migrationsforanstaltning, ikke en anbefaling om at bevare type 99 på ubestemt tid.
Bekræft DNS og faktisk mail
Undersøg autoritative TXT svar efter offentliggørelse, og gør rede for rekursive caches. Test rigtige beskeder fra de bevarede afsendertjenester hos betroede modtagere, noter den anvendte SMTP identitet og SPF resultatet. Et modtagerrapporteringspas for et andet leverandørkontrolleret kuvertdomæne beviser ikke, at det rettede domænes TXT politik blev anvendt.
Opdater runbooks til at sige TXT type 16 og indfang det forventede ejernavn. Hvis udbyderens brugergrænseflade fortsætter med at bruge en SPF etiket, skal du dokumentere, hvad den opretter. Dette forhindrer det samme problem i at vende tilbage under en registratoroverførsel eller DNS-udbydermigrering.
Definer færdiggørelsesbeviset
Behold før-og-efter DNS svarene, godkendelse af afsenderpolitik, opgørelse over tilbagetrukne ældre afhængigheder og repræsentative beskedtests. Målet er en vedligeholdt SPF version 1-politik i det krævede format, hvor gammelt værktøj ikke længere præsenterer modstridende beviser.
Brug beviserne til en beslutning
For eksemplet kun type99, bevar separate forespørgselsresultater for TXT og type99. Forudsat en gyldig identitet og ingen opslagsfejl, finder en standardoverensstemmende SPF kontrol ingen TXT politik og returnerer ingen; den låner ikke type99. Efter en godkendt TXT ændring skal du kræve en prøve, der bruger den nøjagtige identitet, før du lukker. Dette er forventet protokoladfærd, ikke en målt migration.