Valitse Postmark ja identiteetit
Tämä opas kattaa lähtevät viestit, jotka on tosiasiallisesti lähetetty Postmark , ei verkkosivustoja, jotka käyttävät vain Postmark saapuvan käsittelyn yhteydessä. Tallenna sovellus, Postmark ja viestivirta, tarkoitettu Lähettäjä-toimialue ja DNS järjestelmänvalvoja. Eri sovelluksella lähetetty kuitti on testattava erikseen, vaikka sen brändäys näyttäisi samalta. Ennen kuin muutat DNS , tallenna olemassa olevat tietueet ja perusviesti tarkasta työnkulusta.
Postmark verkkotunnuksen varmennustyönkulun tarvikkeet a DKIM TXT tietue ja mukautettuja Return-Path CNAME. Vahvistettu verkkotunnus sallii lähettämisen osoitteista koko verkkotunnuksen alueella, joten verkkotunnuksen vahvistamisen tulee olla sitä edustavan tiimin omistuksessa. Käytä verkkotunnuksellesi näkyviä arvoja, älä eri vuokralaisen arvoja. Postmark verkkotunnuksen vahvistus.
Ota allekirjoitus käyttöön ennen käytännön muuttamista
Avaa Lähettäjän allekirjoitukset, valitse toimialue ja kirjoita DNS asetukset. Kopioi DKIM isäntänimi ja -arvo TXT tietueeseen virallisessa DNS palveluntarjoajassa. Tarkista, lisääkö DNS editori vyöhykkeen nimen; monistettu jälkiliite asettaa avaimen väärään paikkaan. Palaa Postmark ja vahvista tietue. Postmark dokumentoi automaattiset tarkastukset 48 tunnin sisällä ja manuaalisen Verify-kontrollin. Allekirjoitus alkaa vahvistuksen jälkeen. DKIM asetukset.
Älä käsittele vihreää tilaa viimeisenä hyväksymistestinä. Se vahvistaa, että palveluntarjoaja löysi ennätys, ei sillä, että tuotantosovelluksesi olisi käyttänyt tarkoitettua Lähettäjä-osoitetta tai että myöhempi yhdyskäytävä säilytti allekirjoituksen. Ajoita kontrolloitu lähetys varmennuksen jälkeen ja säilytä vastaanottajan alkuperäinen viesti, mukaan lukien kaikki DKIM allekirjoitukset.
Lisää tuettu Return-Path erikseen
Käytä samoissa verkkotunnuksen asetuksissa näkyvää Return-Path isäntänimeä ja sen CNAME kohdetta, joka on dokumentoitu muodossa pm.mtasv.net . Varaa tähän tarkoitukseen käyttämätön isäntänimi. Älä aseta an SPF TXT -tietue samassa omistajan nimessä olevan CNAME rinnalla, äläkä korvaa huipputietueitasi Bounce CNAME lla. Postmark näkyy erilaiset oletusisäntänimien kirjoitusasut, joten live-tilin arvo on etusijalla kopioituun esimerkkiin nähden. Verkkotunnuksen vahvistus.
Postmark ei vaadi sen sisällyttämistä asiakkaan kärkeen SPF ennätys. SPF tarkistus seuraa todellista kirjekuorialuetta. Huipun sisällyttämisen lisääminen ei voi muuttaa palveluntarjoajan omistamaa Return-Path asiakkaan omistamaksi. Dokumentoitu mukautettu Return-Path on aliverkkotunnus; Postmark suosittelee rentoa SPF ää linjaus tälle reitille. Tiukkaa SPF vaatimusta ei korjata lisäämällä lisää osia. Säilytä verkkotunnuksen hyväksytty käytäntö ja käytä tarvittaessa vahvistettua kohdistettua DKIM polkua. Postmark SPF opastus.
Todista sovelluksen tulos
Seuraava on synteettinen vastaanottomalli, ei kaapattu toimitus. Korvaa jokainen esimerkki havaitulla arvolla ja säilytä testin aikaleima ja viestitunnus.
- Todisteet: Näkyvissä; Havainnollistava arvo: receipts@example.com ; Hyväksymiskysymys: Onko tämä hyväksytty sovellusidentiteetti?
- Todisteet: Envelope domain; Havainnollistava arvo: pm-bounces.example.com ; Hyväksymiskysymys: Aktivoituiko mukautettu Return-Path tässä viestissä?
- Todisteet: DKIM allekirjoitusverkkotunnus; Havainnollistava arvo: example.com ; Hyväksymiskysymys: Vahvistiko luotettu vastaanottaja tämän allekirjoituksen?
- Todisteet: DMARC; Havainnollistava arvo: pass; Hyväksymiskysymys: Mikä tasausmenetelmä tuotti tämän tuloksen?
- ra example.com -verkkotunnuksesta ja sen alla olevasta palautusaliverkkotunnuksesta, rento SPF kohdistus voi toimia, kun taas tiukka SPF kohdistus ei. Tarkka verkkotunnuksen välitys DKIM -allekirjoitus voi silti täyttää DMARC vaatimukset. Arvioi havaittu allekirjoitus, älä lupaus, että jokainen viesti on allekirjoitettu. DMARC -linjaus.
Testaa todellista kuittia ja salasanan palautustapahtumaa niiden vastaavien sovelluspolkujen kautta. Vertaa heidän streamejaan ja lähettäjän määrityksiä. Jos toinen menee läpi ja toinen epäonnistuu, tutki poikkeava reitti ennen kuin muutat jaettua DNS . Älä lähetä aitoja kuitteja asiakkaille uudelleen kokeeksi.
Diagnoosi ja toivu
Jos DKIM puuttuu, varmista, että sovelluksen Lähettäjä-verkkotunnus vastaa vahvistettua verkkotunnusta ja että allekirjoitus on aktiivinen. Jos allekirjoitus on olemassa, mutta se epäonnistuu, säilytä vastaanottajan syy ja tarkista tarkka valitsin haku ja mikä tahansa sisältöä muokkaava rele. Jos SPF läpäisee, mutta sitä ei ole kohdistettu, tarkista Return-Path -aktivointi sen sijaan, että lisäät apex-käyttöoikeuksia. Jos DNS vahvistus epäonnistuu, vertaa arvovaltaisia vastauksia, täytä isäntänimi ja tietuetyyppi tilin arvoihin.
Keskeytä vain kyseinen sovellusvirta, jos hyväksyminen epäonnistuu. Palauta tallennettu tietue tai lähettäjäasetus omistajan vaihdon kautta ja testaa sitten valvottu tapahtuma uudelleen. Älä poista vanhaa valitsinta, kun jonossa oleva posti saattaa silti tarvita sitä. Poista käyttämättömät palautus- ja allekirjoitustietueet vasta sen jälkeen, kun olet varmistanut, että mikään muu Postmark ei jaa niitä. Tämä käsikirjoitus perustuu dokumentaatioon; vuokralaista, DNS muutosta tai live-toimitusta ei testattu.
Vertaa tiukkoja ja rentoja tuloksia selkeästi
Oletetaan kirjallisessa tapauksessa PM-01 From receipts@example.com , POSTIA LÄHETTÄJÄ bounce@pm-bounces.example.com ja luotettu SPF -passi osoitteeseen pm-bounces.example.com . Tavallisessa saman organisaation verkkotunnuksen rennossa linjauksessa tämä SPF polku kohdistuu; komennolla aspf=s se ei täsmää example.com . Oletetaan erikseen ohittava allekirjoitus d=example.com, s=demo1: polku linjaa tarkasti ja voi täyttää DMARC myös tiukan SPF:n tapauksessa. Jos DKIM tulee tuntemattomaksi ohimennen sijaan, älä säilytä hyväksyntää aikaisemman lähtökohdan perusteella. Nämä ovat määrättyjä syötteitä, eivät kaapattua Postmark tai neuvoja politiikan heikentämiseksi.
Säilytä täytäntöönpanoraja
RFC 9989 osio 7.4 vaatii kelvollisen DKIM , ei yksin SPF , verkkotunnuksille, joissa julkaistaan p=reject, ja varoittaa epäsuoran postin ja postituslistojen 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ä.