Tunnista kuljetus ennen asennuksen valitsemista
Freshdesk toimialueen vahvistusmenettely koskee sen oletuslähetyspalvelinta. Mukautettu sähköpostipalvelin on eri kuljetus, jonka DKIM asetukset tulee hoitaa kyseisessä palvelussa. Aloita tallentamalla jokainen tukiosoite, sen todellinen palvelinvalinta, näkyvä Lähettäjä, vastauksen kohde ja vastuullinen tukitiimin omistaja. Älä päättele kuljetusta pelkästään osoitteesta.
Erota saapuvan tuen edelleenlähetys lähtevästä todennuksesta. Helpdeskiin saapuva ja lipuksi muodostuva viesti ei todista, että helpdeskin vastauksessa on kelvollinen tasattu allekirjoitus. Toisaalta oikea lähtevä DKIM ei voi korjata saapuneiden viestien edelleenlähetys- tai lippusäikeistysongelmaa. Suunnittele yksi testi kumpaankin suuntaan käyttämällä valvottuja postilaatikoita ja kuvitteellista lippusisältöä.
Hanki ja julkaise luotu tietuejoukko
Järjestelmänvalvoja avaa Järjestelmänvalvoja > Kanavat > Sähköposti > Lisäasetukset > Määritä DKIM . Kopioi neljä luotua CNAME tietueet arvovaltaiseen DNS palveluun, palaa sitten, laajenna verkkotunnus ja valitse Vahvista. Asennus on verkkotunnuskohtainen, ei postilaatikkokohtainen samassa verkkotunnuksessa. Tarkista tilailmaisimet ja tilin järjestelmänvalvojan vahvistus. Lähde: Freshdesk , DKIM tietueiden määrittäminen.
Tilin arvot, eivät näyte blogista, määrittävät omistajien nimet ja kohteet. Ennen kuin lisäät ne, tarkista kaikki olemassa olevat tietueet jokaisen omistajan luona. Jos toinen sovellus käyttää a valitsin, älä poista sitä tai yritä yhdistää useita CNAME kohteita. Freshdesk opas ohjaa ennätysristiriitatapaukset tukeen. Anna tuelle tarkka tili, omistajien nimet ja ristiriitaiset arvot, jotta ongelma voidaan ratkaista arvaamatta.
Jotkut DNS editorit lisäävät vyöhykkeen nimen automaattisesti. Isännästä, kuten selector._domainkey.example.com , voi tulla selector._domainkey.example.com.example.com jos se syötetään väärään kenttään. Tarkista tuloksena oleva täysin pätevä omistaja tallennuksen jälkeen; visuaalisesti uskottava lyhyt etiketti ei riitä. Yleisen pyynnön odottaa etenemistä tulisi seurata, ei edeltää tätä tarkistusta.
Pidä jaetun verkkotunnuksen muutokset rajoitetusti
Yksi liiketoiminta-alue voi palvella useita Freshdesk -tilejä, muita Freshworks-tuotteita ja asiaankuulumattomia sähköpostijärjestelmiä. Säilytä tietueen omistajalle -kartta. Identtiset vaaditut tietueet eivät tarvitse päällekkäistä julkaisua, mutta eri kohteet samalla CNAME omistajalla ovat ristiriidassa. Älä tulkitse päällekkäisiä arvoja koskevaa dokumentaation pikakuvaketta oikeudeksi luoda usean kohteen CNAME tietue.
Älä muuta verkkotunnusta SPF käytäntö vain siksi, että tämän ohjatun toiminnon nimi on DKIM . SPF ja DKIM ovat erillisiä todennusmekanismeja, vaikka toimittajan tietuesarja tukee useita toimituksen näkökohtia. Käytä todellisia määritettyjä siirto- ja nykyisen tilin ohjeita päättääksesi, tarvitaanko erillinen SPF päivitys. Jos päivität SPF , säilytä yksi käytäntö ja säilytä kaikki muut valtuutetut lähettäjät DNS-haun rajoissa.
Testaa koko tukikeskustelu
Aloita ohjattu lippu aiotun saapuvan polun kautta ja lähetä sitten vastaus testattavasta tukiosoitteesta. Säilytä alkuperäinen viesti vastaanottavassa postilaatikossa. Tallenna tukiosoite ja tili, näkyvä Lähettäjä, kirjekuoren verkkotunnus, DKIM d=/s= ja luotettava vastaanottaja Authentication-Results. Testaa toista tukiosoitetta eri verkkotunnuksessa erikseen. Osoitteet, jotka jakavat määritetyn verkkotunnuksen, voivat jakaa DNS asetukset, mutta niillä on silti erilaiset toimintaasetukset.
Synteettinen esimerkki: support@example.com vastaa kelvollisella allekirjoituksella d=example.com ja SPF -passilla riippumattomalle toimittajakirjekuorelle. Tarkan vastaavuuden DKIM voi toimittaa kohdistetun DMARC polku; riippumaton SPF -tulos ei. Jos toinen tukipostilaatikko käyttää mukautettua palvelinta ja siltä puuttuu tämä allekirjoitus, älä oleta, että Freshdesk-oletuspalvelinkokoonpano koskee sitä. Tunnista todellinen kuljetus ja korjaa todennus siellä.
DKIM vahvistaa verkkotunnukseen liittyvän allekirjoituksen. DMARC vaatii kulkevan kohdistetun SPF tai DKIM identiteetin suhteessa näkyvään lähteeseen sovellettavassa tilassa. Kumpikaan mekanismi ei takaa postilaatikon sijoittamista tai tee toisena henkilönä esiintymisestä yleisesti mahdotonta. Tarkista lippujen ketjuttaminen ja vastausten toimittaminen todennuksesta riippumatta.
Diagnosoi validointi ja toimitus järjestyksessä
Jos toimialue puuttuu asetussivulta, tarkista tukisähköpostin asetukset ja vahvistuksen tila ennen tietueiden keksimistä. Jos vahvistus epäonnistuu, vertaa kutakin luotua arvoa luotettavaan DNS ään ja tarkista puutteet, välilyönnit ja päällekkäiset jälkiliitteet. Jos tietueet näyttävät oikeilta, mutta tuotteen vahvistus epäonnistuu, säilytä tilin konteksti, tietueen tulos ja tarkka virhe tukea varten.
Jos DNS ja tuotevahvistus läpäisevät, mutta vastaanottaja ilmoittaa puuttuvan postin, säilytä todellinen lähetysvirhe ja vastaanotettujen näytteiden otsikot. Puuttuva allekirjoitus viittaa reitin tai kokoonpanon yhteensopimattomuuteen; virheellinen allekirjoitus vaatii avaimen ja viestin eheyden tutkimisen; kohdistettu passi huonolla sijoittelulla edellyttää toimitustutkimusta. Älä kierrä toisiinsa liittymättömiä avaimia tai pienennä verkkotunnuksen laajuista DMARC käytäntöä ensimmäisenä vastauksena.
Hyväksy vain osoitettu kattavuus
Säilytä aiemmat tiedot ja tukiasetukset sekä hyväksytty vaihtoehtoinen reitti ennen kuin muutat asiakkaalle suunnattua postia. Poista vanhat tietueet vasta riippuvuustarkistuksen jälkeen. Valmistustietueen on tunnistettava jokainen testattu tukialue ja kuljetus, DNS ja tuotteen validointi, vastaanottimen todennus ja vastaus-/ketjutustulos. Tämä on dokumentaarinen opas synteettisellä esimerkillä, ei live Freshdesk testillä. Riippumaton tarkastus, ihmisten pk-yritysten hyväksyntä ja julkaiseminen vaaditaan edelleen.
Pidä todennus ja lipun sulkeminen erillään
Kirjallinen tukitapaus FD-01 olettaa, että help@example.com käyttää oletusarvoista Freshdesk palvelinta ja valvotulla vastauksella on luotettava DKIM passi d=example.com, s=demo1. Tämä täsmällisesti kohdistettu polku voi täyttää DMARC , mutta SPF on muuten tuntematon. Oletetaan nyt erikseen, että vastausosoite reitittää seuraavan vastauksen väärään jonoon. Todennuksen hyväksyminen ei sulje työnkulkuvirhettä. Tuen omistajan tulee korjata hyväksytty vastausreitti ja toistaa vaaraton keskustelutesti; DKIM korvaaminen tai DMARC alentaminen ei ratkaisisi mainittua ongelmaa. Toinen mukautettua SMTP :tä käyttävä postilaatikko jää tämän oletuspalvelimen tuloksen ulkopuolelle. Nämä ovat määrättyjä opetussyötteitä, eivät suoritettua lippua tai havaittua asiakastapausta.
Säilytä täytäntöönpanoraja
RFC 9989 Kohta 7.4 edellyttää kelvollista DKIM , ei pelkästään SPF , verkkotunnusten julkaisemiseen p=reject, ja varoittaa epäsuoran postin ja postituslistan yhteentoimivuudesta. Yksittäinen onnistunut suoraviestitesti ei ole todiste siitä, että jokainen laillinen reitti on valmis vahvempaan politiikkaan. Säilytä olemassa oleva hyväksytty suojaus diagnosoidessasi todellista aukkoa; Jokainen politiikan muutos vaatii oman päätöksensä.