Kako pošiljati e-pošto iz svoje aplikacije (in pristati v nabiralniku)

Da bi e-pošto iz aplikacije zanesljivo pošiljali, uporabite ponudnika za pošiljanje e-pošte in ne svojega poštnega predala, pošiljajte z naslova na svoji domeni ter dodajte DNS zapise, ki vam jih da ponudnik, da bodo SPF, DKIM in DMARC vsi uspešno preverjeni. Transakcijsko e-pošto – ponastavitve gesel, račune, potrditve – ločite od tržne, vsako pošiljajte samo ljudem, ki to pričakujejo, in urejajte odjave ter nedostavljena sporočila. Najprej uredite preverjanje avtentičnosti; to je najpogostejši razlog, da e-pošta aplikacij konča v neželeni pošti.

Transakcijska proti tržni e-pošti

Ti dve vrsti e-pošte se v kodi lahko podobno pošiljata, vendar ju ponudniki nabiralnikov in zakon obravnavajo zelo različno.

Loči ju. Če tržna kampanja sproži pritožbe o neželeni pošti, ne želite, da trpijo ponastavitve gesel iz istega toka. Pogost pristop so ločene poddomene – na primer mail.example.com za račune in news.example.com za glasila; nekateri ponudniki ločujejo oba tokova tudi notranje. Postmark na primer opisuje, da njegova transakcijska in oddajna »sporočilna tokova« tečeta po ločeni infrastrukturi za pošiljanje (stanje septembra 2026).

Izbira ponudnika

Vaša aplikacija ne bi smela sama pošiljati e-pošte s svojega strežnika. Ponudniki za pošiljanje poskrbijo za infrastrukturo, ugled IP-naslovov, ponovne poskuse in obdelavo nedostavljenih sporočil. Znani ponudniki so Postmark, Resend, SendGrid, Amazon SES in Mailgun; vsi imajo HTTP API in dostop prek SMTP, cene in paketi pa se spreminjajo, zato jih primerjajte na njihovih spletnih straneh.

Kaj primerjati:

• Osredotočenost. Nekateri ponudniki se posvečajo transakcijski e-pošti, drugi združujejo transakcijsko in tržno.
• Izkušnja razvijalca. Jasen API, uradne knjižnice za vaš jezik, uporabni dnevniki, ki pokažejo, ali je bilo sporočilo dostavljeno, zavrnjeno ali označeno kot neželena pošta.
• Webhooki za nedostavljena sporočila, pritožbe in dostave, da se lahko aplikacija odzove.
• Predloge – shranjene pri ponudniku ali v vaši kodi. Če so v kodi, so različice in jih je mogoče testirati.
• Regija in ravnanje s podatki, če imate zahteve glede tega, kje se podatki obdelujejo.
• Strošek pri vašem obsegu, vključno s tem, kaj se zgodi, ko presežete brezplačni paket.

Za glasila na seznam je pogosto boljša namenska orodja za glasila ali e-poštni marketing kot gradnja funkcij kampanj v sami aplikaciji.

Nastavitev pošiljateljske domene

Pošiljajte z lastne domene – hello@example.com, ne z naslova Gmail ali Outlook. Pošta z brezplačnega poštnega naslova, poslana prek storitve tretje osebe, ne prestane preverjanj avtentičnosti in je verjetno filtrirana.

Razmislite o poddomeni samo za pošiljanje. Resend na primer priporoča pošiljanje s poddomen, kot je updates.example.com, da se ugled pošiljanja izolira (stanje septembra 2026). Hkrati so DNS zapisi za e-pošto ločeni od zapisov vaše glavne spletne strani.

Ponudnik vam nato da DNS zapise, ki jih dodate tam, kjer se upravlja DNS vaše domene. Če vam je DNS nov, vam kako delujejo domene in DNS najprej razloži zapise.

SPF

SPF (Sender Policy Framework) je TXT zapis, ki našteva strežnike, smejo pošiljati e-pošto za vašo domeno. Prejemniki preverijo, ali je pošiljajoči strežnik na seznamu.

