Kuidas saata rakendusest e-kirju nii, et need jõuaksid postkasti

Rakenduse e-kirjade usaldusväärseks saatmiseks kasuta e-kirjade saatmise teenusepakkujat, mitte oma postkasti, saada kirju oma domeeni aadressilt ja lisa teenusepakkuja antud DNS-kirjed, et SPF, DKIM ja DMARC kõik läbiksid kontrolli. Hoia tehingulised kirjad, nagu parooli lähtestamised, kviitungid ja kinnitused, turunduskirjadest eraldi, saada igaüks ainult neile, kes seda ootavad, ning käsitle tagasipõrkeid ja tellimustest loobumisi. Õigesta kõigepealt autentimine; see on kõige sagedamini põhjus, miks rakenduse kirjad satuvad rämpsposti.

Tehinguline vs turunduslik e-kiri

Need kaks e-kirja tüüpi näevad koodis välja sarnased, kuid postkastide teenusepakkujad ja seadus käsitlevad neid väga erinevalt.

Hoia need lahus. Kui turunduskampaania saab rämpsposti kaebusi, ei taha sa, et sama voo parooli lähtestamised selle pärast kannataksid. Levinud lähenemine on eraldi alamdomeenid, näiteks mail.example.com kontokirjadele ja news.example.com uudiskirjadele. Mõned teenusepakkujad eraldavad need ka oma sees. Näiteks Postmark kirjeldab oma tehingulisi ja massisaatmise "sõnumivooge" nii, et need töötavad eraldi saatmisinfrastruktuuril (seis septembril 2026).

Saatmisteenuse valimine

Rakendus ei tohiks kirju saata ise oma serverist. Saatmisteenuse pakkujad hoolitsevad infrastruktuuri, IP-maine, uuesti proovimiste ja tagasipõrgete töötlemise eest. Tuntud valikud on Postmark, Resend, SendGrid, Amazon SES ja Mailgun; igal neist on HTTP API ja SMTP-ligipääs. Hinnad ja paketid muutuvad, seega võrdle neid nende enda lehtedel.

Mida võrrelda:

• Fookus. Mõned teenusepakkujad keskenduvad tehingulisele e-kirjale, teised kombineerivad tehingulise ja turunduse.
• Arendajakogemus. Selge API, ametlikud teegid sinu keelele ja kasulikud logid, mis näitavad, kas iga kiri kohale jõudis, tagasi tuli või rämpsposti märgiti.
• Veebihaagid tagasipõrgete, kaebuste ja kohaletoimetamiste kohta, et sinu rakendus saaks nende peale reageerida.
• Mallid — teenusepakkujas salvestatud või sinu enda koodis. Malli hoidmine koodis teeb selle versioonitud ja testitavaks.
• Piirkond ja andmete töötlemine, kui sul on nõudeid selle kohta, kus andmeid töödeldakse.
• Hind sinu mahus, sh see, mis juhtub, kui ületad tasuta paketi piiri.

Uudiskirjade saatmiseks nimekirjale sobib sageli paremini eraldi uudiskirja- või e-turundustööriist kui kampaaniafunktsioonide ehitamine oma rakendusse.

Seadista saatedomeen

Saada kirju oma domeenilt — hello@example.com, mitte Gmaili ega Outlooki aadressilt. Tasuta postkasti aadressilt kolmanda osapoole teenuse kaudu saadetud kiri ebaõnnestub autentimiskontrollides ja selle tõenäosus filtreeritud saada on suur.

Kaalu alamdomeeni ainult saatmiseks. Näiteks Resend soovitab saata alamdomeenidelt nagu updates.example.com, et eraldada saatmismaine (seis septembril 2026). See hoiab ka e-posti DNS-kirjed sinu põhilehe omadest eraldi.

Teenusepakkuja annab seejärel DNS-kirjed, mis tuleb lisada sinu domeeni DNS-i haldamise kohas. Kui DNS on sulle uus, selgitab kuidas domeenid ja DNS töötavad kõigepealt kirjeid.

SPF

SPF (Sender Policy Framework) on TXT-kirje, mis loetleb, millised serverid tohivad sinu domeeni nimel e-kirju saata. Vastuvõtja kontrollib, kas saatev server on nimekirjas.

