Kako slati e-poštu iz vaše aplikacije (i stići u inbox)

Da biste pouzdano slali e-poštu iz aplikacije, koristite provajdera za slanje e-pošte umjesto vlastitog poštanskog sandučića, šaljite s adrese na vlastitom domenu i dodajte DNS zapise koje vam provajder daje, tako da SPF, DKIM i DMARC svi prolaze. Držite transakcionu e-poštu — resetovanje lozinke, račune, potvrde — odvojeno od marketinške, šaljite svaku samo ljudima koji je očekuju i obrađujte povratne poruke (bounce) i odjave. Prvo postavite autentifikaciju kako treba; to je najčešći razlog zašto e-pošta aplikacije završi u spamu.

Transakciona i marketinška e-pošta

Ove dvije vrste e-pošte u kodu izgledaju slično, ali ih provajderi inboksa i zakon tretiraju vrlo različito.

Držite ih odvojeno. Ako marketinška kampanja dobije prijave za spam, ne želite da zbog toga pate resetovanja lozinke iz istog toka. Čest pristup su odvojene poddomene — na primjer mail.example.com za e-poštu računa i news.example.com za newslettere — a neki provajderi ih interno razdvajaju. Postmark, na primjer, navodi da njegovi transakcioni i broadcast „message streams“ rade na odvojenoj infrastrukturi za slanje (stanje na septembar 2026).

Izbor provajdera

Vaša aplikacija ne bi trebala sama slati e-poštu sa svog servera. Provajderi za slanje brinu o infrastrukturi, reputaciji IP adresa, ponovnim pokušajima i obradi povratnih poruka. Poznate opcije su Postmark, Resend, SendGrid, Amazon SES i Mailgun; svaka ima HTTP API i SMTP pristup, a cijene i planovi se mijenjaju, zato ih uporedite na njihovim sajtovima.

Šta uporediti:

• Fokus. Neki provajderi se fokusiraju na transakcionu e-poštu; drugi kombinuju transakcionu i marketinšku.
• Iskustvo za developere. Jasan API, zvanične biblioteke za vaš jezik, korisni logovi koji pokazuju da li je svaka poruka isporučena, vraćena ili označena kao spam.
• Webhook-ovi za povratne poruke, prijave i isporuke, kako bi aplikacija mogla reagovati.
• Šabloni — čuvani kod provajdera ili u vašem kodu. Držanje u kodu ih čini verzionisanim i testabilnim.
• Region i obrada podataka, ako imate zahtjeve o tome gdje se podaci obrađuju.
• Trošak pri vašem obimu, uključujući šta se dešava kada premašite besplatni nivo.

Za newslettere na listi, namjenski alat za newsletter ili e-mail marketing često je bolji izbor nego da kampanje gradite unutar same aplikacije.

Podesite domen za slanje

Šaljite s vlastitog domena — hello@example.com, a ne s Gmail ili Outlook adrese. Pošta s besplatne adrese poslana preko servisa treće strane ne prolazi provjere autentifikacije i vjerovatno će biti filtrirana.

Razmislite o poddomeni samo za slanje. Resend, na primjer, preporučuje slanje s poddomena poput updates.example.com kako bi se izolovala reputacija slanja (stanje na septembar 2026). Time se i DNS zapisi za e-poštu drže odvojeno od vaše glavne stranice.

Provajder vam zatim daje DNS zapise koje treba dodati tamo gdje se upravlja DNS-om vašeg domena. Ako vam je DNS nova tema, kako funkcionišu domene i DNS najprije objašnjava zapise.

SPF

SPF (Sender Policy Framework) je TXT zapis koji navodi koji serveri smiju slati e-poštu za vaš domen. Primaoci provjeravaju da li je server pošiljaoca na listi.