• Domena naj ima samo en SPF zapis. Če dodate ponudnika, ga združite v obstoječi zapis in ne dodajte drugega.
• SPF pri vrednotenju dovoli največ 10 DNS poizvedb; dolge verige vnosov include: lahko presežejo to mejo in povzročijo napake.
• Mnogi ponudniki nastavijo SPF na poddomeni za povratno pot, ki jo zahtevajo, zato glavnega SPF zapisa morda sploh ne boste spreminjali.

DKIM

DKIM (DomainKeys Identified Mail) doda kriptografski podpis vsakemu sporočilu. Ponudnik podpisuje z zasebnim ključem, vi pa objavite ustrezni javni ključ kot DNS zapis (TXT ali CNAME, odvisno od ponudnika). Prejemniki preverijo podpis in tako potrdijo, da je sporočilo prišlo od pooblaščenega pošiljatelja in ni bilo med potjo spremenjeno.

DKIM je večinoma tisto, za kar gre pri koraku »preveri domeno« pri ponudniku. Ne preskočite ga.

DMARC

DMARC poveže druga dva. Gre za TXT zapis na _dmarc.yourdomain.com, ki prejemnikom sporoča:

• Poravnavo: domena v vidnem naslovu »Od« se mora ujemati z domeno, ki je prestala SPF ali DKIM.
• Politiko: kaj storiti s sporočili, ki ne uspejo – p=none (samo poročaj), p=quarantine (obravnavaj kot sumljivo, pogosto neželeno) ali p=reject (zavrni).
• Poročila: kam poslati skupna poročila (rua=), da vidite, kdo pošilja v vašem imenu.

Smiselna pot je začeti s p=none in naslovom za poročila, potrditi, da legitimna pošta uspe, nato preiti na quarantine in nazadnje na reject. Strožja politika tudi precej oteži ponarejanje vaše domene.

Kaj zahteva Gmail

Od septembra 2026 pravila Googlovih pošiljateljev pravijo:

• Vsi pošiljatelji na osebne Gmail naslove potrebujejo SPF ali DKIM, veljaven obratni in direktni DNS za pošiljajoče strežnike, TLS ter stopnjo neželene pošte v Postmaster Tools pod 0,3 %.
• Množični pošiljatelji (več kot 5.000 sporočil na dan na Gmail) potrebujejo SPF in DKIM, DMARC zapis (politika p=none je dovoljena), poravnavo domene »Od« ter enoklično odjavo in vidno povezavo za odjavo v tržnih in naročenih sporočilih.

Vaš ponudnik opravi strežniške dele. DNS zapisi in ravnanje z odjavami sta vaša. Tudi če daleč niste pri 5.000 na dan, je izpolnjevanje pravil za množične pošiljatelje najpreprostejši način, da ste varni.

Vgradnja pošiljanja v aplikacijo

Ko je domena preverjena:

1. Shranite API ključ kot skrivnost na strežniku – nikoli v kodi na strani odjemalca. Glejte kaj so okoljske spremenljivke in skrivnosti.
2. Pošiljajte s strežnika, potem ko je dejanje, ki sproži e-pošto, uspešno.
3. Ne pustite uporabnika čakati na e-pošto. Pri vsaki aplikaciji, ki presega najpreprostejšo, sporočila damo v čakalno vrsto in pri začasnih napakah poskusimo znova, tako da počasen odgovor ponudnika ne upočasni registracije.
4. Beležite izid – ID sporočila pri ponudniku in stanje –, vendar brez ključa in brez celotnih vsebin sporočil z osebnimi podatki.
5. Obravnavajte webhooke za nedostavljena sporočila in pritožbe. Nehajte pošiljati na naslove, ki trdo odpovejo ali vas označijo kot neželeno pošto.

Poziv, ki pokrije osnove:

Pošiljaj transakcijsko e-pošto prek [PONUDNIK] z uporabo strežniške skrivnosti [ENV_IME], od "Acme hello@mail.acme.com". Po registraciji pošlji dobrodošlico, po shranjeni rezervaciji pa potrditev rezervacije. Predloge hrani v kodi, z golobesedilno različico poleg HTML-ja. Pošiljanje postavi v čakalno vrsto in pri začasnih napakah poskusi do trikrat. Napake beleži s ponudnikovo napako, nikoli pa s API ključem. Dodaj webhook končno točko, ki označi naslove kot nedostavljive ob trdih odbojih in pritožbah, ter jih v prihodnje preskoči.

