Käytä tilin määritystä lähtökohtana
Sendloop tarjoaa tilin työnkulun lähettäjän verkkotunnuksen todennusta varten, kun taas sen julkinen todennustoiminto mainitsee myös omistetun DKIM ja linjaus asetukset. Nämä sivut vahvistavat, että todennus on käytettävissä, mutta ne eivät määritä tarkkaa tietuejoukkoa, allekirjoitusidentiteettiä tai kirjekuoren hallintaa tietylle tilille. Tämä opas opastaa sinut dokumentoidun tilin työnkulun ja valvotun vahvistussuunnitelman läpi. Erillinen DKIM järjestely tai mukautetun kirjekuoren vaatimus säilyy toimittajan vahvistuksena. Ohjattu Sendloop-todennustoiminto, DKIM ja verkkotunnuksen kohdistusasetukset.
Tunnista ensin tili, hyväksytty verkkotunnuksista sekä kampanjat tai automaatiot, jotka käyttävät niitä. Kirjaa ylös, onko tilillä erillinen toimitusjärjestely ja kuka voi vahvistaa sen. Älä päättele omistettua infrastruktuuria hinnoittelumerkinnöistä, vanhasta aloitussähköpostista tai kolmannen osapuolen lähettämien IP-osoitteiden luettelosta. Määritä organisaatiolle Sendloop-järjestelmänvalvoja, DNS omistaja ja tarkistaja DMARC politiikkaa.
Ennen kuin teet muutoksia, vie nykyiset DNS merkinnät asianomaisille omistajille. Säilytä yksi edustajan vastaanottama viesti olemassa olevalta hyväksytyltä reitiltä, jos sellainen on saatavilla. Jo toimivien tuotteiden luettelo estää uutta todennusprojektia vahingossa poistamasta toista lähettäjää käytöstä. Kohde on todennettu ja kohdistettu Sendloop-reitti, ei toimialueen sähköpostimäärityksen tukkukorvaus.
Avaa lähettäjän toimialueen ohjauspaneeli
Palveluntarjoajan opas reitittää sinut Asetukset > Lähettäjän verkkotunnuksen todennus > Todista lähettäjän verkkotunnus ja sitten Lisää verkkotunnus. Tuloksena oleva toimialueen ohjauspaneeli tarjoaa tiliin liittyvät arvot ja Tarkista DNS tietueet -toiminnon. Kaappaa tuo tulos ennen DNS muokkaamista. Jos nykyinen käyttöliittymä eroaa, käytä nykyisen toimittajan ohjeita tai tukea vastaavien painikkeiden arvaamisen sijaan. Sendloop-opas, Ohjatun sähköpostin valtuutustoiminnon käyttäminen ja Tarkista todennusasetukset.
Tallenna jokainen täysi omistaja, DNS tyyppi, arvo ja TTL sen tarkoituksella. Säilytä näytettävä tietuesarja vaihtolipun liitteenä. Jos paneeli näyttää puuttuvan tietueen, määritä, onko se poissa, julkaistu väärällä omistajalla vai onko se eri arvoinen. Toimialue, joka on jo määritetty toiselle Sendloop-tilille, saattaa tarvita palveluntarjoajan koordinointia vaihtamisen sijaan.
Yleisessä oppaassa on SPF esimerkki ja olemassa olevan tietueen muutos, jossa ei ole identtisiä, sisältää. Se kuvaa myös tekstitiedostojen valmistelua. Älä muuta kumpaakaan yksityiskohtaa automaattiseksi tuotantoreseptiksi. DNS on sisällettävä nykyinen sovellettava käytäntö; työasemaan tallennettu tekstitiedosto ei julkaise sitä. Ratkaise kaikki ristiriidat tilipaneelin ja julkisen sivun välillä ennen käyttöönottoa. Sendloop-opas, SPF tietueen määrittäminen.
Tarkista SPF laajentamatta asiaankuulumattomia käyttöoikeuksia
Määritä, mitä kirjekuorialuetta todellinen Sendloop-viesti käyttää. Tämä on identiteetti, joka on tutkittava SPF varalta, sen sijaan, että oletetaan, että näkyvän Lähettäjä-verkkotunnuksen on oltava arvioinnin omistaja. Jos valtuutettu mukautettu kirjekuorijärjestely on olemassa, tallenna sen asetukset ja laajuus. Jos näin ei ole, tallenna havaittu toimittajan kirjekuoren identiteetti ja arvioi DKIM kohdistus erikseen.
Jos omistajaa vaihdetaan, säilytä yksi SPF -käytäntö ja säilytä muiden aktiivisten lähettäjien vaatimat valtuutukset. Tarkista sisäkkäiset DNS -haut ennen uusien termien lisäämistä. SPF :n kymmenen aikavälin raja koskee mekanismeja ja modifioijia, jotka aiheuttavat DNS hakuja arvioinnin aikana, ei tietueessa näkyvien sanojen määrää. Myös olemassa olevat sallivat mekanismit kannattaa tarkistaa, mutta niiden poistaminen on erillinen riippuvuuspäätös. RFC 7208 , kohdat 4.5 ja 4.6.4.
Älä kopioi laajaa esimerkkikäytäntöä olemassa olevan tietueen tilalle. Tämä voi valtuuttaa ei-toivotut isännät, muuttaa virhemääritteen tai poistaa toisen palveluntarjoajan. Kun vaadittu valtuutus ei mahdu turvallisesti, pysähdy ja pyydä postin omistajaa valitsemaan tuettu malli. Älä ratkaise ongelmaa julkaisemalla toista SPF -käytäntöä tai poistamalla palveluita, jotka sattuvat olemaan tuntemattomia.
Julkaise vain julkaistu julkinen DKIM materiaali
Käytä tälle tilille annettua omistaja- ja julkista arvoa. Julkinen opas näyttää DKIM TXT -asetuksen, mutta sen esittelyavain ei ole asiakkaan avain. Jos paneeli tai tuki toimittaa toisen tuetun tietuelomakkeen, säilytä tämä ohje sen sijaan, että muunnat sen ilman todisteita. Sendloop-opas, DKIM tietueen määrittäminen.
Vain julkinen vahvistusavain kuuluu DNS . DKIM luo kryptografisen allekirjoituksen yksityisellä avaimella; se ei upota yksityistä avainta lähtevään viestiin. Julkisen oppaan epävirallista selitystä ei pidä lukea allekirjoitussalaisuuksien jakamispyyntönä. Viesti sisältää allekirjoituksen, ja todentaja käyttää julkista avainta, joka on tunnistettu sen allekirjoitusalueelta ja valitsin. RFC 6376 , kohdat 3.5 ja 6.1.
Tarkista ehdotetulta omistajalta toiselle reitille kuuluva aktiivinen avain. Törmäys vaatii koordinaatiota; ei ole turvallista korvata toimivaa valitsinta vain punaisen tilan poistamiseksi. Tarkista täydellinen nimi julkaisun jälkeen, mukaan lukien DNS editorin lisäämä verkkotunnuksen pääte. Säilytä aikaleimat ja kyselytulokset, jotta myöhemmät raportit voivat erottaa vanhentuneen välimuistin väärästä omistajasta tai avaimesta.
Pidä linkkien brändäys linjauspäätelmän ulkopuolella
Palveluntarjoajan oppaassa kuvataan valinnainen CNAME aliasoiduille viestilinkeille. Sen tarkoitus on linkkibrändäys, ei todiste SPF tai DKIM yhdenmukaisuudesta. Ota se käyttöön vain, jos asianmukainen seurantamuutos on hyväksytty ja tili tarjoaa tarkan kohteen. Sendloop-opas, VALINNAINEN: Määritä CNAME tietue.
Tarkista olemassa olevan verkkosivuston tai seurannan käyttö ennen ehdotetun omistajan vaatimista. Älä osoita juurisivustoa tai elävän sovelluksen isäntänimeä seurantakohteeseen. Säilytä vaaraton testilinkki valvotussa kampanjassa, jotta arvioija voi varmistaa sekä sen kohteen että näytettävän isäntänimen. Todennus ja linkkitoiminto ovat erillisiä hyväksyntätarkistuksia; toimiva merkkilinkki ei luo kelvollista allekirjoitusta.
Palaa tilin DNS tarkistukseen julkaisun jälkeen. Vertaa jokaista näytettyä tulosta riippumattomaan julkiseen hakuun. Tietueen odottavat tilat rehellisesti. Jos tili näkyy vahvistettuna, vaikka ulkoinen testi epäonnistuu, jätä muutos avoimeksi ja käytä viestitodisteita jäljellä olevan rajan paikantamiseen.
Kerää vastaanotetun viestin tunnistetietue
Lähetä kampanjan varsinaisen työnkulun kautta ohjattuihin ulkoisiin postilaatikoihin ilman asiakastietoja. Toista olennaisesti eri verkkotunnuksista tai toimituskokoonpanoista. Säilytä alkuperäinen viesti ja luotettujen vastaanottajien tulokset sekä viestitunnus ja UTC-aikaleima. Tallenna kaikki DKIM -allekirjoitukset sen sijaan, että pysähtyisit ensimmäiseen ohitettuun allekirjoitukseen.
Todistetietueen tulee sisältää näkyvä Lähettäjä-verkkotunnus, todennettu kirjekuoren identiteetti, Return-Path, DKIM d= ja s= arvot, SPF ja DKIM -tulokset ja vastaanottimen DMARC tulos. Määritä, mikä välitysmekanismi on linjassa From-verkkotunnuksen kanssa. Rento ja tiukka linjaus vaatii erilaisia verkkotunnusten vertailuja; tallenna käytössä oleva tila. RFC 9989 , tunnisteen kohdistus selitetty.
Jos ainoa ohittava allekirjoitus käyttää riippumatonta palveluntarjoajan toimialuetta, pyydä tuettua asiakastoimialueen allekirjoitusvaihtoehtoa ja sen aktivointiehtoja. Julkisen ohjatun toiminnon omistettu DKIM-yhteystieto ei todista, että vaihtoehto on käytössä, ilmainen, käytettävissä kaikissa sopimuksissa tai määritetty automaattisesti. Hanki nämä vastaukset tarkalle tilille. Älä edusta seurantaaliasta vaihtoehtoisena kirjekuoriverkkotunnuksena.
Käytä epäonnistumista seuraavan tarkistuksen valitsemiseen
Kadonneelle DKIM -allekirjoitus, vahvista tili, joka on valittu Identiteetti ja palveluntarjoajan aktivointi. Jos allekirjoitus epäonnistuu, vertaa havaittua valitsinta ja julkista avainta ennen kuin tutkit allekirjoitettuun sisältöön tehtyjä muutoksia. Testi toisella lähettäjän osoitteella voi onnistua, vaikka kyseinen kampanja epäonnistuu, joten pidä työnkulku vakiona diagnoosin aikana.
SPF virheen varalta, tunnista arvioitu toimialue ja lopullinen lähetyslähde. Jos SPF on läpäissyt DMARC virheen, tarkista kohdistus sen sijaan, että lisäät SPF komponentteja. Jos palveluntarjoaja ei voi dokumentoida vaadittua identiteettivaihtoehtoa, pidä kyseinen vaatimus estettynä ja arvioi toinen tuettu reitti yrityksen omistajan kanssa. Älä alenna koko verkkotunnuksen käytäntöä vain siksi, että yhden palveluntarjoajan testi lakkaa epäonnistumasta.
Valmistele tukipaketti, joka sisältää tilin tunnisteen, asianomaisen toimialueen, julkaistut julkiset tietueet, havaitut DNS vastaukset, viestitunnuksen, ajan ja asiaankuuluvat vastaanottajan tulokset. Sulje pois salasanat, API-avaimet, vastaanottajaluettelot ja asiaankuulumaton viestisisältö. Lyhyt toistettavissa oleva virhe on hyödyllisempi kuin useat korreloimattomat kuvakaappaukset DNS muokkauksista.
Työarkin palautus ja hyväksyminen
Käytä Sendloop-todennuslaskentataulukkoa (luo erillinen tarkistustietue tässä kuvatuilla kentillä) seurataksesi tietueiden poikkeamien tarkistusta, erityisten ominaisuuksien vahvistusta ja lopullista identiteetin vertailua. Puuttuva kirjekuoren ominaisuusvastaus voi jäädä selkeästi ratkaisematta, vaikka tavallinen kohdistettu DKIM toimii. Määrittele hyväksyntä suhteessa liiketoimintavaatimuksiin sen sijaan, että täytä jokainen tyhjä oletus.
Jos muutos epäonnistuu, keskeytä lähetykset ja palauta aiemmin hyväksytty kokoonpano tallennetun muutossuunnitelman kautta. Koordinoi DKIM -muutokset palveluntarjoajan aktivoinnin kanssa; julkisen avaimen poistaminen, kun palvelu vielä allekirjoittaa sen kanssa, aiheuttaa uuden virheen. Kun poistat Sendloopin käytöstä, varmista, että kaikki kampanjat ja automaatiot ovat pysähtyneet, ja tarkista jaetut SPF riippuvuudet ennen luottamuksen tai seurantatietueiden poistamista.
Kuvitteellinen esimerkki SPF erosta
Vain kuvitteellinen kirjallinen tapaus: SLP-01 olettaa, että se on tarkoitettu From offers@workshop.example . Julkinen esimerkki sisältää kaksi palveluntarjoajaa, kun taas sen olemassa olevan politiikan käsky nimeää yhden; nykyisen tilin valtuutus, kirjekuoren identiteetti ja DKIM / SPF -tulokset ovat tuntemattomia. DNS omistaja säilyttää muutoksen ja pyytää tilin omistajaa hankkimaan reittikohtaisen vahvistuksen. Tekstitiedosto ja merkkilinkki eivät vahvista todennusta. Selvityksen jälkeen tiimi tarkastelee yhtä käytäntöä ja kerää valvotun kampanjaviestin. Tiliä, DNS tai lähetystestiä ei suoritettu.
Dokumentaarinen kattavuus ja jäljellä olevat portit
Tämä luonnos kattaa julkisen tilin työnkulun ja turvallisen vahvistuksen. Se ei luo yleistä dedikoitua DKIM- tai mukautettua Return-Path -asetusta, eikä se väitä, että reaaliaikaisesti kohdistettu Sendloop-viesti olisi tarkastettu. Nämä tilikohtaiset tiedot, live DNS ja otsikkotodisteet, riippumaton tarkistus, visuaalinen tarkastus ja ihmisten pk-yritysten hyväksyntä ovat edelleen odottavia. Pidä alkuperäinen täysi toteutusalue odotustilassa, kunnes vaaditut tilin todisteet korjaavat aukot.
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.