SPF besvarer et snævert spørgsmål: er forbindelsesserveren autoriseret til at bruge domænet præsenteret i en bestemt SMTP identitet? Det starter ikke med afsendernavnet, der vises i en indbakke. Denne sondring forklarer, hvorfor ændring af den forkerte DNS post kan efterlade et godkendelsesproblem urørt.
For en normal ikke-tom omvendt sti er den relevante identitet domænet i SMTP MAIL FRA. Adressen kan være en udbyder-administreret afvisningsadresse i stedet for den synlige forfatter. En separat HELO kontrol kan også forekomme. Når MAIL FROM er tom, konstruerer SPF sin MAIL FROM-identitet ved hjælp af HELO domænet og den lokale delpostmaster. Disse identitetsregler er defineret i RFC 7208 §2.3 og RFC 7208 §2.4.
Følg konvolutten gennem én levering
Forestil dig en ansøgning, der sender en faktura. SMTP forbindelsen kommer fra 192.0.2.44 , dens MAIL FRA er receipts@bounce.example.com , og meddelelseshovedet siger From: billing@example.com . Disse er syntetiske værdier reserveret til dokumentation, ikke en implementeringsopskrift.
Modtageren evaluerer den forbindende IP i forhold til SPF politikken på bounce.example.com . Den vælger ikke example.com 's SPF politik, blot fordi det domæne vises i Fra. En politik hos forælderen autoriserer ikke automatisk sit barn.
Antag at bounce.example.com udgiver v=spf1 ip4:192.0.2.44 -all. IP4-mekanismen matcher, og resultatet er bestået. Hvis forbindelsesadressen var 192.0.2.45 , ville den ikke matche; evaluering ville nå -all og returnering mislykkes. Ingen af resultaterne siger, om fakturaen er ægte, eller om kontoen, der sender den, er blevet kompromitteret.
Identificer beviser, du kan stole på
Bed om den oprindelige modtagne besked i stedet for et skærmbillede af dens visningsnavn. Registrer modtageren, modtagetid, tilslutnings-IP, evalueret SMTP identitet og SPF resultat. Under RFC 8601 §7.1, modtagerens betroede godkendelsesresultater eller logfiler er stærkere bevis end en header leveret af en vilkårlig afsender.
Under RFC 5321 §4.4, en leveret Return-Path kan hjælpe med at afsløre konvolutafsenderen, men det er et spor efter levering snarere end en kommando, du trygt kan redigere for at ændre SPF . Gateways, genindsendelse og videresendelse kan skabe endnu en SMTP transaktion. Diagnosticer transaktionen, hvor den svigtende modtager udførte sin kontrol.
Hold et kort identitetsark: synlig fra domæne; MAIL FRA domæne; HELO navn; forbinder IP; SPF rekord observeret på det tidspunkt; resultat; og eventuelle justerede DKIM resultat. Pointen er at forebygge en rekord editor fra at blive det første diagnostiske trin.
Håndter afvisninger og fremsendelse separat
En tom omvendt sti er normal for visse leveringsmeddelelser. Behandl det ikke som manglende bevis, og erstat det synlige Fra-domæne. Fang HELO og anvend null-path-reglen i stedet.
Videresendelse introducerer et andet problem. Den næste modtager ser speditørens tilslutnings-IP, som muligvis ikke er godkendt af det oprindelige kuvertdomæne. Omskrivning af konvolutten kan ændre den identitet, der kontrolleres. Et pass til den omskrevne identitet justeres ikke automatisk med den synlige forfatter. Undersøg hele ruten og eventuelle overlevende på linje DKIM signatur i stedet for at tilføje alle speditører til din politik.
Forbind SPF med forretningsbeslutningen
DMARC tilføjer en identitetssammenligning: et bestået SPF resultat skal være på linje med forfatterdomænet for at opfylde dets SPF sti. Et separat justeret DKIM pas kan opfylde DMARC , selv når SPF ikke gør det. RFC 9989 beskriver det forhold.
For fakturaeksemplet skal du evaluere justering under de gældende regler for tilstand og registrering af organisationsdomæner; antag ikke, at et delt tekstsuffiks beviser justering i hvert navneområde. Streng SPF justering kræver nøjagtig domænelighed under RFC 9989 §3.2.10.2; afslappet organisationsdomæneopdagelse er specificeret i RFC 9989 §4.10.2.
Før du godkender en ændring, skal du spørge tjenesteejeren, hvilken kuvertidentitet produktet understøtter, og hvem der kontrollerer dets DNS . Bevar den tidligere registrering, foretag den mindste autoriserede ændring, og send en ny repræsentantfaktura gennem den berørte rute. Luk kun problemet, når den observerede identitet, resultat og påkrævede justering opfylder det tilsigtede resultat.
Den praktiske takeaway
Start med SMTP konvolutten og tilslutnings-IP. Redigering af et domæne, som SPF aldrig har evalueret, er ikke en reparation, selvom et registreringskontrolværktøj bliver grønt.
Hold beslutningen reproducerbar
For fakturaopstillingen skal du beholde tilsluttende IP 192.0.2.44 , MAIL FRA domænet bounce.example.com og synligt Author Domain example.com som separate felter. En overordnet TXT redigering er ikke bevis på en repareret børnekontrol. For en videresendt kopi skal du tage en ny transaktionsrække i stedet for at videreføre den originale IP. Disse er hypotetiske input, ikke udførte SPF eller leveringsobservationer.