E-pošta za račun – potrditvene povezave, magične povezave in ponastavitve gesel – je del prijave. Kako dodati prijavo v aplikacijo pojasni, kako se ti tokovi povezujejo; te povezave naj bodo enkratne in kratkotrajne.

Navade za dostavljivost

Preverjanje avtentičnosti vam zagotovi, da vas sploh upoštevajo. Vedenje vas obdrži v nabiralniku.

• Pošiljajte samo to, kar ljudje pričakujejo. Potrjene registracije, jasno soglasje za tržna sporočila, brez kupljenih seznamov.
• Odjava naj bo enostavna pri vsem, kar ni strogo transakcijsko, in naj deluje takoj.
• Segrevajte nove domene. Nova domena, ki na prvi dan pošlje tisoče sporočil, deluje sumljivo. Začnite s transakcijsko pošto in obseg povečujte postopoma.
• Čistite sezname. Trde odboje takoj odstranite; razmislite tudi o odstranitvi ljudi, ki dolgo ničesar niso odprli.
• Pišite kot človek. Jasen zadevek, prepoznavno ime pošiljatelja, golobesedilni del, malo slik in povezav na vašo domeno. Izogibajte se skrajševalnikom povezav.
• Spremljajte. Domeno registrirajte v Google Postmaster Tools in občasno preberite poročila DMARC.
• Uporabite pravi naslov za odgovore, ki ga nekdo dejansko bere. Odgovori so dober signal in koristna povratna informacija.

Testiranje brez pošiljanja neželene pošte komurkoli

• Uporabite testni način ali peskovnik ponudnika, kjer ga ima, ali pošiljajte na naslove, ki so vaši.
• V razvoju pošiljajte na testni nabiralnik, ki sprejme vse, ne pravim uporabnikom; baza s prepričljivimi naslovi je zanesljiv način, da nehote pišete tujcem.
• Vsako predlogo preglejte v več odjemalcih – Gmail v brskalniku, aplikacija za pošto na telefonu, Outlook – in v temnem načinu.
• Oglejte si glave sporočila testne e-pošte: pokažejo, ali so SPF, DKIM in DMARC uspeli.

Pravne osnove

Pravila se po državah razlikujejo. Na splošno tržna e-pošta v mnogih krajih zahteva soglasje, mora navesti pošiljatelja in ponuditi delujočo odjavo; transakcijska e-pošta je obravnavana drugače, vendar je ne smete uporabiti za skrito pošiljanje trženja. Če zbirate naslove prek strani s čakalnim seznamom, povejte, kaj in kdaj boste pošiljali ter kako in kdaj je vsak človek ob prijavi dal soglasje. Če niste prepričani, preverite pravila tam, kjer so vaši uporabniki.

Kontrolni seznam za e-pošto

• Ponudnik za pošiljanje izbran; API ključ shranjen kot skrivnost na strežniku
• Pošiljanje z lastne domene ali poddomene, ne z brezplačnega poštnega naslova
• Dodani in uspešno preverjeni zapisi SPF, DKIM in DMARC
• Transakcijska in tržna pošta ločeni
• Pošiljanja v čakalni vrsti, ponovni poskusi, izidi zabeleženi
• Webhooki za nedostavljena sporočila in pritožbe obravnavani
• Odjava pri netransakcijski pošti, takoj upoštevana
• Predloge preizkušene v več odjemalcih; testna pošta nikoli ne doseže pravih uporabnikov

Pošiljanje e-pošte iz aplikacije Mythex

Mythex za aplikacije, ki jih gradite, ne vključuje vgrajene storitve za pošiljanje e-pošte, zato prinesete ponudnika, na primer Resend, SendGrid ali Postmark. API ključ shranite kot projektno skrivnost – agent ga lahko zahteva s kartico za skrivnosti v klepetu – in v običajnih besedah zahtevajte e-pošto, ki jo potrebujete. Začetni poziv je v dokumentaciji v članku pošiljanje e-pošte iz aplikacije. Če ste domeno kupili prek Mythexa na načrtu Pro, lahko TXT in CNAME zapise ponudnika dodate v nastavitvah DNS za domeno; glejte domene po meri.

Vprašanja