En DNS editor kan vise flere siterte fragmenter uten å opprette flere poster. Omvendt kan to rader se ut som én policy for en person mens de forblir to uavhengige poster til en mottaker. Kontroller både den nøyaktige verdien og postgrensen før du erklærer en autentiseringspost korrekt.
Les DNS representasjonen
Referanser: RFC 1035 §3.3, RFC 1035 §3.3.14, RFC 7208 §3.3.
RFC 1035 definerer TXT data som én eller flere tegnstrenger. Hver streng er begrenset til 255 oktetter, ikke nødvendigvis 255 viste tegn. En lengre verdi kan oppta flere strenger i én post. Applikasjonen definerer hvordan disse dataene tolkes. Til SPF, RFC 7208 krever eksplisitt sammenhengende strenger innenfor en rekord uten å sette inn mellomrom.
Anførselstegn i sonefilpresentasjon avgrenser strenger. De er ikke automatisk bokstavelige anførselstegn i DNS verdien. En leverandørs skjema kan forvente rå tekst, sitert sonefilsyntaks eller en strukturert liste med strenger. Følg det dokumenterte inndataformatet og inspiser det resulterende svaret i stedet for å legge til eller fjerne sitater til skjermen ser kjent ut.
Ta vare på mellomrom og uavhengige poster
Referanser: RFC 7208 §4.5.
Hvis en SPF verdi deles rett før en mekanisme, beholder du skillerommet inne i en av strengene. To tilstøtende strenger som inneholder v=spf1 og ip4:192.0.2.10 -all ville rekonstruere som en ugyldig token-sekvens uten det mellomrommet. I dette misformede eksemplet er det rekonstruerte prefikset v=spf1ip4, som ikke er et gyldig SPF versjonstoken. Hvis ingen annen post er valgt som en SPF -policy, er SPF resultatet ingen. Bevar den eksakte applikasjonssyntaksen i stedet for å anta at alle TXT forbrukere håndterer mellomrom identisk.
Ikke bli med separat TXT poster bare fordi en parser returnerer dem i én samling. Flere urelaterte TXT -poster hos samme eier er normalt. Flere poster valgt som SPF -policyer hos den eieren er ikke: SPF returnerer en permanent feil i stedet for å slå sammen autorisasjonslistene deres. Ta vare på hele svaret og søknadens utvalgsregel i diagnosen.
Gjengi en grensetest
Syntetisk sonearmatur A inneholder én post: example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10" " -all ". Rekonstruer strengene i rekkefølge uten å legge til bytes. Forventet SPF -tekst er v=spf1 ip4:192.0.2.10 -all. Dokumentasjonsadressen er illustrativ og må ikke brukes til å autorisere en produksjonsavsender.
Fixtur B erstatter A med to poster: example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 -all " og example.com . 300 IN TXT " v=spf1 ip4:192.0.2.20 -all ". Forventet SPF valg er flere policy-poster og en permanent feil. Armatur C beholder A og legger til example.com . 300 IN TXT "site-verification=synthetic"; den urelaterte bekreftelsesposten er ikke en ekstra SPF policy.
Last hver fikstur separat i en isolert testsone. Spørsmål grav @AUTH example.com . TXT +norecurse, erstatter laboratoriemyndigheten med AUTH. Behold ett ressurs-record-objekt per returnert post og dens ordnede strengliste. En trofast sele skal skille A fra B selv om skjermen omslutter lang utgang. Dette er forventede utfall, ikke rapporterte live-tester.
Bekreft den publiserte verdien
Sammenlign redaktørens innspill, hvert autoritativt svar og et rekursivt svar. Sjekk eiernavnet for et tilfeldig gjentatt sone-suffiks. Bruk et DNS bibliotek som bevarer poststrukturen ved automatisering av kontroller; en linjeorientert tekstskrap kan forveksle innpakning med postgrenser.
Behold tidligere verdi og godkjenning før en produksjonsendring. Etter publisering tester du den relevante e-postbanen med ufarlig innhold og fanger opp autentiseringsbevis. Riktig TXT syntaks etablerer en DNS forutsetning; det beviser ikke at en tjeneste signerer meldinger eller at en mottaker godtar dem.
Hold bevisomfanget eksplisitt
Lokal strengsammenkobling bekrefter at den bevarte plassen produserer v=spf1 ip4:192.0.2.10 -all ; utelate det produserer det uvalgte v=spf1ip4 -prefikset. Dette er en tekst-/utvalgsillustrasjon, ikke en utført SPF evaluator eller live DNS spørring.