En SPF beroenderegister svarar på en praktisk fråga: om detta DNS värde ändras eller den här leverantören försvinner, vilken affärspost påverkas och vem kan bestämma vad som ska göras? En kopia av toppnivån TXT post kan inte svara på den frågan på egen hand. Beroenden kan vara kapslade, kontrolleras utanför din organisation och nås endast för särskilda indata.
Modellera policyn och dess konsumenter
Skapa en policypost för varje SMTP domän som används, med dess exakta DNS ägarnamn, aktuella post, fångsttid, zonägare och ändringsprocess. Bifoga de applikationer och affärsenheter som använder den identiteten. Håll synliga från domäner i separata fält så att ingen misstar dem för SPF uppslagsidentiteten. En överordnad domän SPF rekord ärvs inte automatiskt av ett barn. RFC 7208 §2.4, RFC 7208 §4.
Lägg till en kant för varje inkludering, omdirigering och annan DNS-beroende term, identifiera målet och vem som kontrollerar det. Inkludera och omdirigera är inte utbytbara: en inkludering matchar när dess rekursiva kontrollavkastning passerar, medan omdirigering delegerar utvärdering när den aktuella policyn når modifierarens villkor. Bevara termordning och kvalificeringar i ögonblicksbilden. RFC 7208 §5.2, RFC 7208 §6.1.
Lagra tillräckligt med bevis för att agera
Rekommenderade registerfält är: policydomän; företagstjänster; företagsägare; teknisk ägare; leverantörskontoreferens; beroendemål; skäl för tillstånd; representant som skickar IP:er; normala och failover-envelope-domäner; ögonblicksbild datum; evaluated-path resultat; föreslagna nästa granskning; och pensionsvillkor. Håll inloggningsuppgifter och privata nycklar utanför registret. Begränsa interna kontoreferenser till lämpliga granskare.
För dynamiska makron, registrera både uttrycket och representativa utökade värden. Ett tillplattat beroendediagram utan indataidentitet, IP och tid är inte ett fullständigt utvärderingsspår. SPF :s DNS-fråga-orsakande termgräns gäller under utvärdering, inklusive rekursiva kontroller, så en väg kan nå ett problem som en annan väg undviker. RFC 7208 §4.6.4, RFC 7208 §7.
Gör registret användbart mellan team
Belysande exempel: upphandling och kundsupport är båda beroende av _spf.service.example.net genom samma organisationspolicy. Upphandling planerar att avsluta sitt kontrakt och begär borttagning. Beroenderegistret exponerar supporttjänsten innan den delade inkluderingen raderas. Beslutet blir tjänstepensionering eller isolering, snarare än en ogranskad DNS rensning.
Tilldela en teknisk policyägare att samordna delade ändringar, samtidigt som du behåller företagets ansvar för varje konsument. Kräv onboarding för att lägga till ägaren och testa bevis, migrering för att uppdatera beroenden och offboarding för att lösa återstående konsumenter. Detta är en driftrekommendation, inte ett extra SPF -protokollkrav.
Granska ändringar istället för att jaga en poäng
Diff ögonblicksbilder för att upptäcka nya mål, borttagna auktoriseringar, utökade avstånd och ändrade sökvägar. Undersök en förändring i sammanhanget: en leverantör kan på ett legitimt sätt rotera infrastruktur. Verifiera förändringar med stor genomslagskraft med hjälp av aktuella instruktioner från första part och bevis från mottagna meddelanden. Arkivera det gamla tillståndet och beslutet och uppdatera sedan registret efter att DNS ändringen lyckats.
Ett användbart kompletteringstest är en bordsövning: välj ett beroende och identifiera alla berörda tjänster, beslutsägaren, testvägen och återställningsvägen. Om laget inte kan göra det har registret fortfarande en lucka även om varje aktuell SPF kontroll passerar.
Använd ett konkret beslutsprotokoll
För exemplet med delad leverantör, ge beroendet två konsumentposter, upphandling och support, med separata ägare och pensionsvillkor. Om upphandlingen avslutas medan stödet kvarstår, är det ännu inte motiverat att ta bort den gemensamma positiva inkluderingen. Fånga den aktuella policyn, termkvalificeraren, representativa IP/envelope-ingångar och kapslade målögonblicksbilder innan du föreslår isolering. Det här exemplet illustrerar ett beslut, inte en genomförd inventeringsrevision.