Kā sūtīt e-pastus no savas lietotnes (un nonākt iesūtnē)

Lai no savas lietotnes sūtītu e-pastus uzticami, izmantojiet e-pasta sūtīšanas pakalpojumu, nevis savu pasta kontu, sūtiet no adreses savā domēnā un pievienojiet pakalpojumu sniedzēja dotos DNS ierakstus, lai SPF, DKIM un DMARC visi tiktu izturēti. Nodaliet transakcijas e-pastu — paroļu atjaunošanu, čekus, apstiprinājumus — no mārketinga e-pasta, sūtiet katru tikai cilvēkiem, kas to sagaida, un apstrādājiet atsitušās adreses un atteikšanos. Vispirms nokārtojiet autentifikāciju; tā ir biežākais iemesls, kāpēc lietotnes e-pasts nonāk surogātpastā.

Transakcijas un mārketinga e-pasts

Šie divi e-pasta veidi kodā izskatās līdzīgi, bet iesūtnes pakalpojumu sniedzēji un likums ar tiem rīkojas ļoti atšķirīgi.

Turiet tos atsevišķi. Ja mārketinga kampaņa saņem surogātpasta sūdzības, nevēlaties, lai paroļu atjaunošanas e-pasti no tās pašas plūsmas par to cieš. Parasta pieeja ir atsevišķi apakšdomēni — piemēram, mail.example.com konta e-pastam un news.example.com jaunumu vēstulēm — un daži pakalpojumu sniedzēji nodala abus iekšēji. Piemēram, Postmark apraksta savas transakcijas un izsūtīšanas „ziņojumu plūsmas“ kā atsevišķu sūtīšanas infrastruktūru (2026. gada septembrī).

Sūtīšanas pakalpojuma izvēle

Jūsu lietotnei nevajadzētu sūtīt e-pastu pašai no sava servera. Sūtīšanas pakalpojumu sniedzēji nodrošina infrastruktūru, IP reputāciju, atkārtotus mēģinājumus un atsitušo ziņojumu apstrādi. Pazīstamas iespējas ir Postmark, Resend, SendGrid, Amazon SES un Mailgun; katrai ir HTTP API un SMTP piekļuve, cenas un plāni mainās, tāpēc salīdziniet tos to vietnēs.

Ko salīdzināt:

• Fokuss. Daži pakalpojumu sniedzēji koncentrējas uz transakcijas e-pastu, citi apvieno transakcijas un mārketingu.
• Izstrādātāju pieredze. Skaidrs API, oficiālas bibliotēkas jūsu valodai, noderīgi žurnāli, kas rāda, vai ziņojums ir piegādāts, atsists vai atzīmēts kā surogātpasts.
• Webhook atsitumiem, sūdzībām un piegādēm, lai lietotne varētu reaģēt.
• Sagataves — glabātas pie pakalpojumu sniedzēja vai jūsu kodā. Glabājot tās kodā, tās ir versionētas un testējamas.
• Reģions un datu apstrāde, ja jums ir prasības par to, kur dati tiek apstrādāti.
• Izmaksas jūsu apjomā, ieskaitot to, kas notiek, kad pārsniedzat bezmaksas līmeni.

Saraksta sūtīšanai kādam sarakstam bieži labāk derēs īpašs jaunumu vēstuļu vai e-pasta mārketinga rīks, nevis kampaņu funkciju veidošana lietotnē.

Sūtīšanas domēna iestatīšana

Sūtiet no sava domēna — hello@example.com, nevis Gmail vai Outlook adreses. Pasts no bezmaksas adreses, kas sūtīts caur trešās puses pakalpojumu, neizturēs autentifikācijas pārbaudes un, visticamāk, tiks filtrēts.

Apsveriet apakšdomēnu tikai sūtīšanai. Piemēram, Resend iesaka sūtīt no apakšdomēniem, piemēram, updates.example.com, lai nodalītu sūtīšanas reputāciju (2026. gada septembrī). Tas arī tur e-pasta DNS ierakstus atsevišķi no jūsu galvenās vietnes.

Pakalpojumu sniedzējs pēc tam dod DNS ierakstus, kas jāpievieno tur, kur tiek pārvaldīts domēna DNS. Ja DNS jums ir jauns, kā darbojas domēni un DNS vispirms izskaidro ierakstus.

SPF

SPF (Sender Policy Framework) ir TXT ieraksts, kas uzskaita serverus, kuriem atļauts sūtīt e-pastu jūsu domēnam. Saņēmēji pārbauda, vai sūtītāja serveris ir sarakstā.

