An SPF riippuvuusrekisteri vastaa käytännön kysymykseen: jos tämä DNS arvo muuttuu tai tämä palveluntarjoaja katoaa, mihin yrityspostiin tämä vaikuttaa ja kuka voi päättää mitä tehdä? Kopio huipputasosta TXT tietue ei voi vastata tähän kysymykseen yksin. Riippuvuudet voivat olla sisäkkäisiä, hallita organisaatiosi ulkopuolella ja tavoittaa vain tietyillä syötteillä.
Mallina politiikkaa ja sen kuluttajia
Luo yksi käytäntömerkintä kullekin käytettävälle SMTP verkkotunnukselle, jossa on sen tarkka DNS omistajan nimi, nykyinen tietue, sieppausaika, vyöhykkeen omistaja ja muutosprosessi. Liitä sovellukset ja liiketoimintayksiköt, jotka käyttävät tätä identiteettiä. Pidä näkyvissä verkkotunnuksista erillisissä kentissä, jotta kukaan ei luulisi niitä SPF hakuidentiteetiksi. Ylätason verkkotunnus SPF ennätys ei ole automaattisesti peritty lapselle. RFC 7208 §2.4, RFC 7208 §4.
Lisää kullekin include-, redirect- ja muulle DNS-riippuvaiselle termille reuna, joka tunnistaa kohteen ja kuka sitä hallitsee. Sisällytä ja uudelleenohjaus eivät ole keskenään vaihdettavissa: sisällyttäminen vastaa, kun sen rekursiivinen tarkistus palauttaa läpäisyn, kun taas uudelleenohjaus delegoi arvioinnin, kun nykyinen käytäntö saavuttaa kyseisen muuntajan ehdot. Säilytä termien järjestys ja tarkenteet tilannekuvassa. RFC 7208 §5.2, RFC 7208 §6.1.
Säilytä tarpeeksi todisteita toimiaksesi
Suositeltavat rekisterikentät ovat: policy domain; liike-elämän palvelut; yrityksen omistaja; tekninen omistaja; palveluntarjoajan tiliviite; riippuvuustavoite; syy luvan saamiseen; edustaja lähettää IP-osoitteet; normaalit ja vikasietoiset kirjekuorialueet; tilannekuvan päivämäärä; arvioitu polkutulos; ehdotettu seuraavaa tarkistusta; ja eläkeehto. Pidä tunnistetiedot ja yksityiset avaimet poissa rekisteristä. Rajoita sisäiset tiliviittaukset asianmukaisiin tarkastajiin.
Tallenna dynaamisille makroille sekä lauseke että edustavat laajennetut arvot. Litistetty riippuvuuskaavio ilman tuloidentiteettiä, IP-osoitetta ja aikaa ei ole täydellinen arviointijälki. SPF :n DNS-kyselyn aiheuttava termirajoitus on voimassa arvioinnin aikana, mukaan lukien rekursiiviset tarkistukset, joten yksi polku voi saavuttaa ongelman, jonka toinen polku välttää. RFC 7208 §4.6.4, RFC 7208 §7.
Tee rekisteristä hyödyllinen kaikissa joukkueissa
Havainnollistava esimerkki: hankinnat ja asiakastuki ovat molemmat riippuvaisia _spf.service.example.net -sivustosta saman organisaatiokäytännön kautta. Hankinta aikoo päättää sopimuksensa ja pyytää poistamista. Riippuvuusrekisteri paljastaa tukipalvelun ennen kuin jaettu sisällyttäminen poistetaan. Päätöksestä tulee palvelun lopettaminen tai eristäminen, eikä tarkistamaton DNS puhdistus.
Määritä yksi teknisen politiikan omistaja koordinoimaan jaettuja muutoksia säilyttäen samalla liiketoiminnan vastuun jokaisesta kuluttajasta. Edellytä käyttöönottoa omistajan lisäämiseksi ja testaamiseksi, siirrot riippuvuuksien päivittämiseksi ja offboarding ratkaisemaan jäljellä olevat kuluttajat. Tämä on toiminnallinen suositus, ei ylimääräinen SPF -protokollavaatimus.
Tarkista muutokset mieluummin kuin tavoittele pisteitä
Erottele tilannekuvia uusien kohteiden, poistettujen valtuuksien, laajennettujen alueiden ja muuttuneiden hakupolkujen havaitsemiseksi. Tutki kontekstin muutosta: palveluntarjoaja voi laillisesti kiertää infrastruktuuria. Vahvista suuret muutokset käyttämällä voimassa olevia ensimmäisen osapuolen ohjeita ja vastaanotettujen viestien todisteita. Arkistoi vanha tila ja päätös ja päivitä sitten rekisteri DNS muutoksen onnistumisen jälkeen.
Hyödyllinen suoritustesti on pöytäharjoitus: valitse yksi riippuvuus ja tunnista jokainen palvelu, päätöksen omistaja, testireitti ja palautuspolku. Jos joukkue ei pysty siihen, rekisterissä on edelleen aukko, vaikka jokainen nykyinen SPF tarkastus läpäisi.
Käytä konkreettista päätöskirjaa
Anna jaetun palveluntarjoajan esimerkissä riippuvuudelle kaksi kuluttajamerkintää, hankinta ja tuki, erillisillä omistajilla ja eläkkeellä olevilla ehdoilla. Jos hankinnat poistuvat tuen säilyessä, yhteisen positiivisen sisällyttämisen poistaminen ei ole vielä perusteltua. Tallenna nykyinen käytäntö, termin tarkenne, edustavat IP-/kirjekuorisyötteet ja sisäkkäiset kohteen tilannevedokset ennen eristyksen ehdottamista. Tämä esimerkki havainnollistaa päätöstä, ei suoritettua varastontarkastusta.