• Domeenil peaks olema ainult üks SPF-kirje. Kui lisad teenusepakkuja, ühenda see olemasoleva kirjega, mitte ära lisa teist.
• SPF lubab hindamisel kõige rohkem 10 DNS-päringut; pikad include:-ahelad võivad selle ületada ja põhjustada tõrkeid.
• Paljud teenusepakkujad seadistavad SPF-i alamdomeenil, mille loomist nad palluvad, nii et sa ei pruugi oma peamist SPF-kirjet üldse puudutada.

DKIM

DKIM (DomainKeys Identified Mail) lisab igale kirjale krüptograafilise allkirja. Teenusepakkuja allkirjastab privaatvõtmega; sina avaldad vastava avaliku võtme DNS-kirjena (TXT või CNAME, sõltuvalt teenusepakkujast). Vastuvõtja kontrollib allkirja, et kinnitada, et kiri tuli volitatud saatjalt ja seda ei muudetud teel.

Teenusepakkuja "kinnita domeen" samm käsitleb peamiselt just DKIM-i. Ära jäta seda vahele.

DMARC

DMARC seob need kaks kokku. See on TXT-kirje aadressil _dmarc.sinudomeen.com, mis ütleb vastuvõtjale:

• Joondus: nähtaval saatja aadressil olev domeen peab vastama domeenile, mis läbis SPF-i või DKIM-i.
• Poliitika: mida teha kirjaga, mis ei läbinud kontrolli — p=none (ainult raporteeri), p=quarantine (käsitle kahtlasena, sageli rämpspostina) või p=reject.
• Aruanded: kuhu saata koondaruandeid (rua=), et näha, kes saadab sinu domeeni nimel.

Mõistlik tee on alustada p=none ja aruande aadressiga, kinnitada, et su seaduslikud kirjad läbivad kontrolli, seejärel liikuda quarantine'ile ja lõpuks reject'ile. Range poliitika muudab ka teiste jaoks sinu domeeni võltsimise palju raskemaks.

Mida nõuab Gmail

Septembri 2026 seisuga ütlevad Google'i saatjajuhised:

• Kõik saatjad isiklikele Gmaili kontodele vajavad SPF-i või DKIM-i, saatvate serverite kehtivat päri- ja pöördDNS-i, TLS-i ning rämpsposti määra Postmasteri tööriistades alla 0,3%.
• Massisaatjad (rohkem kui 5000 kirja päevas Gmaili aadressidele) vajavad SPF-i ja DKIM-i, DMARC-kirjet (lubatud on poliitika p=none), saatjadomeeni joondust ning ühe klõpsuga tellimusest loobumise ja nähtava loobumislingi turunduslikel ja tellitud kirjadel.

Teenusepakkuja tegeleb serveripoolsete osadega. DNS-kirjed ja tellimusest loobumise käsitlemine on sinu teha. Isegi kui sa pole lähedalgi 5000 kirjas päevas, on massisaatja reeglite täitmine kõige lihtsam viis olla kindel.

Ehita saatmine oma rakendusse

Kui domeen on kinnitatud:

1. Salvesta API-võti serveripoolse saladusena — mitte kunagi esikülje koodis. Vaata mis on keskkonnamuutujad ja saladused.
2. Saada kiri serverist pärast seda tegevust, mis kirja käivitab, ja alles siis, kui see on edukas.
3. Ära jäta kasutajat kirja ootama. Kõige lihtsamast rakendusest kaugemal saada kiri järjekorda ja proovi ajutiste tõrgete korral uuesti, et aeglane teenusepakkuja vastus ei aeglustaks registreerumist.
4. Logi tulemus — teenusepakkuja sõnumi ID ja staatus —, logimata võtit ega isikuandmeid sisaldavat kirja täielikku sisu.
5. Käsitle veebihaake tagasipõrgete ja kaebuste jaoks: lõpeta saatmine aadressidele, mis kõvalt tagasi põrkuvad või millelt tuleb rämpsposti kaebus.

Näide põhitõdede kohta:

Saada tehinguline e-kiri teenusepakkujaga [PROVIDER], kasutades serveri saladust [ENV_NAME], saatjana "Acme hello@mail.acme.com". Saada tervituskiri pärast registreerumist ja broneeringu kinnitus pärast broneeringu salvestamist. Hoia mallid koodis, koos tavatekstiversiooniga HTML-i kõrval. Pane saatmised järjekorda ja proovi ajutised tõrked kuni kolm korda uuesti. Logi tõrked teenusepakkuja veateatega, aga mitte kunagi API-võtit. Lisa veebihaagi lõpp-punkt, mis märgib aadressid kättetoimetamatuks kõvade tagasipõrgete ja kaebuste korral ning jätab need edaspidi vahele.