• Domen bi trebao imati samo jedan SPF zapis. Ako dodajete provajdera, spojite ga u postojeći zapis umjesto da dodajete drugi.
• SPF pri evaluaciji dopušta najviše 10 DNS upita; duži nizovi include: unosa mogu to premašiti i izazvati greške.
• Mnogi provajderi postavljaju SPF na return-path poddomeni koji vas traže da napravite, pa možda uopšte nećete dirati glavni SPF zapis.

DKIM

DKIM (DomainKeys Identified Mail) dodaje kriptografski potpis svakoj poruci. Provajder potpisuje privatnim ključem; vi objavljujete odgovarajući javni ključ kao DNS zapis (TXT ili CNAME, zavisno od provajdera). Primaoci provjeravaju potpis kako bi potvrdili da je poruku poslao ovlašćeni pošiljalac i da nije promijenjena na putu.

Korak „verify domain“ kod provajdera uglavnom se odnosi upravo na DKIM. Nemojte ga preskočiti.

DMARC

DMARC povezuje ostala dva. To je TXT zapis na _dmarc.yourdomain.com koji primaocima govori:

• Poravnanje: domen u vidljivoj adresi pošiljaoca (From) mora se podudarati s domenom koji je prošao SPF ili DKIM.
• Politika: šta raditi s porukama koje ne prolaze — p=none (samo prijavi), p=quarantine (tretiraj kao sumnjivu, često spam) ili p=reject.
• Izvještaji: kamo slati zbirne izvještaje (rua=), kako biste vidjeli ko šalje u vaše ime s domena.

Razuman put je početi s p=none i adresom za izvještaje, potvrditi da vaša legitimna pošta prolazi, zatim preći na quarantine i na kraju na reject. Stroga politika također znatno otežava drugima lažiranje vašeg domena.

Šta Gmail zahtijeva

Od septembra 2026. Googleove smjernice za pošiljaoce kažu:

• Svi pošiljaoci na lične Gmail naloge trebaju SPF ili DKIM, ispravan forward i reverse DNS za servere koji šalju, TLS i stopu spama ispod 0,3% u Postmaster Tools.
• Masovni pošiljaoci (više od 5.000 poruka dnevno na Gmail) trebaju SPF i DKIM, DMARC zapis (dozvoljena je politika p=none), poravnanje From domena, te odjavu jednim klikom plus vidljiv link za odjavu u marketinškim i porukama s pretplate.

Vaš provajder se brine o serverskim dijelovima. DNS zapise i obradu odjava radite vi. Čak i ako ste daleko od 5.000 dnevno, ispunjavanje pravila za masovne pošiljaoce je najjednostavniji način da budete na sigurnoj strani.

Ugradite slanje u aplikaciju

Kada je domen potvrđen:

1. Sačuvajte API ključ kao tajnu na serveru — nikada u front-end kodu. Pogledajte šta su varijable okruženja i tajne.
2. Šaljite sa servera, nakon što radnja koja pokreće e-poštu uspije.
3. Ne tjerajte korisnika da čeka e-poštu. Za sve osim najjednostavnije aplikacije, stavite slanje u red čekanja i ponovite pokušaj kod privremenih grešaka, kako spor odgovor provajdera ne bi usporio registraciju.
4. Zabilježite ishod — ID poruke i status kod provajdera — bez bilježenja ključa ili punog sadržaja poruka koje sadrže lične podatke.
5. Obradite webhook-ove za povratne poruke i prijave: prestanite slati na adrese koje trajno ne prolaze ili su vas prijavile kao spam.

Prompt koji pokriva osnove:

Pošalji transakcionu e-poštu preko [PROVAJDER] koristeći serversku tajnu [ENV_NAME], s adrese „Acme hello@mail.acme.com“. Pošalji dobrodošlicu nakon registracije i potvrdu rezervacije nakon što se rezervacija sačuva. Čuvaj šablone u kodu, uz tekstualnu verziju pored HTML-a. Stavi slanje u red čekanja i ponovi privremene greške do tri puta. Bilježi greške s porukom provajdera, ali nikada API ključ. Dodaj webhook krajnju tačku koja označava adrese kao neisporučive kod trajnih povrata i prijava spama i preskače te adrese ubuduće.

