Vahvista CMS:n käyttöönotto ennen ohjeiden valitsemista
Optimizely CMS luo sovellusviestejä, mutta määritetty kuljetus lähettää ne. Aloita tallentamalla CMS-versio, isännöintimalli, ympäristö ja sähköpostiintegraatio, joka käsittelee asianomaisen työnkulun. DXP:llä toimivan CMS:n, itseisännöidyn asennuksen ja sovelluksen, jolla on oma kolmannen osapuolen välitys, ei voida olettaa jakavan yhtä SPF tai DKIM kokoonpano. Optimizely-kampanja on erillinen tuote, jonka markkinointisähköpostin verkkotunnustietueita ei saa lainata CMS-ilmoituksia varten.
Tätä opasta varten haettu ensimmäisen osapuolen DXP-sähköpostipalvelinsivu on DXP for CMS 12 ja Commerce 14. Se dokumentoi pilven tapahtumasähköposti palvelu, SendGrid-tuettu SMTP määritys ja tuki-avusteinen toimialueen todennusprosessi. Tämä artikkeli käyttää tätä reittiä konkreettisena toteutushaarana. Soveltuvuus toiseen CMS-versioon, isännöintitasoon tai mukautettuun integrointiin edellyttää vastaavaa nykyistä dokumentaatiota ja käyttöönottotodisteita. Yleinen luettelon nimi Optimizely CMS on laajempi kuin tässä määritetty määritysalue. DXP-sähköpostipalvelimen asetukset
Nimeä sovelluksen omistaja, käyttöönotto-operaattori, sähköpostin järjestelmänvalvoja ja DNS omistaja ennen määrityksen muokkaamista. Sovi, mikä työnkulku osoittaa onnistumisen: projekti-ilmoitus, sisällön hyväksymisviesti vai muu erikseen määritetty sovellussähköposti. Käytä synteettistä sisältöä ja valvottua vastaanottajaa. Markkinoinnin uutiskirje ei korvaa CMS-ilmoitustestiä vain siksi, että molemmilla tuotteilla on sama toimittajan nimi.
Jäljitä viesti sovellustapahtumasta välitykseen
Katkaise reitti tapahtuman luomiseen, sovelluksen lähettämiseen, SMTP lähetykseen, palveluntarjoajan toimitukseen ja vastaanottajan todentamiseen. Kirjaa ylös, mitä todisteita on saatavilla kussakin vaiheessa. Jos sovellus ei koskaan tuota tai lähetä ilmoitusta, SPF muokkaaminen ei voi luoda sitä. Jos SMTP hylkää tunnistetiedot, viesti ei ole vielä saavuttanut vaihetta, jossa vastaanottaja arvioi DMARC.
Optimizelyn CMS 13 Projects -dokumentaatiossa kuvataan erikseen ilmoitusten lähettäminen ja sanotaan, että sähköposti-ilmoituksia varten on määritettävä SMTP asetukset. Tämä tukee käynnistys- ja lähetysvaiheen tarkistamista, kun varsinainen asennus on CMS 13; se ei vahvista, että CMS 12 -asetuksella on identtiset työn oletusasetukset tai että DXP SMTP -esimerkki soveltuu muuttumattomana. Yhdistä määritysohjeet asennettuun versioon sen sijaan, että sekoitat versioidut katkelmat. CMS 13 -projektiilmoitukset
Erottele jokaisen ympäristön tehokas ajonaikainen kokoonpano lähdetiedostosta, joka voidaan ohittaa käyttöönoton aikana. Lavastus onnistuu rinnakkain tuotantovirheen kanssa, joka johtuu puuttuvasta asetuksesta tai erilaisesta Lähettäjä-osoitteesta. Kerää puhtaat asetukset ja sovelluslokit normaalin suunnitteluprosessin kautta. Älä paljasta SMTP tunnistetietoja, API-avaimia tai asiaankuulumattomia tuotantosalaisuuksia todistepaketissa.
Määritä dokumentoitu DXP-siirto ohjatun käyttöönoton avulla
DXP-oppaassa sanotaan, että sähköpostikonfiguraatiota ei sovelleta automaattisesti vakiokonfiguraatiomuunnoksilla. Siinä kuvataan sähköpostipalvelun valtuustietojen hankkiminen DXP-hallintaportaalin kautta ja SMTP asetusten toimittaminen sovellukselle. Sen esimerkki sisältää sovelluksen ilmoitusidentiteettiasetukset sekä kuljetusasetukset. Käytä tuettua konfigurointimekanismia käyttöönotetussa versiossa ja ympäristössä ja tarkista tuloksena olevat tehokkaat arvot. DXP-sähköpostipalvelimen asetukset
Käsittele valtuustietojen luomista, tallennusta ja kiertoa erillisenä kontrolloituna suojausoperaationa. Tämä opas ei vaadi uutta valtuustietoa, jos hyväksytty toimiva valtuustieto on jo olemassa. Älä koskaan liitä salaisuutta julkiseen artikkeliin, arkiston esimerkkiin, DNS tietueeseen tai tuen kuvakaappaukseen. Mainitse sen sijaan hyväksytty salainen myymälä ja vastuullinen operaattori. Varmista, että käyttöönottolokit ja virheraportointi eivät tulosta valtuustietoja testauksen aikana.
Dokumentoitu DXP-palvelu on tarkoitettu automatisoituun tapahtumaan tapahtuvaan verkkosivustoviestintään. Opas ohjaa asiakkaita, jotka tarvitsevat muita SendGrid ominaisuuksia, kuten oman mukautetun HTML-mallipohjan käytön, erikseen tilattavalle tilille tai toiselle SMTP palveluntarjoajalle. Vahvista käyttötarkoitus sen sijaan, että oletat, että DXP SMTP n käyttö on rajoittamaton pääsy asiakkaan hallinnoimaan SendGrid tiliin. Erillisellä tilillä on oma omistus- ja verkkotunnuksen todennusmenettelynsä.
Pyydä todennusta jokaiselle lähettävälle verkkotunnukselle
Jos tarvitset dokumentoidun DXP-reitin, ota yhteyttä Optimizelyyn lähetysalueen kanssa saadaksesi apua lähettäjän todennuksen aktivoinnissa. Sama opas sanoo, että DKIM on pyydettävä jokaiselle mail-send-domainille ja vaatii lisää DNS tietueita. Hanki tarkka tietuesarja ja ympäristön aktivointisuunnitelma ennen kuin julkaiset mitään. Ei universaalia valitsin, CNAME kohde tai yksityinen avain voidaan johtaa tuotteen nimestä. DXP-verkkotunnus ja DKIM -määritys
Luettele kaikki asiaankuuluvien ilmoitusten käyttämät näkyvät Lähettäjä-verkkotunnukset. Jos usean sivuston sovellukset tai erikseen määritetyt työnkulut käyttävät eri toimialueita, kysy tuelta, mitkä todennuskokoonpanot kattavat kunkin. Älä oleta, että yrityksen ensisijaisen toimialueen vahvistaminen aktivoi automaattisesti jokaisen aliverkkotunnuksen tai vaihtoehtoisen tuotemerkin. Kirjaa ylös, kenen on vahvistettava lähettäjäpuolen aktivointi DNS julkaisun jälkeen.
DXP-sivulla on esimerkki SPF käytännöistä. Käsittele niitä esimerkkeinä dokumentaatiosta, älä täydellisinä tuotantoalueen reseptejä. Selvitä kirjekuoren todellinen omistaja, säilytä muut valtuutetut lähettäjät ja säilytä siellä yksi voimassa oleva SPF käytäntö. Arvioi rekursiiviset hakurajat ennen valtuutuksen yhdistämistä. Jos määritetty siirto eroaa dokumentoidusta DXP-palvelusta, hanki sen sijaan sen omat voimassa olevat ohjeet. SPF RFC 7208
Julkaise jokainen toimitettu DKIM tietue tarkalle omistajalle toimitetun tyypin kanssa. Säilytä aktiiviset valitsimet suunnitellun siirtymän aikana, ratkaise CNAME ristiriidat ennen tallentamista ja pidä yksityiset avaimet DNS ulkopuolella. Tee kysely arvovaltaisilta palvelimilta ja tarkista tuloksena oleva nimi ja arvo; DNS -editorin esikatselu ei riitä. Julkinen tietue tukee validointia vain silloin, kun varsinainen lähtevä viesti käyttää vastaavaa allekirjoitusidentiteettiään. DKIM RFC 6376
Pidä lähettäjän henkilöllisyys ja DMARC -käytäntö koordinoituina
Sovi aiottu näkyvä lähettäjäosoite ennen testiä. Oikea SMTP isäntänimi ja toimivat tunnistetiedot eivät todista, että sovellus käyttää hyväksyttyä Lähettäjä-toimialuetta. Tallenna voimassa oleva ilmoitusidentiteetti ja kaikki sovellustason ohitukset erillään siirtomäärityksistä. Tarkista vastausten käsittely, jotta vastaanottajia ei ohjata valvomattomaan postilaatikkoon ilman liiketoimintapäätöstä.
Tarkista näkyvän verkkotunnuksen nykyinen DMARC -käytäntö ja säilytä sen hyväksytty täytäntöönpano, linjaus ja raportointikokoonpano. DMARC onnistuu, kun vähintään yksi läpäisevä SPF tai DKIM identiteetti linjautuu sovellettavaan tilaan. Palveluntarjoajan omistama allekirjoitustoimialue voi läpäistä kryptografisen vahvistuksen ilman, että se vastaa organisaation näkyvää Lähettäjä-verkkotunnusta. Älä vastaa heikentämällä koko toimialueen käytäntöä ennen kuin olet tutkinut tuetun lähettäjän todennusreitin. DMARC RFC 9989
Sovellusten liitettävyys, palveluntarjoajan todennus ja postilaatikon sijoittaminen ovat erillisiä hyväksymistuloksia. CMS-loki, jossa sanotaan, että viesti on lähetetty, ei ole kuitti lopullisesta postilaatikosta. Vastaanotettu viesti, joka läpäisee DMARC , voidaan silti suodattaa muista syistä. Säilytä nämä erot muutosraportissa, jotta yksi onnistunut taso ei piilota ratkaisematonta ongelmaa muualle.
Uudelleen käytettävä CMS- ja DXP-reittitaulukko
Täytä erillinen kopio jokaisesta käyttöönottoympäristöstä ja olennaisesti erilaisesta lähetystunnuksesta.
- CMS-versio, isännöintimalli, projekti ja ympäristö: ______.
- Tarkka työnkulku, synteettinen laukaisu ja odotettu vastaanottaja: ______.
- Määrityslähde, käyttöönottoversio ja tehokkaat ajonaikaiset asetukset: ______.
- Vain kuljetuspalveluntarjoaja, tilin omistaja ja hyväksytty salainen viite: ______.
- Näkyy lähettäjä, näyttönimi, vastauksen kohde ja kirjekuoren odotus: ______.
- Tukitapaus, joka vahvistaa DXP:n soveltuvuuden ja jokaisen lähettävän verkkotunnuksen: ______.
- Myönnetyt DNS omistajat, tyypit, arvot ja aktivointivaatimukset: ______.
- Nykyiset SPF ja DMARC -käytännöt ja hyväksytty muutosjoukko: ______.
- Viralliset vastaukset, kyselyajat ja palveluntarjoajan vahvistuksen tila: ______.
- Lähetys, SMTP toimitus ja toimittajan toimitustodisteet: ______.
- Vastaanotettu-viesti Lähettäjä, kirjekuori, kaikki DKIM d=/s= -parit ja luotetut tulokset: ______.
- Palautuskäyttöönotto, DNS palautussuunnitelma ja ihmisen hyväksyntä: odottaa.
Kuvitteellinen diagnoosi tuotantoilmoituksen epäonnistumisesta
Tämä esimerkki on fiktiivinen. Ryhmä testaa hyväksyntäilmoituksen vaiheittain ja ottaa sovelluksen käyttöön. Tuotantoviestit käyttävät eri näkyvää Lähettäjä-verkkotunnusta. SMTP lähetys onnistuu, mutta riippumaton vastaanottaja ilmoittaa kelvollisen toimittajan allekirjoituksen, joka ei ole linjassa kyseisen tuotantoalueen kanssa. Tiimi ehdottaa kampanjan DKIM -kohteen kopioimista DNS , koska se kuuluu myös Optimizelylle.
Ehdotettu diagnoosi vertaa tehokasta tuotantoidentiteettiä DXP-tukipyynnön kattamiin toimialueisiin. Tässä skenaariossa vain lavastusidentiteetti sisällytettiin. Korjaussuunnitelmana on pyytää tuettua todennuskonfiguraatiota tuotannon lähetysalueelle, julkaista myönnetyt tietueet ja testata uudelleen varsinainen hyväksyntätyönkulku. Kampanjatietueen lainaaminen ei vahvista, että DXP-allekirjoittaja käyttää sitä. Tämä on toimiva esimerkki, ei live-testi tai väite mistään asiakkaan käyttöönotosta.
Palauta muuttuneesta tasosta
Jos sovellus lopettaa viestien lähettämisen, vertaa käyttöönotto- ja siirtoasetuksia ennen DNS palauttamista. Jos verkkotunnuksen vahvistus epäonnistuu, vertaa tuen saaneita omistajia luotettaviin vastauksiin. Jos todennus onnistuu, mutta toimitus epäonnistuu, tarkista palveluntarjoajan ja vastaanottajan vastaukset laajentamatta turhaan lähettäjän oikeuksia. Säilytä todisteet ennen uudelleenyrityksiä, jotta päällekkäiset ilmoitukset voidaan tunnistaa.
Palautuksen pitäisi palauttaa käyttöönoton tai DNS muutos, johon se vaikuttaa vain vähän, eikä kaikkia valtuustietoja vaihdeta tai koko vyöhykettä nollattava. Poista korvatut valitsimet vasta sen jälkeen, kun sähköpostin omistaja on vahvistanut, ettei mikään aktiivinen tai jonossa oleva reitti tarvitse niitä. Dokumentoitu DXP-haara on perustettu, mutta laajempi CMS-version soveltuvuus, vuokraajakohtaiset asetukset, tuen myöntämät arvot, live DNS , vastaanotetut viestit, visuaalinen tarkistus ja ihmisen pk-yritysten hyväksyntä jäävät odottamaan. Tämän oppaan sovellusmäärityksiä, tunnistetietoja, DNS tietueita tai live-työnkulkua ei muutettu.
Pidä kuljetusturva poissa kopioituista esimerkeistä
Julkisella sivulla on kokoonpanotiedostoesimerkkejä ja se sisältää SSL:n estävän koodiasetuksen. Tämä artikkeli ei hyväksy kyseistä asetusta tai versiota poikkeavaa katkelmaa. Pyydä käyttöönoton omistajaa vahvistamaan tuettu siirto- ja TLS -käyttäytyminen todellisen suoritusajan osalta paljastamatta valtuustietoja. Kuvitteellisessa tapauksessa toimittajan allekirjoitus ei yksin määritä määrittelemätöntä SPF tulosta.
Erillinen viestien hyväksyminen käytännön käyttöönotosta
Ohjattu kohdistettu SPF tulos voi tyydyttää sanoman arvioinnin, mutta se ei yksin oikeuta siirtämään koko toimialuetta hylättäväksi. RFC 9989 Kohta 7.4 edellyttää kelvollista DKIM ää verkkotunnusten julkaisemiseen p=reject ja varoittaa epäsuoran postin yhteentoimivuudesta. Inventoi kaikki lailliset lähettäjät ja epäsuorat reitit ennen kuin käytännön omistaja hyväksyy täytäntöönpanon. Tälle artikkelille ei suoritettu DNS muutosta, vuokraajatoimintoa tai vastaanotettujen viestien testiä.