An SPF hændelse, der ser ud til at være begrænset til ét modtagernetværk, er et sammenligningsproblem. Find først ud af, om netværket har evalueret den samme afsendende IP, kuvertdomæne og DNS politik som dine vellykkede kontroller. En bred autorisationsændring kan skjule forskellen, mens den øger, hvem der kan sende med dit domæne.
Byg en matchet sammenligning
Vælg en mislykket transaktion og en vellykket transaktion fra samme applikation og omtrentlige tidspunkt. Registrer UTC-tiden, tilsluttende IPv4 eller IPv6 -adresse, SMTP MAIL FRA, HELO navn, modtagernetværk, nøjagtigt SMTP svar og betroet godkendelsesresultat, hvis meddelelsen blev accepteret. En meddelelse, der afvises under SMTP har muligvis aldrig en leveret header at inspicere. Bevar i stedet afsenderens transaktionslog. Behandl identifikatorer og meddelelsesindhold som begrænset operationelt bevis.
SPF evaluerer normalt MAIL FROM-domænet; for en nul omvendt sti er dens MAIL FROM-identitet konstrueret ved hjælp af postmaster og HELO domænet. Den synlige Fra-adresse er ikke opslagsinstruktionen. En videresendelsestjeneste kan også ændre den forbindelses-IP, som den endelige modtager ser. RFC 7208 , afsnit 2.3-2.4 og 10.3.
Adskil fejlklasserne
En eksplicit fejl peger mod en evalueret sti, der ikke autoriserede klienten. Permerror opfordrer til inspektion af politik syntaks, multiple SPF optager, rekursive afhængigheder og evalueringsgrænser. Temperror opfordrer til undersøgelse af midlertidige opslags- eller behandlingsproblemer. Ingen betyder, at der ikke blev fundet et brugbart evalueret domæne eller ingen relevant SPF record, snarere end et eksplicit forbud. Neutral betyder, at politikken ikke fremsætter nogen bestemt autorisationspåstand; softfail udtrykker en svagere negativ påstand end fail. Det er heller ikke et SPF pas. Fang resultatet, før du fortolker en generisk "godkendelsesproblem"-billet.
Sammenlign autoritative DNS svar med rekursive svar og deres tidsstempler. Forespørg på det nøjagtige ejernavn og hver afhængighed, der er nået til den IP. SPF 's ti-tidsgrænse dækker vurderet omfatter, a, mx, ptr og eksisterende mekanismer og omdirigeringsmodifikator, herunder indlejret evaluering, i stedet for hver DNS pakke eller TXT fragment. ip4, ip6 og alle mekanismer bruger ikke det tidsbudget; separate grænser kan stadig gælde for andet DNS arbejde. En statisk værktøjsscanning og en modtagers faktiske vej kan derfor være uenige. RFC 7208 , afsnit 4.5-4.6.4 og 8.
Arbejd gennem et kontrolleret eksempel
Illustrativt scenarie: afsenderen når netværk A over en autoriseret IPv4 adresse, men når netværk B over en ikke-listet IPv6 -adresse. Applikationens navn og fra-adresse ser identiske ud. Den nyttige indgriben er at verificere ejerskab og tilsigtet brug af IPv6 ruten og derefter godkende den snævert, hvis det er relevant, eller stoppe med at bruge den. Tilføjelse af modtagernetværket til SPF ville adressere den forkerte side af forbindelsen.
En anden mulighed er videresendelse: netværk B modtager fra en mellemmand i stedet for din oprindelige udgående vært. Tilføj ikke vilkårlige speditører til din politik. Tjek fremsendelsesstien, overlevende justeret DKIM og modtagerens politik. Et bestået SPF resultat kan stadig ikke justeres for DMARC. RFC 9989 , afsnit 4.4.
Luk med reproducerbare beviser
Foretag én kontrolleret ændring med en ejer, gemt tidligere værdi og tilbagerulningstilstand. Gentag de matchede tests gennem den berørte rute, inklusive begge adressefamilier, hvor de blev brugt. Bekræft SPF , tilpasset godkendelse og SMTP håndtering separat. Hvis de samme input og politik stadig giver forskellige resultater, skal du forberede en redigeret bevispakke til den modtagende operatør. Registrer den uløste implementeringsforskel i stedet for at mærke hele netværket ødelagt.
Brug et matchende bevis-arbejdsark
- Mislykket/kontrolpar: optag UTC-tider, applikations- og modtagernetværk for begge.
- Forbindelse: Sammenlign den faktiske IPv4 eller IPv6 kilde og ethvert videresendelseshop.
- Identitet: sammenlign MAIL FROM, HELO og det domæne, som modtageren faktisk tjekkede.
- Politik: behold daterede TXT svar og den evaluerede afhængighedssti.
- Resultat: bevar fejl, softfail , neutral, ingen, temperror eller permerror nøjagtigt, plus SMTP svaret.
- Handling: Reparer kun en bekræftet forskel; gentag den samme rute og behold uløste forskelle til eskalering.