Valitse yrityksen identiteetti ennen DNS vaihtamista
EngageLab-sähköpostissa on sekä mukautetun verkkotunnuksen lähetys että isännöity jaetun verkkotunnuksen reitti. Nämä ovat erilaisia identiteettivalintoja, eivät vaihdettavia pikanäppäimiä. Päätä, täytyykö vastaanottajien nähdä organisaatiosi verkkotunnus. Onnistunut testi palveluntarjoajan omistamasta osoitteesta ei osoita, että yrityksesi verkkotunnus on todennettu. Tallenna tarkka sovellus, näkyvä lähettäjän osoite ja viestin tyyppi ennen DNS -asetusten avaamista.
Lähetysasetukset-dokumentaatiossa kuvataan alkuperäinen testitoimialue, erillinen jaetun toimialueen ominaisuus ja mukautetut yritysalueet. Sen jaettu reitti käyttää aliverkkotunnusta base.engagelab.com ja näkyvä osoite kyseisessä isännöidyssä nimitilassa. Käytä yritysverkkotunnuksen käyttöönotossa mukautetun verkkotunnuksen työnkulkua. Älä käsittele palvelun jaettua mainetta tai ilmaisia kiintiöitä koskevia väitteitä toimitustakuuna tai sopimusoikeutena. Vahvista kaupalliset rajoitukset erikseen.
Kaappaa verkkotunnuskohtainen kokoonpano
Luo tai valitse lähettävä toimialue kohdassa Setting, domain ja hanki sen nykyiset DNS ohjeet. EngageLab-listat SPF, DKIM ja MX tarpeen mukaan, kanssa DMARC valinnainen sen validointitiloissa. Vahvistamaton tarkoittaa, että vaadittu tarkistus puuttuu; Käyttökelpoinen tarkoittaa, että vaaditut tarkastukset läpäisevät; Vahvistettu tarkoittaa, että kaikki näytetyt tarkastukset läpäisevät. Nämä tarrat kuvaavat tuotteen validointia, eivät vastaanotettua viestiä.
Pyydä DNS omistajaa tarkistamaan koko ehdotettu tietuesarja ennen julkaisemista. MX muutos vaikuttaa saapuvan liikenteen reitittämiseen sen omistajan nimessä. Jos ehdotettu nimi vastaanottaa jo henkilökunnan postia, keskeytä ja ratkaise törmäys sen sijaan, että vaihdat sen postinvaihtimia. Erillinen lähetysnimiavaruus voi vähentää törmäyksiä, mutta sen soveltuvuus on vahvistettava todelliseen tilin kokoonpanoon verrattuna. Kirjaa jokaisen muutoksen omistajan nimi, tyyppi, arvo, TTL, vanha arvo ja syy.
Domain API -dokumentaatio paljastaa SPF , DKIM , MX ja DMARC -määritysarvot ja tietuekohtaiset vahvistustulokset. Se on hyödyllinen tilin odotusten ristiintarkistamiseen, ei uudelleenkäytettävien mallitunnistetietojen tai DNS avaimien lähteenä. Kopioi arvot omasta toimialueobjektistasi. Älä koskaan käytä uudelleen esimerkkitoimialueen julkista avainta, oleta sen valitsin koskee sinua, tai ota käyttöön sen esimerkkihylkäyskäytäntö tarkistamatta muita laillisia sähköpostivirtojasi.
Julkaise korvaamatta asiaankuulumattomia käyttöoikeuksia
Lisää arvovaltaiselle DNS isännälle tarkat vaaditut tietuetyypit ja omistajien nimet. DNS paneelit eroavat toisistaan sen mukaan, lisäävätkö ne vyöhykkeen nimen, joten tarkista tuloksena oleva täysin kelvollinen nimi. Väärin sijoitettu valitsin voi jättää uskottavan näköisen tietueen, jota vastaanottajat eivät koskaan kysy. Säilytä täydelliset avaintiedot ja vältä muiden tietojen lisäämistä a CNAME omistaja.
Jos SPF on jo olemassa, sovita uusi valtuutus yhteen SPF -käytäntöön. Älä luo toista v=spf1 -käytäntöä samalla nimellä. Arvioi yhdistetyn käytännön DNS-haun riippuvuudet sen sijaan, että lasket vain näkyviä sisällytyksiä. Säilytä aktiiviset lähettäjät ja vahvistettu lopullinen määrittäjä, ellei verkkotunnuksen omistaja ole erikseen hyväksynyt muutosta. Mikään näistä vaiheista ei anna lupaa laajentaa käyttöoikeuksia asiaankuulumattomiin sähköpostipalveluihin.
Pyydä arvovaltaisia tietueita ja vertaa niitä tallennettuihin tiliohjeisiin. Suorita sitten EngageLab-tarkistus uudelleen, kun välimuistit ovat ehtineet vanhentua. Dokumentaation arvioitu DNS viive ei ole yleinen määräaika. Väärä arvovaltainen vastaus ei korjaa itseään odottamalla. Jos alusta ja arvovaltaiset vastaukset ovat eri mieltä, säilytä molemmat aikaleimoilla ennen ratkaisejan välimuistin vianmääritystä.
Sido sovellus aiottuun reittiin
EngageLab myös ohjeistaa käyttäjiä käyttämään erilaisia lähetysalueita eri ensisijaisilla verkkotunnuksilla trigger- ja joukkopostituksiin, jotta joukkorajoitukset eivät viivästyttäisi trigger-viestejä. Vahvista tämä erottelu tilin omistajalta ennen API_USER-reittien sitomista. kaksi saman ensisijaisen verkkotunnuksen aliverkkotunnusta eivät täytä annettua ohjetta. Tallenna hyväksytty verkkotunnus kullekin viestityypille.
Dokumentoitu API_USER-asetus yhdistää lähettävän toimialueen ja triggerin tai eräviestityypin. Varmista, että sovellus käyttää aiottua yhteyttä. Yhden valtuustodistuksen testaaminen, kun tuotanto käyttää toista, voi tuottaa harhaanjohtavan vihreän tuloksen. Säilytä salaisuudet hyväksytyssä salassa, älä näitä todisteita, kuvakaappauksia tai tukiliitteitä.
Luo pieni reittitaulukko: sovellus, ympäristö, API- tai SMTP -kuljetus, viestin tyyppi, sidottu toimialue, näkyvä Lähettäjäosoite, omistaja ja palautusreitti. Testaa tuotantoa vastaavan koodin polkua valvotuilla vastaanottajilla. Älä päättele, että esikatselu, testitili tai asiaankuulumaton sovellus todistaa integroinnin. Jos kyseessä on aikariippuvainen tapahtumaposti, testaa erikseen käynnistävä työnkulku sen sijaan, että luottaisit onnistuneeseen joukkokampanjaan.
Todista linjaus vastaanotetun viestin kanssa
Säilytä alkuperäinen vastaanotettu viesti ja luotettava vastaanottaja Authentication-Results. Record From, kirjekuoren verkkotunnus, jokainen DKIM d=- ja s=-arvo, SPF -tulos, DKIM -tulos ja DMARC tulos. SPF todentaa kirjekuorialueen; DKIM todentaa allekirjoitustoimialueensa. DMARC tarvitsee vähintään yhden kulkevan todetun polun, joka on kohdistettu näkyvän Lähettäjä-verkkotunnuksen kanssa sovellettavassa tilassa. Todennus ei takaa postilaatikon sijoittamista.
Synteettinen päättelyesimerkki, ei EngageLab-oletus: From receipts@example.com , kirjekuori bounce@other.example.net ja ohittava allekirjoitus, jossa on d=example.com. SPF sivustolle other.example.net ei ole linjassa example.com kanssa, mutta allekirjoitus tarjoaa tarkan DKIM linjaus. Jos allekirjoitus puuttuu tai on virheellinen, oletettua DMARC passia ei tueta. Kirjoita identiteetit tuomioiden viereen, jotta paljas sana, kuten pass, ei voi peittää väärää verkkotunnusta.
Sulje muutos ja säilytä palautus
Jos vahvistus epäonnistuu, selvitä, onko ongelma DNS , verkkotunnuksen yhdistäminen vai viestin allekirjoittaminen. Palauta tunnetusti hyvä sovellusreitti sen sijaan, että heikennät koko toimialueen DMARC käytäntöä. Älä poista avaimia, joita jonossa olevat viestit edelleen käyttävät. Säilytä onnistumisen jälkeen hyväksytty DNS ero, tilin vahvistus, reittilaskentataulukko ja viestitodisteet ja ajoita uusintatarkistus siirto- tai verkkotunnuksen muutoksen jälkeen.
Tämä on dokumentaarinen konfigurointiopas. EngageLab-vuokralaista ei muutettu, tuotanto DNS ei mitattu eikä todellista vastaanotettujen viestien identiteettitaulukkoa kerätty tälle luonnokselle. Yllä olevat tarkastukset ovat hyväksyntätyötä operaattorille, ei vaadittuja tuloksia. Ihmisten hyväksyntä ja reittikohtainen testi ovat välttämättömiä ennen tuotannon käyttöönottoa.
Korjaa verkkotunnuksen sidontavirhe ennen julkaisua
Kirjallinen tapaus EL-01 olettaa, että konsoli on merkitty notify.example.com Usable, kun taas tuotannon käynnistyssovellus pysyy sidottuna isännöityyn jaettuun verkkotunnukseen API_USER. Sen tarkoitettu Lähettäjä on receipts@notify.example.com ; todellisia Lähettäjä-, kirjekuoren tunniste- ja allekirjoitustuloksia ei ole kerätty. Käyttökelpoinen DNS tila ei voi todistaa aiottua sovelluksen identiteettiä. Sovelluksen omistajan on sovitettava sidottu verkkotunnus ja laukaisutyyppi hyväksytyn reitin kanssa ennen vaaratonta kontrolloitua kuittitestiä. Älä luo valtuustietoja tai muuta MX ää vain tehdäksesi laskentataulukosta vihreän. API-kutsua, salaisuutta, DNS muokkausta tai viestiä ei suoritettu.
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ä.