“SPF passerer i værktøjet" og "modtageren rapporterer SPF fejl" er ikke nødvendigvis modstridende. Værktøjet kan have valideret syntaks, testet en anden IP eller forespurgt nyere DNS . Modtageren evaluerede en bestemt SMTP forbindelse. Diagnosen starter med at rekonstruere den forbindelse, ikke ved at antage, at begge resultater skal være forkerte.
Identificer, hvad værktøjet faktisk bestod
Gem værktøjets input og nøjagtige output. En gyldig registreringsindikator er ikke nødvendigvis et SPF pas for en besked. Hvis den udførte en evaluering, skal du registrere IP-adressen, konvolutafsender, HELO hvor det er relevant og forespørgselstid. Hold skelnen synlig, når du rapporterer hændelsen til andre teams.
Indsaml derefter destinationens betroede godkendelsesresultat eller SMTP afvisningsbeviser. Behandl ikke en afsenderleveret Authentication-Results felt som destinationens dom. RFC 8601 forklarer, hvorfor resultater har brug for en tillidsgrænse.
Sammenlign identitet og forbindelsesadresse
SPF evaluerer forbindelsen i forhold til den relevante SMTP identitet, ikke kun den synlige Fra-adresse. RFC 7208 §2.3 og RFC 7208 §2.4 beskriv HELO og MAIL FRA checks. Sammenlign den modtagerobserverede IP og det evaluerede domæne med værktøjsholderen.
Et illustrativt tilfælde: en applikation viser Fra billing@example.com , men bruger en konvolutidentitet under en udbyders domæne. En værktøjstest af example.com kan være irrelevant for modtagerens faktiske SPF beslutning. I et andet tilfælde forlader applikationen et andet relæ, end administratoren forventede. Ret forståelsen af ruten, før du forlænger tilladelsen.
Som beskrevet i RFC 7208 §10.3, hvis en videresender er involveret, kan den endelige modtager se speditørens forbindelse i stedet for den oprindelige afsendende IP. Tilføj ikke alle observerede speditører til oprindelsesdomænets SPF som en tæppereparation. Vurder det komplette indirekte-mail-flow og andre godkendelsesresultater i stedet.
Sammenlign DNS på de relevante tidspunkter
Hent den aktuelle gældende registrering og afhængigheder. Bevar modtagerens begivenhedstid og alle samtidige DNS beviser. En test udført efter en reparation kan ikke bevise, hvad modtageren så tidligere. På samme måde kan en udbyderafhængighed ændres uden en lokal registreringsredigering.
Tjek autoritativ udgivelse, rekursive svar og fejltilstande. Skelne en gammel cachelagret politik fra en manglende politik eller en midlertidig DNS fejl. RFC 7208 afsnit 2.6 definerer forskellige resultatkategorier; ikke kollaps mislykkes, softfail , temperror og permerror i én diagnose.
Gentag den faktiske sti
Brug en standardbevidst evaluator med de observerede input. Undersøg den matchede mekanisme, kvalifikationer, rekursive afhængigheder og enhver grænse eller DNS fejl. Hvor historisk DNS ikke er tilgængelig, skal du markere genafspilningen som en test af den aktuelle tilstand i stedet for en rekonstruktion af den tidligere begivenhed.
Test begge adressefamilier, hvis afsenderen kan bruge begge. Sammenlign flere berørte og upåvirkede prøver for at se, om fejlen følger en rute, region, IP-familie eller tidsinterval. Dette er en anbefalet diagnosemetode, ikke en påstand om, at en bestemt udbyder distribuerer trafik på en bestemt måde.
Foretag den smalleste understøttede reparation
Ret det bekræftede problem: forkert konvolutkonfiguration, manglende autoriseret omfang, forkert udformet politik, brudt afhængighed eller routing-inkonsistens. Bevar den oprindelige tilstand og opnå den normale ændringsgodkendelse. Udvid ikke politikken blot for at foretage en uforklarlig prøvebeståelse.
Efter reparationen skal du sende gennem den samme applikationsrute og inspicere et nyt betroet modtagerresultat. Check DMARC separat, fordi en rå SPF pas kan være ujusteret og en justeret DKIM pass understøtter muligvis DMARC , selv når SPF fejler. De alignment diagnose guide dækker denne sondring. Luk hændelsen med forskellen mellem det gamle og det nye bevis, ikke bare endnu et grønt ternet screenshot.
DNS -baggrund: RFC 1035 afsnit 3.2.1 definerer ressource-record TTL; RFC 2308 §5 dækker cachelagring af negative svar. RFC 8767 §4 opdaterer TTL-semantik for at tillade gammel brug, når autoritativ opdatering mislykkes. Disse beskriver DNS adfærd, ikke en universel færdiggørelsestid for en ændring.
Brug en konkret beslutningsoversigt
Hypotetisk sammenligning: en checker vurderer IP A mod example.com i dag; gårsdagens modtager vurderede IP B mod bounce.service.example.net . Det er forskellige inputsæt. Registrer både IP/domæne/tidstripler og DNS beviser, der er tilgængelige for hver. Hvis historisk DNS mangler, skal du angive, at det originale resultat ikke kan afspilles fuldt ud. Mærk ikke nogen af værktøjerne defekte ud fra disse observationer alene. Ingen genafspilning eller DNS test blev udført her.