Kontokirjad — kinnituslingid, võlupingid ja parooli lähtestamised — on osa sisselogimisest. Kuidas lisada oma rakendusele sisselogimine selgitab, kuidas need voogud kokku sobivad; tee need lingid ühekordseks ja lühiajaliseks.

Kohaletoimetamise harjumused

Autentimine annab sulle usaldusväärsuse. Käitumine hoiab sind postkastis.

• Saada ainult seda, mida inimesed ootavad. Kinnitatud registreerumised, selge nõusolek turunduse jaoks, ostetud nimekirju ei ole.
• Tee tellimusest loobumine lihtsaks kõigil kirjadel, mis ei ole rangelt tehingulised, ja austa seda kohe.
• Soojenda uusi domeene. Täiesti uus domeen, mis saadab esimesel päeval tuhandeid kirju, tundub kahtlane. Alusta tehingulistest kirjadest ja kasvata mahtu järk-järgult.
• Hoia nimekirjad puhtad. Eemalda kõvad tagasipõrked kohe ja kaalu eemaldamist neilt, kes pole pikka aega midagi avanud.
• Kirjuta nagu inimene. Selge teema, äratuntav saatja nimi, tavatekstiosa, vähe pilte ja lingid oma domeenile. Väldi linkide lühendajaid.
• Jälgi. Registreeri oma domeen Google Postmaster Toolsis ja vaata aeg-ajalt DMARC-aruandeid.
• Kasuta päris vastamisaadressi, mida keegi loeb. Vastused on hea signaal ja kasulik tagasiside.

Testi nii, et ühtegi inimest ei spämmita

• Kasuta teenusepakkuja testrežiimi või liivakasti, kui see on olemas, või saada kirju aadressidele, mis on sinu omad.
• Arenduses saada kirjad kõikipüüdvasse testpostkasti, mitte päris kasutajatele; seemnetega andmebaas täis päris moodi aadresse on lihtne viis kogemata võõrastele kirjutada.
• Kontrolli iga malli mitmes kliendis — veebi-Gmail, telefoni postirakendus, Outlook — ja tumedas režiimis.
• Vaata testkirja päiseid: need näitavad, kas SPF, DKIM ja DMARC läbisid kontrolli.

Õiguslikud põhitõed

Reeglid erinevad riigiti. Üldiselt vajab turundusakiri paljudes kohtades nõusolekut, peab tuvastama saatja ja pakkuma toimivat tellimusest loobumise võimalust; tehinguliste kirjade suhtes kehtivad teised reeglid, kuid neid ei tohi kasutada turunduse varjamiseks. Kui kogud aadresse ootenimekirja lehelt, ütle selgelt, mida ja millal saadad ning kuidas iga inimene registreerus. Kahtluse korral vaata reegleid riigis, kus su kasutajad asuvad.

E-kirjade kontrollnimekiri

• Saatmisteenuse pakkuja valitud; API-võti salvestatud serveri saladusena
• Saadetakse oma domeenilt või alamdomeenilt, mitte tasuta postkasti aadressilt
• SPF, DKIM ja DMARC kirjed lisatud ja kontrolli läbivad
• Tehinguline ja turundusline post on lahus
• Saatmised on järjekorras ja proovitakse uuesti; tulemused logitud
• Tagasipõrgete ja kaebuste veebihaagid käsitletud
• Tellimusest loobumine tehinguliste kirjade välistavatel kirjadel, austatakse kohe
• Mallid testitud mitmes kliendis; testkirjad ei jõua kunagi päris kasutajateni

E-kirjade saatmine Mythexi rakendusest

Mythex ei sisalda sinu ehitatud rakenduste jaoks sisseehitatud e-kirjade saatmise teenust, seega tood ise teenusepakkuja, näiteks Resend, SendGrid või Postmark. Salvesta selle API-võti projekti saladusena — agent võib selle küsida vestluses saladuste kaardi kaudu — ja telli vajalikud kirjad lihtsas keeles. Dokumentatsioonis on alustamise prompt lehel saada e-kiri oma rakendusest. Kui ostsid domeeni Mythexi kaudu Pro-paketis, saad lisada teenusepakkuja TXT- ja CNAME-kirjed domeeni DNS-seadetes; vaata kohandatud domeenid.

Küsimused