Afprøvning SPF kræver to slags beviser: hvad DNS udgiver, og hvad en modtager vurderede for en bestemt besked. Dig og nslookup hjælper med at inspicere den første. En betroet Authentication-Results felt- eller modtagersidesporing hjælper med at inspicere den anden. Hold disse observationer forbundet med det samme konvolutdomæne, senderute og tidsvindue.
Start med det rigtige domæne
Send en repræsentativ besked gennem den applikation, du undersøger, og bevar dens originale overskrifter. Identificer kuvertidentiteten ud fra pålidelige modtagerbeviser ved hjælp af Return-Path som et fingerpeg i stedet for at forveksle det med den synlige Fra-adresse. For en tom omvendt sti involverer SPF 's identitetshåndtering HELO; antag ikke, at indtastninger af almindelige beskeder dækker dette tilfælde. RFC 7208 §2.3 og RFC 7208 §2.4 beskrive identiteterne.
Skriv den afsendende IP observeret af modtageren, kuvertidentiteten, modtagersystemet og beskedtidspunktet. Upload ikke fulde private overskrifter til en ukendt offentlig checker, blot for at opnå et farvet resultat. En minimal kontrolleret armatur kan ofte besvare det tekniske spørgsmål uden at afsløre ikke-relaterede meddelelsesdata.
Undersøg det offentliggjorte TXT svar
Disse er illustrative skrivebeskyttede kommandoer. Erstat eksempelnavnet med det domæne, der evalueres; de er ikke beviser for tests, der allerede er kørt:
dig TXT bounce.example.com . nslookup - type=TXT bounce.example.com .De BIND gravemanual dokumenterer forespørgselsværktøjet, og Microsofts nslookup reference beskriver forespørgselsmuligheder. Brug en afsluttende prik til et absolut forespørgselsnavn, og undgå utilsigtet søgesuffiksudvidelse. Behold den fulde respons ved fejlfinding, inklusive resolver, status, svar og TTL, hvor vist. Et forkortet svar kan være praktisk at læse, men udelad diagnostisk kontekst.
Undersøg det faktiske ejernavn, og vælg SPF værdien fra ikke-relateret TXT registreringer. Flere citerede tegnstrenge kan tilhøre én TXT post; SPF behandler disse strenge som sammenkædede uden at indsætte mellemrum. To separate gældende SPF optager er et andet problem. RFC 7208 §3.2 og RFC 7208 §3.3 definere denne sondring.
Læs et parret syntetisk resultat
Følgende er et fuldsyntetisk armatur, ikke observeret post eller en produktionsregistrering. Antag, at modtageren så en direkte forbindelse fra dokumentationsadressen 192.0.2.10 , MAIL FRA invoices@bounce.example.com og synlig fra invoices@example.com . Dens DNS svar indeholder én TXT ressourcepost:
bounce.example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " -all "De to strenge i den ene post slutter sig til v=spf1 ip4:192.0.2.10 -all. Det bagerste rum i den første streng adskiller mekanismerne. For den angivne forbindelse matcher adressemekanismen, og det forventede SPF resultat er bestået. Et tilsvarende illustrativt modtagerresultat er:
Authentication-Results : mx.receiver.example ; spf=pass smtp.mailfrom= bounce.example.comBehandl kun dette som troværdigt under den eksplicitte opstillingsantagelse, at mx.receiver.example er destinationens betroede godkendelsestjeneste. En afsender kunne ellers indsætte lignende tekst. Eksemplet viser kun SPF -bevis; det hævder ikke en DKIM, DMARC eller leveringsresultat.
Sammenlign det med dette forskellige syntetiske DNS svar, som indeholder to separate relevante poster med samme navn:
bounce.example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 -all " bounce.example.com . 300 IN TXT " v=spf1 ip4:192.0.2.20 -all "Optagelsesvalg vender nu tilbage permerror frem for at kombinere tilladelserne. Diagnostiser ikke den situation ved at tælle anførselstegn alene; bevare grænserne DNS -ressourceregistrering.
Sammenlign resolvere, når udgivelsen er bestridt
Hvis DNS editoren og en rekursiv forespørgsel er uenige, skal du identificere den autoritative navneservere og forespørg direkte på en verificeret autoritativ server. Dig understøtter formen dig @servernavn TXT; erstatte en faktisk verificeret server og målnavn. Sammenlign svaret og tidsstemplet med det rekursive resultat. Antag ikke, at den DNS konto, der redigeres, er vært for den delegerede zone.
Et aktuelt autoritativt svar og et ældre rekursivt svar kan indikere caching. En timeout, SERVFAIL og et vellykket svar uden relevant registrering er forskellige observationer. Bevar det nøjagtige svar, før du beslutter årsagen. Undgå gentagne gange at redigere en korrekt registrering, blot fordi én observation er forældet.
Evaluer budskabet, ikke kun syntaks
Et TXT opslag udfører ikke SPF . En standardbevidst evaluator har brug for forbindelses-IP og relevante SMTP identiteter plus den DNS tilstand, den løser. Undersøg dets spor for den matchede mekanisme, afhængigheder og fejl. En statisk registreringsvalidator kan rapportere en strukturelt acceptabel politik uden at svare på, om den rigtige afsender består.
På destinationen skal du læse Authentication-Results indsat af en betroet modtager, ikke en vilkårlig tidligere kopi. RFC 8601 gør tillidsgrænsen vigtig. Registrer SPF resultatet og identiteten sammen med DKIM og DMARC -resultater uden at behandle dem som udskiftelige.
Før en reproducerbar testjournal
Gem kommandoerne, forespørgselstider, DNS svar, evaluator-input og redigeret modtagne meddelelsesbeviser. Test hver væsentligt forskellig applikationsrute og adressefamilie i brug. Mærk syntetiske armaturer separat fra observerede resultater. Hvis DNS visningen ser korrekt ud, men modtageren er uenig, skal du fortsætte med værktøjsbeståelse versus modtagerfejl frem for at erklære, at modtageren må tage fejl.
DNS -baggrund: RFC 1035 afsnit 3.2.1 definerer ressource-record TTL; RFC 2308 §5 dækker negativ caching; RFC 8767 §4 opdaterer TTL-semantik og tillader gammel brug, når autoritativ opdatering mislykkes. Disse beskriver DNS adfærd, ikke en universel færdiggørelsestid for en ændring.
Optag den næste beslutning
For enkelt-record-armaturen skal grænsen vise to strenge inde i en plade og sammenføjningsrummet; forventet SPF er bestået for 192.0.2.10 . For to-record-armaturen mislykkes udvælgelsen med permerror , før mekanismer evalueres. Gem antagelsen om pålideligt resultat separat: Den udskrevne tekst Authentication-Results er ikke uafhængigt troværdig. Ingen kommando- eller mailbekræftelse blev udført her.