• Domēnam jābūt tikai vienam SPF ierakstam. Ja pievienojat pakalpojumu sniedzēju, apvienojiet to esošajā ierakstā, nevis pievienojiet otru.
• SPF novērtēšanā atļauti ne vairāk kā 10 DNS meklējumi; garas include: ķēdes var pārsniegt šo limitu un izraisīt kļūmes.
• Daudzi pakalpojumu sniedzēji iestata SPF apakšdomēnā, ko jūs izveidojat kā atgriešanās ceļu, tāpēc galveno SPF ierakstu var nemaz nemainīt.

DKIM

DKIM (DomainKeys Identified Mail) pievieno katram ziņojumam kriptogrāfisku parakstu. Pakalpojumu sniedzējs paraksta ar privāto atslēgu, un jūs publicējat atbilstošo publisko atslēgu kā DNS ierakstu (TXT vai CNAME atkarībā no pakalpojumu sniedzēja). Saņēmēji pārbauda parakstu, lai apstiprinātu, ka ziņojums nācis no pilnvarota sūtītāja un nav mainīts ceļā.

DKIM ir tas, par ko galvenokārt ir pakalpojumu sniedzēja solis „verify domain“. Neizlaidiet to.

DMARC

DMARC saista abus pārējos kopā. Tas ir TXT ieraksts domēna nosaukumā _dmarc.yourdomain.com, kas saņēmējiem saka:

• Atbilstību: domēnam redzamajā sūtītāja adresē jāsakrīt ar domēnu, kas izturēja SPF vai DKIM.
• Politiku: ko darīt ar ziņojumiem, kas neizturēja — p=none (tikai ziņot), p=quarantine (uzskatīt par aizdomīgu, bieži surogātpastu) vai p=reject.
• Pārskatiem: kur sūtīt apkopotos pārskatus (rua=), lai redzētu, kas sūta kā jūsu domēns.

Saprātīgs ceļš ir sākt ar p=none un pārskatu adresi, pārliecināties, ka jūsu likumīgais pasts izturas, tad pāriet uz quarantine un galu galā uz reject. Stingra politika arī ievērojami apgrūtina citu cilvēku iespējas viltot jūsu domēnu.

Ko prasa Gmail

No 2026. gada septembra Google sūtītāju vadlīnijas nosaka:

• Visiem sūtītājiem uz personiskiem Gmail kontiem vajag SPF vai DKIM, derīgu tiešo un atgriezenisko DNS sūtīšanas serveriem, TLS un surogātpasta līmeni zem 0,3% Postmaster Tools.
• Masveida sūtītājiem (vairāk nekā 5000 ziņojumu dienā uz Gmail) vajag SPF un DKIM, DMARC ierakstu (politika p=none ir atļauta), no-domēna atbilstību un atteikšanos ar vienu klikšķi, kā arī redzamu atteikšanās saiti mārketinga un abonētajos ziņojumos.

Jūsu pakalpojumu sniedzējs risina servera puses daļas. DNS ieraksti un atteikšanās apstrāde ir jūsu. Pat ja neesat tuvu 5000 dienā, masveida sūtītāju noteikumu izpilde ir vienkāršākais veids, kā būt drošam.

Sūtīšanas iebūvēšana lietotnē

Kad domēns ir verificēts:

1. Glabājiet API atslēgu kā servera puses noslēpumu — nekad priekšējā koda daļā. Skatiet kas ir vides mainīgie un noslēpumi.
2. Sūtiet no servera pēc tam, kad darbība, kas izraisa e-pastu, ir veiksmīga.
3. Neliekiet lietotājam gaidīt e-pastu. Jebkurai lietotnei, kas ir vairāk par vienkāršāko, ievietojiet sūtīšanu rindā un atkārtojiet pagaidu kļūmes, lai lēna pakalpojumu sniedzēja atbilde nepalēninātu reģistrāciju.
4. Reģistrējiet rezultātu — pakalpojumu sniedzēja ziņojuma ID un statusu —, bet nereģistrējiet atslēgu vai pilnus ziņojumu tekstus ar personas datiem.
5. Apstrādājiet webhook atsitumiem un sūdzībām: pārtrauciet sūtīt uz adresēm, kas stabili atsitas vai atzīmē jūs kā surogātpastu.

Uzvedne, kas aptver pamatus:

Sūtiet transakcijas e-pastu ar [PROVIDER], izmantojot servera noslēpumu [ENV_NAME], no „Acme hello@mail.acme.com“. Sūtiet laipni gaidītu e-pastu pēc reģistrācijas un rezervācijas apstiprinājumu pēc tam, kad rezervācija ir saglabāta. Glabājiet sagataves kodā ar teksta versiju līdzās HTML. Ievietojiet sūtīšanu rindā un atkārtojiet pagaidu kļūmes līdz trīs reizēm. Reģistrējiet kļūmes ar pakalpojumu sniedzēja kļūdu, bet nekad ar API atslēgu. Pievienojiet webhook galapunktu, kas atzīmē adreses kā nepiegādājamas stabilu atsitumu vai sūdzību gadījumā un turpmāk tās izlaiž.

