An SPF afhængighedsregister svarer på et praktisk spørgsmål: hvis denne DNS værdi ændres, eller denne udbyder forsvinder, hvilken virksomhedsmail er berørt, og hvem kan beslutte, hvad der skal gøres? En kopi af det øverste niveau TXT post kan ikke besvare det spørgsmål alene. Afhængigheder kan være indlejret, kontrolleret uden for din organisation og kun nået for bestemte input.
Modeller politikken og dens forbrugere
Opret én politikpost for hvert SMTP domæne, der er i brug, med dets nøjagtige DNS ejernavn, aktuelle registrering, registreringstidspunkt, zoneejer og ændringsproces. Vedhæft de applikationer og forretningsenheder, der bruger denne identitet. Hold synlige fra domæner i separate felter, så ingen forveksler dem med SPF opslagsidentiteten. Et overordnet domæne SPF rekord ikke automatisk arves af et barn. RFC 7208 §2.4, RFC 7208 §4.
Tilføj en kant for hver inkludering, omdirigering og andre DNS-afhængige termer, der identificerer målet, og hvem der kontrollerer det. Inkluder og omdirigering kan ikke udskiftes: en inkludering matcher, når dens rekursive check returnerer passerer, mens omdirigering delegerer evaluering, når den aktuelle politik når denne modifikators betingelser. Bevar terminsrækkefølge og kvalifikationer i øjebliksbilledet. RFC 7208 §5.2, RFC 7208 §6.1.
Gem nok beviser til at handle
Anbefalede registerfelter er: politikdomæne; forretningsservice; virksomhedsejer; teknisk ejer; udbyderkontoreference; afhængighedsmål; grund til tilladelse; repræsentant afsender IP'er; normale og failover-konvolutdomæner; snapshot dato; evalueret-sti resultat; foreslået næste revision; og pensionsforhold. Hold legitimationsoplysninger og private nøgler ude af registret. Begræns interne kontoreferencer til relevante korrekturlæsere.
For dynamiske makroer skal du registrere både udtrykket og repræsentative udvidede værdier. Et fladtrykt afhængighedsdiagram uden input-identitet, IP og tid er ikke et fuldstændigt evalueringsspor. SPF 's DNS-forespørgselsforårsagende termgrænse gælder under evaluering, inklusive rekursive kontroller, så én sti kan nå et problem, som en anden sti undgår. RFC 7208 §4.6.4, RFC 7208 §7.
Gør registret nyttigt på tværs af hold
Illustrativt eksempel: indkøb og kundesupport afhænger begge af _spf.service.example.net gennem den samme organisationspolitik. Indkøb planlægger at afslutte sin kontrakt og anmoder om fjernelse. Afhængighedsregisteret afslører supporttjenesten, før den delte include slettes. Beslutningen bliver tjenestepensionering eller isolation snarere end en ugennemgået DNS oprydning.
Tildel én ejer af en teknisk politik til at koordinere delte ændringer, mens du bevarer virksomhedens ansvar for hver forbruger. Kræv onboarding for at tilføje ejeren og teste beviser, migreringer for at opdatere afhængigheder og offboarding for at løse de resterende forbrugere. Dette er en driftsanbefaling, ikke et ekstra SPF -protokolkrav.
Gennemgå ændringer i stedet for at jagte en score
Forskellige snapshots til at detektere nye mål, fjernede autorisationer, udvidede rækkevidder og ændrede opslagsstier. Undersøg en ændring i kontekst: En udbyder kan lovligt rotere infrastruktur. Bekræft ændringer med stor indflydelse ved hjælp af aktuelle førstepartsinstruktioner og modtagne meddelelsesbeviser. Arkiver den gamle tilstand og beslutningen, og opdater derefter registret, efter at DNS ændringen lykkes.
En nyttig afslutningstest er en bordøvelse: Vælg én afhængighed og identificer hver berørt tjeneste, beslutningsejeren, testruten og tilbagerulningsstien. Hvis holdet ikke kan gøre det, har registret stadig et hul, selvom hver igangværende SPF kontrol består.
Brug en konkret beslutningsoversigt
For eksempel med delt udbyder, giv afhængigheden to forbrugerposter, indkøb og support, med separate ejere og pensionsbetingelser. Hvis indkøb afsluttes, mens støtten er tilbage, er det endnu ikke berettiget at fjerne den fælles positive inkludering. Indfang den aktuelle politik, termkvalifikation, repræsentative IP/konvolut-input og indlejrede målsnapshots, før du foreslår isolering. Dette eksempel illustrerer en beslutning, ikke en gennemført lagerrevision.