Pidä Account Engagement erillään muista Salesforce -sähköpostituotteista
Salesforce Account Engagementilla on oma toimialueen hallinnan työnkulku. Aloita vahvistamalla, että viesti on lähetetty Account Engagementin kautta, jota aiemmin kutsuttiin Pardotiksi, eikä Salesforce ydinsähköpostin tai Marketing Cloud Engagementin kautta. Toisen Salesforce tuotteen DNS resepti voi käyttää erilaisia ohjausobjekteja, eikä sitä tule tuoda vain siksi, että organisaatio käyttää samaa toimittajaa. Tämä opas kattaa Account Engagement -lähetysverkkotunnuksen vahvistuksen, DKIM ja valinnainen tuki-avusteinen mukautettu paluupolku.
Luettele jokainen tilin käyttämä liiketoimintayksikkö, tuotemerkki ja tarkoitettu From-verkkotunnus. Sisällytä kampanja- ja automaatioasetusten mukaan valittu todellinen lähettäjä. Käyttäjän postilaatikon osoitteessa näkyvää toimialuetta ei ole määritetty automaattisesti jokaiselle Account Engagement -reitille. Määritä markkinoinnin omistaja ja DNS järjestelmänvalvoja tarkistamaan mainosjakauma yhdessä ennen jaetun verkkotunnuksen tietueiden muuttamista.
Hyväksyntätavoite on kontrolloitu vastaanotettu viesti, jossa on kohdistettu läpäisytodennusmekanismi. Verkkotunnuksen omistajuuden vahvistus, DNS julkaisu ja vihreä hallinnointitila ovat hyödyllisiä välitodisteita. Mikään ei yksinään todista, että tietty kampanja käytti aiottua identiteettiä tai että vastaanottava palvelin hyväksyi sen todennuksen.
Ymmärrä SPF -oletuspolku ennen kuin muokkaat juuri DNS ää
Salesforce's Account Engagement DNS -ohjeet toteaa, että Tilin sitouttamisposti kulkee SPF ohjatun lähetysinfrastruktuurinsa kautta, eikä se vaadi asiakkaan SPF muutosta oletusasetuksiin. Älä lisää yleistä Salesforce SPF -lisäystä organisaation juuriverkkotunnukseen vain siksi, että tuotteen nimi näkyy DMARC raportti. Vahvista ensin todellinen reitti ja arvioitu henkilöllisyys.
SPF todentaa SMTP POSTIA LÄHETTÄJÄ henkilöllisyys, erillisellä käsittelyllä HELO, alla RFC 7208. Sen tulos on erilainen linjaus näkyvillä From. Onnistunut tarjoajan verkkotunnuksen SPF tarkistus voi olla rinnakkain kohdistamattoman SPF kanssa. Eri toimialueen käytännön muuttaminen ei muuta sitä, mitä kirjekuorialuetta viesti käyttää.
Säilytä SPF -käytäntö, jota organisaation muut palvelut tarvitsevat. Jos erikseen valtuutettu mukautettu asennus edellyttää käytännön muutosta, tarkista yksi täydellinen käytäntö kyseiseltä omistajalta, mukaan lukien sisäkkäiset DNS-kyselytermit ja protokollan hakurajoitus. Älä luo sekuntia SPF ennätys tai poista asiaankuulumattomat lähettäjät tehdäksesi tilaa vahvistamattomalle vaatimukselle.
Vahvista omistajuus ja DKIM erillisinä tietueina
Käytä Domain Managementia tunnistaaksesi aiotun sähköpostin lähetysalueen ja sen odotetut DNS merkinnät. The DNS opastus erottaa toimialueen vahvistusavaimen sen DomainKeystä. Vahvistusarvo määrittää lähetyksen omistajuuden; DKIM arvo tukee viestin allekirjoitusta. Säilytä molemmat tarkoitukset laskentataulukossa sen sijaan, että käsittelet niitä TXT tietue sisältää Salesforce arvon vaihdettavana todisteena.
Kopioi arvot varsinaisesta tilistä. Tallenna koko tietueen omistaja, tyyppi, arvo ja ohjepäivämäärä ennen DNS muutoksen tekemistä. Tarkista, onko toinen Account Engagement -tili tai eri palvelu jo riippuvainen samasta omistajasta. Älä korvaa ristiriitaista tietuetta, käytä uudelleen toisen asiakkaan arvoa tai muuta a valitsin keksittyyn nimeen. Pyydä tukea tuettuun ratkaisuun, kun tilijärjestelyt törmäävät.
Pidä sähköpostin lähetysverkkotunnus erillään seurantaverkkotunnuksesta. Salesforce varoittaa nimenomaisesti käyttämästä identtistä toimialuetta näille kahdelle toiminnolle. Brändätty seurantaisäntänimi ei ole sama asia kuin Lähettäjä-verkkotunnus, vaikka molemmilla jaettaisiin vanhempi. Varaston seurantariippuvuudet erikseen, jotta todennustyö ei vahingossa muuta resurssien URL-osoitteita tai kampanjalinkkejä.
Julkaise DomainKey dokumentoidun työnkulun kautta
Salesforce's DKIM käyttöönottoohjeet vaatia Account Engagege Administrator -roolia. Avaa Lightning-sovelluksessa Account Engagement Settings ja sitten Domain Management. Vaihtoehtoisessa Account Engagement -rajapinnassa dokumentoitu lähtökohta on Admin. Avaa Sähköpostin lähetystoimialueet -kohdassa Odotetut DNS merkinnät valitulle toimialueelle ja kopioi DomainKey-arvo julkaistavaksi TXT muodossa.
Käytä kyseiselle tilille ja verkkotunnukselle näkyvää omistajaa ja arvoa. Nykyisessä artikkelissa sanotaan, että allekirjoituksen voimaantulolle on annettava enintään 24 tuntia tietueen lisäämisen jälkeen. Käsittele sitä palveluntarjoajan ajoitusohjeena, ei takuuna siitä, että jokainen DNS välimuisti tai -vastaanotin päivittyy samassa hetkessä. Kirjaa julkaisuaika muistiin ja odota odotettua tilaa ennen kuin arvioit uuden testin.
Vahvista julkinen DNS vastaus, mukaan lukien tarkka täysin pätevä omistaja. DNS editorit lisäävät joskus vyöhykkeen nimen isäntäkenttään ja luovat kaksoisliitteen, kun koko nimi syötetään. Tarkista tuloksena oleva vastaus sen sijaan, että luotat syöttölomakkeeseen. Tallenna mahdolliset Domain Management -virheet ja niiden tiedot, jotta tuki voi tutkia todellisen vian muunnetun tilan sijaan.
Päätä, tarvitaanko mukautettu paluupolku
Salesforce's DMARC tukiartikkeli kuvaa tasattua DKIM ää normaaliksi DMARC poluksi ja selittää, että oletusarvo paluupolku verkkotunnus ei ole linjassa näkyvän Lähettäjä:n kanssa. Se dokumentoi myös tukiavusteisen mukautetun paluupolkupyynnön. Ilmoitettu rajoitus on yksi kiinteä mukautettu paluupolun toimialue liiketoimintayksikköä kohti, eikä jokaiselle viestille valittu muuttuva toimialue.
Ennen kuin pyydät tätä vaihtoehtoa, määritä liiketoiminnan vaatimus. Organisaation, joka tarvitsee yhdenmukaistetun SPF ja DKIM tulee arvioida todellinen verkkotunnuksen järjestely ja kohdistustila tuen avulla. Liiketoimintayksikön, joka lähettää lähetyksiä toisiinsa liittymättömille brändeille, ei pitäisi olettaa, että yksi kiinteä paluupolku voi kohdistaa jokaisen From-verkkotunnuksen. Pidä suunnittelukysymys avoimena, kunnes havaitut identiteetit ja tuetut kokoonpanot ratkaisevat sen.
Hanki tarkat DNS tietueet tukitapauksesta ja pyydä DNS omistajaa tarkistamaan ristiriidat ja riippuvuudet. Tämä artikkeli ei sisällä yleistä mukautetun palautuspolun kohde- tai aktivointikytkintä. Arvattujen tietueiden julkaiseminen tai toisen tuotteen palautusaluemäärityksen kopioiminen voi katkaista työreitin ilman vaatimusta.
Testaa valittua lähettäjää varsinaisen viestivirran kautta
Lähetä vaarattomia hallittuja viestejä jokaisen olennaisesti erilaisen lähetysalueen ja liiketoimintayksikön reitin kautta. Käytä samaa lähettäjän valintaa kuin suunniteltu kampanja tai automaatio. Tallenna kampanjaviite, viestin tunnus, UTC-aika ja ulkoinen testivastaanottaja. Jos esikatselu- tai testiominaisuus käyttää eri polkua kuin tuotanto, ratkaise ero ennen kuin käsittelet sitä edustavana todisteena.
Kaappaa luotetussa vastaanottavassa järjestelmässä From, Return-Path ja kaikki DKIM -allekirjoitusalueet ja valitsimet. RFC 6376 määrittää d=- ja s=-arvot, joita käytetään julkisen vahvistusavaimen paikantamiseen. Vertaa havaittua allekirjoitusaluetta määritettyyn lähetysalueeseen. DNS -tietue voi olla oikea, vaikka viesti käyttää edelleen odottamatonta lähettäjää tai muuta reittiä.
Käytä RFC 9989 todellisiin tuloksiin. DMARC voi kulkea tasaisen ohituksen läpi DKIM -allekirjoitus tai kulkee kohdistettu SPF . Kirjaa ylös, mikä mekanismi antoi tuloksen ja mitä kohdistustilaa käytettiin. Pidä SPF -todennus, SPF kohdistus, DKIM -todennus ja DKIM kohdistus erillisissä kentissä. Tämä estää yksittäistä vihreää tilaa piilottamasta testaamatonta vaatimusta.
Tee vianetsintäraja sen sijaan, että vaihtaisit jokaista säädintä
Jos lähettävä verkkotunnus on vahvistamaton, vertaa sen vahvistusavainta ja tarkkaa DNS omistajaa odotettuihin DNS merkintöihin. Jos DKIM puuttuu odotetun aktivointijakson jälkeen, vahvista valittu From-verkkotunnus ja tili ja tarkista sitten Domain Management -virheet. Jos allekirjoitus epäonnistuu, tarkista valitsin ja julkinen arvo ja tarkasta kaikki alavirran järjestelmät, jotka muuttavat sanomaa allekirjoituksen jälkeen.
Jos DMARC epäonnistuu SPF ohituksen aikana, tutki kohdistus ja onko tälle lähettäjälle määritetty kohdistettu DKIM . Älä pidä SPF oletusmenestystä lupauksena DMARC menestystä. Jos kyseessä on mukautettu palautuspolku, vertaa havaittua kirjekuoren identiteettiä kiinteään liiketoimintayksikön asetukseen ja tuen antamiin ohjeisiin. Säilytä edustava epäonnistunut viesti diagnoosia varten.
Pidä organisaation DMARC käytäntö ja raportointikohteet nykyisessä omistuksessaan. Salesforce artikkelissa kuvataan ulkoisen DMARC valvonnan tarvetta sen sijaan, että Account Engagement kerää niitä epäonnistumisraportit. DNS -todennustyön ei pitäisi hiljaa korvata raportointikohteita tai heikentää pakottamista toisiinsa liittymättömien lähettäjien välillä. Tarkista kaikki ehdotetut käytäntömuutokset erikseen sähköpostin ja tietoturvan omistajien kanssa.
Account Engagement -verkkotunnuksen laskentataulukko
- Tili, liiketoimintayksikkö, brändi ja lähetystyönkulku: ____.
- Valittu Lähettäjä-osoite ja määritetty sähköpostin lähetysalue: ____.
- Erillinen seurantaverkkotunnus ja sen olemassa olevat riippuvuudet: ____.
- Vahvistusavain ja DKIM -tietueviitteet odotettavissa olevista DNS merkinnöistä: ____.
- Julkiset DNS vastaukset, julkaisuaika ja hallinnan tila: ____.
- Oletus- tai tukiavusteinen mukautettu paluupolun suunnittelu: ____.
- Mukautetun paluupolun rajoitus ja tukivahvistus tarvittaessa: ____.
- Testiviesti-ID, UTC-aika, Lähettäjä-, Return-Path ja DKIM identiteetit: ____.
- Luotetut todennustulokset ja kohdistettu DMARC mekanismi: ____.
- Poikkeukset, omistajan valvonta ja hyväksytty palautus: ____.
Kuvitteellinen esimerkki SPF menestyksestä ilman kohdistusta
Vain fiktiivinen kirjallinen tapaus: AE-01 olettaa, että liiketoimintayksikkö North lähettää muodossa news@example.org ja liiketoimintayksikkö Etelä lähettää muodossa news@example.net . Ehdotettu kiinteä mukautettu paluupolku osoitteessa bounce.example.org voi olla kohdakkain ensimmäisen rennosti SPF tasauksen alaisena, mutta sen ei voida olettaa vastaavan riippumatonta toista. DKIM -allekirjoitukset ja SPF -tulokset jäävät tuntemattomiksi, joten kummallakaan reitillä ei ole vahvistettua DMARC -tuomiota. Markkinoinnin ja sähköpostin omistajien tulee erottaa liiketoimintayksikön asetukset ja vahvistaa kohdistettu DKIM valittua From-verkkotunnusta kohden ennen SPF juuren muokkauksen pyytämistä. Kaikki identiteetit ja järjestelyt on keksitty; tukitapausta, DNS kyselyä tai viestiä ei suoritettu.
Pidä valmistuminen sidottuna eläviin todisteisiin
Dokumentoitu työnkulku ei vahvista todellisen vuokralaisen käyttöoikeuksia, luotuja arvoja tai mukautetun paluupolun kykyä. Nämä tilitarkastukset, reaaliaikainen DNS ja otsikkovarmennus, visuaalinen tarkistus ja ihmisen pk-yritysten hyväksyntä ovat edelleen odottavia. Tämä opas on julkaisematon, eikä sitä saa esittää todisteena siitä, että organisaation kampanjat on todennettu tuotannossa.
Erottele ohimenevä viesti täytäntöönpanovalmiudesta
RFC 9989 osio 7.4 edellyttää kelvollista DKIM ää toimialueen julkaisulle p=reject ja varoittaa 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.