Konta e-pasts — apstiprināšanas saites, pieteikšanās saites un paroļu atjaunošana — ir daļa no pieteikšanās. Kā lietotnei pievienot pieteikšanos aplūko, kā šīs plūsmas savienojas; padariet šīs saites vienreizējas un īslaicīgas.

Piegādes paradumi

Autentifikācija palīdz tikt ņemtiem vērā. Uzvedība notur jūs iesūtnē.

• Sūtiet tikai to, ko cilvēki sagaida. Apstiprinātas reģistrācijas, skaidra piekrišana mārketingam, nekādi pirkti saraksti.
• Padariet atteikšanos vienkāršu visam, kas nav stingri transakcijas, un ievērojiet to uzreiz.
• Sasildiet jaunus domēnus. Pilnīgi jauns domēns, kas pirmajā dienā sūta tūkstošiem ziņojumu, izskatās aizdomīgi. Sāciet ar transakcijas pastu un palieliniet apjomu pakāpeniski.
• Turiet sarakstus tīrus. Nekavējoties noņemiet stabilus atsitumus un apsveriet noņemt cilvēkus, kas ilgi nav neko atvēruši.
• Rakstiet kā cilvēks. Skaidrs temats, atpazīstams sūtītāja vārds, teksta daļa, maz attēlu un saites uz jūsu pašu domēnu. Izvairieties no saīsinātājiem saitēm.
• Uzraugiet. Reģistrējiet domēnu Google Postmaster Tools un laiku pa laikam lasiet DMARC pārskatus.
• Izmantojiet īstu atbildes adresi, ko kāds lasa. Atbildes ir labs signāls un noderīga atgriezeniskā saite.

Testēšana bez nevienas nosūtīšanas nepareizajiem

• Izmantojiet pakalpojumu sniedzēja testa režīmu vai smilškasti, ja tāds ir, vai sūtiet uz adresēm, kas pieder jums.
• Izstrādē sūtiet uz testa iesūtni, kas pieņem visu, nevis uz reāliem lietotājiem; datubāze ar reāliem izskatīgām adresēm ir viegls veids, kā nejauši nosūtīt e-pastu svešiniekiem.
• Pārbaudiet katru sagatavi dažos klientos — Gmail tīmekļa versijā, tālruņa pasta lietotnē, Outlook — un tumšajā režīmā.
• Apskatiet testa e-pasta galvenes: tajās redzams, vai SPF, DKIM un DMARC izturēja.

Juridiskie pamati

Noteikumi atšķiras pa valstīm. Vispārīgi, mārketinga e-pastam daudzviet vajag piekrišanu, jāidentificē sūtītājs un jāpiedāvā darboša atteikšanās; transakcijas e-pastu traktē citādi, bet to nevajadzētu izmantot, lai ieslīdzinātu mārketingu. Ja adreses ievācat no gaidīšanas saraksta lapas, pasakiet, ko un kad sūtīsiet un glabāsiet katram cilvēkam, kad un kā viņš pierakstījās. Šaubu gadījumā pārbaudiet noteikumus tajā vietā, kur ir jūsu lietotāji.

E-pasta kontrolsaraksts

• Sūtīšanas pakalpojums izvēlēts; API atslēga glabāta kā servera noslēpums
• Sūtīšana no sava domēna vai apakšdomēna, nevis bezmaksas pasta adreses
• SPF, DKIM un DMARC ieraksti pievienoti un izturēti
• Transakcijas un mārketinga pasts nodalīts
• Sūtīšana ievietota rindā un atkārtota; rezultāti reģistrēti
• Atsitumu un sūdzību webhook apstrādāti
• Atteikšanās ir ne-transakcijas pastā un tiek ievērota nekavējoties
• Sagataves pārbaudītas vairākos klientos; testa pasts nekad nesasniedz reālus lietotājus

E-pasta sūtīšana no Mythex lietotnes

Mythex nepiedāvā iebūvētu e-pasta sūtīšanas pakalpojumu lietotnēm, ko veidojat, tāpēc jums jāizmanto pakalpojumu sniedzējs, piemēram, Resend, SendGrid vai Postmark. Glabājiet tā API atslēgu kā projekta noslēpumu — aģents to var lūgt ar noslēpumu kartīti tērzēšanā — un pieprasiet nepieciešamos e-pastus vienkāršos vārdos. Sākuma uzvedne ir dokumentācijā: e-pasta sūtīšana no lietotnes. Ja domēnu iegādājāties caur Mythex Pro versijā, varat pievienot pakalpojumu sniedzēja TXT un CNAME ierakstus domēna DNS iestatījumos; skatiet pielāgotos domēnus.

Jautājumi