E-pošta računa — linkovi za verifikaciju, magic linkovi i resetovanje lozinke — dio je prijave. Kako dodati prijavu u svoju aplikaciju objašnjava kako se ti tokovi uklapaju; neka ovi linkovi budu jednokratni i kratkotrajni.

Navike za isporučivost

Autentifikacija vam omogućava da uopšte budete razmatrani. Ponašanje vas održava u inboksu.

• Šaljite samo ono što ljudi očekuju. Potvrđene registracije, jasna saglasnost za marketing, bez kupljenih lista.
• Učinite odjavu jednostavnom za sve što nije strogo transakciono i odmah je poštujte.
• Zagrijte nove domene. Potpuno nov domen koji prvog dana šalje hiljade poruka izgleda sumnjivo. Počnite s transakcionom poštom i postepeno povećavajte obim.
• Držite liste čistim. Odmah uklonite trajne povrate i razmislite o uklanjanju ljudi koji dugo ništa nisu otvorili.
• Pišite kao čovjek. Jasan naslov, prepoznatljivo ime pošiljaoca, tekstualni dio, malo slika i linkovi na vaš domen. Izbjegavajte skraćivače linkova.
• Pratite. Registrujte domen u Google Postmaster Tools i povremeno čitajte DMARC izvještaje.
• Koristite pravu adresu za odgovor koju neko čita. Odgovori su dobar signal i koristan povratni podatak.

Testiranje bez slanja spama nekome

• Koristite test način rada ili sandbox vašeg provajdera tamo gdje postoji, ili šaljite na adrese koje vi posjedujete.
• U razvoju šaljite na testni catch-all inbox umjesto na prave korisnike; baza podataka s realno izgledajućim adresama lak je način da se slučajno pošalje e-pošta nepoznatim ljudima.
• Provjerite svaki šablon u nekoliko klijenata — Gmail na webu, aplikacija za poštu na telefonu, Outlook — i u tamnom režimu.
• Pogledajte zaglavlja test poruke: pokazuju da li su SPF, DKIM i DMARC prošli.

Pravne osnove

Pravila se razlikuju od države do države. Uopšteno, marketinška e-pošta u mnogim mjestima zahtijeva saglasnost, mora identifikovati pošiljaoca i mora nuditi funkcionalnu odjavu; transakciona e-pošta se tretira drugačije, ali se ne bi smjela koristiti da se ubaci marketing. Ako prikupljate adrese preko stranice za listu čekanja, recite šta ćete slati i čuvati, te kada i kako se svaka osoba prijavila. Kada niste sigurni, provjerite pravila tamo gdje su vaši korisnici.

Kontrolna lista za e-poštu

• Izabran provajder za slanje; API ključ sačuvan kao serverska tajna
• Slanje s vlastitog domena ili poddomene, a ne s besplatne adrese
• Dodani SPF, DKIM i DMARC zapisi i prolaze
• Transakciona i marketinška pošta odvojene
• Slanja stavljena u red čekanja i ponovljena; ishodi zabilježeni
• Webhook-ovi za povratne poruke i prijave obrađeni
• Odjava u netransakcionoj pošti, odmah poštovana
• Šabloni testirani u više klijenata; test pošta nikada ne dopire do pravih korisnika

Slanje e-pošte iz Mythex aplikacije

Mythex ne uključuje ugrađenu uslugu slanja e-pošte za aplikacije koje gradite, zato donosite provajdera poput Resend, SendGrid ili Postmark. Sačuvajte njegov API ključ kao tajnu projekta — agent može tražiti da ga unesete preko kartice s tajnama u chatu — i tražite e-poruke koje su vam potrebne običnim riječima. Dokumentacija ima početni prompt u slanje e-pošte iz vaše aplikacije. Ako ste domen kupili preko Mythexa na Pro planu, TXT i CNAME zapise provajdera možete dodati u DNS postavkama domena; pogledajte prilagođene domene.

Pitanja