Varaston verkkotunnukset palvelimen ja sovelluksen mukaan
SocketLabs-todennus tulee tarkistaa sen palvelimen tai alatilin osalta, joka todella lähettää viestin. Aloita luettelosta sovelluksista, jotka näkyvät toimialueista ja kunkin sovelluksen käyttämistä SocketLabs-määrityksistä. Sisällytä erilliset From-aliverkkotunnukset, asiakasbrändit ja varareitit. Yksi toimiva tuotemerkki ei riitä todisteeksi palvelimelle, joka lähettää useiden organisaatioiden puolesta.
Palveluntarjoaja vaatii vahvistettuja lähetysalueita ja dokumentoi virheen, kun osoite ei ole sallittu. Se tukee omistajuuden vahvistamista osoitteen vahvistusprosessin tai kelvollisten DNS todennusominaisuuksien kautta, mutta huomioi samalla, että tilin määritykset ja suunnitelma vaikuttavat lähetysverkkotunnuksen hallintaan. SocketLabs lähettää verkkotunnuksia, lisäämällä ja vahvistamalla lähettävän verkkotunnuksen.
Erillinen lähetysoikeus vastaanottajan todennuksesta. Verkkotunnus voidaan sallia lähettää ilman haluttua asiakasverkkotunnusta DKIM tai kirjekuoren identiteettiä käytetään. Tallenna nämä itsenäisiksi tarkastuksiksi ja hanki verkkotunnuksen omistajan lupa ennen asiakkaan tai kumppanin identiteetin valtuuttamista.
Valitse DKIM menetelmä avaimen omistajan kanssa
SocketLabs dokumentoi kolme tapaa: asiakkaan toimittama TXT avain, palveluntarjoajan luoma TXT -avain ja palveluntarjoajan hallinnoima CNAME. Valinta muuttaa, kuka hallinnoi avaimia ja kuinka niitä ylläpidetään palvelimilla. Sen nykyisen yleiskatsauksen mukaan allekirjoitus edellyttää vastaavuutta From-identiteetin kanssa. SocketLabs DKIM yleiskatsaus, kolme allekirjoitusmenetelmää.
Tallenna päätös ennen DNS työn aloittamista. Jos kyseessä on palveluntarjoajan hallinnoima menetelmä, määritä, kuka voi muuttaa allekirjoitusmäärityksiä. Jos kyseessä on asiakasohjattu menetelmä, tunnista yksityisen avaimen säilyttäjä ja hyväksytty kiertoprosessi. Laskentataulukko täynnä avaimia ei ole hyväksyttävä omistustietue. Työarkin tulee sisältää todisteiden viite ja vastuuhenkilö, ei salainen materiaali.
Älä valitse automaattisesti monimutkaisinta menetelmää, koska se paljastaa enemmän säätimiä. Suosi tuettua lähestymistapaa, joka täyttää organisaation vaatimukset ja jota sen todelliset toimijat voivat ylläpitää. Jos käytäntö edellyttää tiettyä avaintenhallintajärjestelyä tai epätavallista allekirjoitusidentiteettiä, hanki palveluntarjoajan vahvistus ennen kokoonpanon esittämistä tuettuna.
Määritä valittu allekirjoitustapa
Virallisessa oppaassa kuvataan CNAME -allekirjoitusta varten yksi delegoitu DNS tietue ja tilipuolen vahvistus ennen ominaisuuden käyttöönottoa. CNAME oppaassa luetellaan dkim. _domainkey lähettävän verkkotunnuksen alla ja osoittaa osoitteeseen dkim._domainkey.email-od.com . Vertaa tätä julkista dokumentoitua paria käyttötilin ohjeisiin; älä kirjoita varatun päälle valitsin vain siksi, että esimerkki vastaa sen nimeä. Jos DNS isäntä ei voi tukea vaadittua alaviivaa CNAME omistajassa, opas ohjaa käyttäjiä käyttämään TXT lähestymistapaa keksityn oikeinkirjoituksen sijaan. SocketLabs CNAME -allekirjoitusopas.
Tarkista, onko aiottu valitsimen omistaja jo toisen palvelun käytössä. CNAME ei voi liittää turvallisesti asiaankuulumattoman valitsimen päälle. Pyydä sen sijaan tuettua vaihtoehtoa tai hyväksyttyä siirtoa. Säilytä toteutuslipussa olemassa oleva tietue, siihen liittyvät palvelut ja muutospäätös.
TXT opas erottaa avainten luomisen alustassa avainparin tuomisesta. Se vaatii julkisen avaimen DNS ssä ja vahvistaa sen ennen tarvittavien asetusten tallentamista. Luotu avaimen kulku säilyttää yksityisen osansa tilillä. SocketLabs TXT -allekirjoitusopas.
Käytä hyväksyttyä salaisen käsittelyn työnkulkua, jos valittu menetelmä sisältää yksityisen materiaalin tuomisen. Julkaise vain julkinen avain. Tallenna tarkka toimialue ja valitsin ja tarkista tuloksena oleva looginen TXT -arvo DNS-editorin merkkijonojen jakamisen jälkeen. Luotu avaimen opas sanoo, että julkinen avain ei ole enää saatavilla portaalissa onnistuneen DNS julkaisun ja tallennuksen jälkeen. Säilytä julkinen tietue ja sen alkuperä ennen asennuslipun sulkemista säilyttämättä yksityistä avainta tarkistuspaketissa.
Määritä palautusverkkotunnus erilliseksi kartoitukseksi
SocketLabs toteuttaa asiakastoimialueen SPF mukautetun palautusverkkotunnusmallinsa kautta ilman lisäystä olemassa olevaan näkyvään lähteeseen SPF ennätys. Sen opas määrittää CNAME valitusta palautusaliverkkotunnuksesta osoitteeseen tracking.socketlabs.com . Useita palautusmerkintöjä voidaan määrittää; unmatched mail käyttää valittua oletusarvoa tai palveluntarjoajan varavaihtoehtoa. SocketLabs mukautettu palautusopas, asennus ja useita mukautettuja palautusverkkotunnuksia.
Valitse käyttämätön nimi DNS järjestelmänvalvojalta ja vahvista tuettu kartoitus varsinaisessa palvelimessa. Pidä verkkotunnuksen tavalliset saapuvan postin asetukset ennallaan. Palautuspalvelinnimi on sovelluksen toimitusidentiteetti, eikä sitä pidä sekoittaa käyttäjän vastauspostilaatikkoon tai verkkosivuston seurantapäätepisteeseen.
Tallenna tarkoitettu vastaavuus jokaiselle Lähettäjä-verkkotunnukselle ja tallenna sitten oletuskäyttäytyminen. Oletusarvot ansaitsevat selkeän yritysarvioinnin usean tuotemerkin palvelimella: onnistunut toimitus voi silti paljastaa odottamattoman tuotemerkin tai palveluntarjoajan identiteetin. Älä päättele aktiivista kartoitusta pelkästään kokoonpanossa olevien nimien perusteella. Lähetetyt Return-Path on todiste verrattavaksi myöhemmin.
Julkaise ja vertaa julkisia tietueita
Vie asiaankuuluvat DNS tietueet ennen hyväksytyn muutoksen tekemistä. Vahvista arvovaltaisen palvelun ja DNS editorin suhteellisten nimien käsittely. Tarkista jokainen julkaistu omistaja erikseen, mukaan lukien sen CNAME ketju tai TXT vastaus. Oikea DKIM tietue ei todista, että palautusnimi on määritetty, ja oikea palautustietue ei todista, että DKIM allekirjoitus on aktiivinen.
SPF arvioidaan käyttämällä SMTP kirjekuoren identiteettiä, ei pelkästään näkyvää From-tunnusta. Jos toinen palvelu tarvitsee edelleen juuriverkkotunnuksen SPF käytännön, säilytä se. Jokaisella omistajalla, jossa vaaditaan SPF käytäntö, säilytä yksi käytäntö ja tarkista protokollan DNS-kyselyn termirajoitus. RFC 7208 , kohdat 2.4, 4.5 ja 4.6.4.
Odota johdonmukaisia arvovaltaisia ja rekursiivisia vastauksia, jos välimuistiin liittyy. Jos palveluntarjoaja ei voi vahvistaa ennätys, tallenna annettu arvo ja ajoitetut DNS havainnot tueksi sen sijaan, että muutat nimeä toistuvasti. DNS-isäntärajoitus tulee käsitellä dokumentoidulla tuetulla menetelmällä.
Testaa jokaista tarkkaa Lähettäjä-verkkotunnuksen ja poistumisvastaavuutta
Lähetä vaaratonta sisältöä jokaisen materiaalisovelluksen ja palvelimen kautta valvotuille ulkoisille vastaanottajille. Säilytä aika, Viesti-ID ja palveluntarjoajan tai sovelluksen tapahtumaviite. Testaa aliverkkotunnuksista erikseen sen sijaan, että oletetaan, että ylätason verkkotunnus kattaisi ne.
Vanhemmalla CNAME sivulla mainitaan PRA ja Sender soveltuvuuskuvauksessaan, kun taas nykyinen yleiskatsaus ja TXT -sivu kuvaavat tarkan Lähettäjä-osuman. Jos sovellus käyttää erillistä lähettäjän otsikkoa tai muuta epätavallista identiteettiä, hanki selvennys ja testaa juuri kyseistä lomaketta. Älä hiljaa käännä näitä erilaisia lausuntoja yleismaailmalliseksi säännöksi.
Tallenna vastaanottajalle näkyvä From, Return-Path , luotettava SPF identiteetti ja tulos, jokainen DKIM d ja s sekä DMARC tulos. DKIM vahvistus käyttää varsinaisessa allekirjoituksessa olevaa verkkotunnusta ja valitsinta julkisen avaimen paikantamiseen. RFC 6376 , kohdat 3.5 ja 6.1.
Vertaa kutakin ohimenevää identiteettiä soveltuvan alla näkyvään From-kohtaan linjaus -tilassa. Muokattu palautus-aliverkkotunnus voi kohdata rennon SPF kohdistuksen ilman tiukkaa tasa-arvoa. Tasainen ohitus DKIM -allekirjoitus voi itsenäisesti täyttää DMARC . Onnistunut verkkotunnuksen vahvistus tai palveluntarjoajan verkkotunnuksen todennuspassi eivät riitä päättelemään koko tulosta. RFC 9989 , tunnisteen kohdistuksen selitys ja DMARC -arviointi.
Diagnosoi viallinen kerros
Jos kyseessä on lähettäjä ei sallita -virhe, tarkista vahvistus ja oikea palvelimen toimialueen ohjaus ennen DNS avaimien vaihtamista. Jos kyseessä on odottamaton allekirjoitustoimialue, vertaa tarkkaa Lähettäjä määritettyyn DKIM merkintään. Jos kyseessä on odottamaton Return-Path , tarkista palautusosuma ja oletusarvo. Pidä nämä tarkastukset erillään, jotta yhden korjaus ei peitä ongelmaa toisessa.
Jos kryptografinen vahvistus epäonnistuu oikeasta DNS huolimatta, tutki allekirjoitettuun sisältöön tai otsikoihin tehtyjä muutoksia polun varrella. Jos todennus ja kohdistus onnistuvat, mutta postilaatikon sijoitus on huono, tutki vastaanottajan suodatus, maine ja viestin tarkoitus. Todennus ei lupaa toimitusta tai tee jokaista valtuutetun tilin käyttöä lailliseksi.
Tallenna palautus ennen julkaisua
Täytä SocketLabs-toimialue- ja palvelinlaskentataulukko (luo erillinen tarkistustietue tässä kuvatuilla kentillä). Säilytä reittikohtainen matriisi luvista, allekirjoitustavoista, pomppimiskartoituksista ja vastaanotetuista todisteista. Tunnista, kuka voi keskeyttää sovelluksen tai palauttaa aiemmin hyväksytyn palvelinkokoonpanon, jos testaus epäonnistuu.
Älä poista vanhoja julkisia avaimia tai palautustietueita, kun jonossa olevat viestit tai muut palvelimet ovat riippuvaisia niistä. Suunnittele eläkkeelle siirtyminen sovelluksen omistajan kanssa ja testaa uudelleen, kun verkkotunnuksesta, palvelimesta, avainmenetelmästä, palautuksen oletusarvosta tai DNS palveluntarjoajasta on tehty muutoksia.
Kuvitteellinen diagnostiikkatapaus, joka sisältää oletusarvoisen palautusmerkinnän
Vain kuvitteellinen kirjoitettu tapaus: SOCK-01 olettaa, että yksi palvelin lähettää osoitteesta news@alpha.example kirjekuoressa bounces.alpha.example ja ohitetun SPF tuloksen. Toinen reitti käyttää osoitetta From news@beta.example , mutta palaa takaisin kohtaan bounces.alpha.example , myös SPF passilla. Rentoutetun kohdistuksen alla ensimmäinen määrätty kirjekuori kohdistuu; toinen ei. Molemmat DKIM tulokset ovat tuntemattomia, joten täydellistä toisen viestin virhettä tai onnistunutta korjausta ei vaadita. Palvelimen omistajan on hyväksyttävä ja vahvistettava beta-kartoitus ja tarkastettava sitten sen lähettämä Return-Path ja DKIM . Palvelin-, DNS tai viestitestiä ei suoritettu.
Hyväksyminen on vielä kesken
Hyväksy reitti, kun aiottu palvelin sallii verkkotunnuksen, valittu allekirjoitusmenetelmä varmistaa, jokainen palautuskartoitus toimii hyväksytyllä tavalla ja vastaanottajan todisteet vahvistavat vaaditun kohdistetun passin. Tämän julkaisemattoman luonnoksen alkuperäisen laajuuden hyväksyntä, reaaliaikainen vuokraaja ja DNS tarkistukset, riippumaton tekninen tarkastus, visuaalinen tarkastus ja ihmisten pk-yritysten hyväksyntä odottavat.
Erottele ohimenevä viesti täytäntöönpanovalmiudesta
RFC 9989 Kohta 7.4 edellyttää kelvollista DKIM ää verkkotunnuksen julkaisua varten p=reject ja varoituksia epäsuoran postin yhteentoimivuudesta. Yksittäinen kohdistettu SPF tulos ei sinänsä oikeuta hylkäyskäytännön käyttöönottoa. Tarkista kaikki lailliset reitit ja käytännön omistajuus erikseen tästä palveluntarjoajan asetuksesta.