Kako slati emailove iz aplikacije (i stizati u inbox)

Da biste slali emailove iz aplikacije pouzdano, koristite provajdera za slanje emaila umesto sopstvenog poštanskog sandučeta, šaljite sa adrese na svom domenu i dodajte DNS zapise koje vam provajder da, tako da SPF, DKIM i DMARC svi prolaze. Transakcione poruke, kao što su resetovanje lozinke, računi i potvrde, držite odvojeno od marketing poruka, šaljite svaku samo ljudima koji je očekuju i obrađujte odbijene adrese i odjave. Autentifikaciju prvo postavite kako treba, jer je to najčešći razlog zašto emailovi aplikacije završavaju u spamu.

Transakcioni i marketing email

Ova dva tipa emaila izgledaju slično u kodu, ali ih inbox provajderi i zakon tretiraju vrlo različito.

Držite ih odvojeno. Ako marketing kampanja dobija prijave za spam, ne želite da zbog toga pate resetovanja lozinke poslata iz istog toka. Čest pristup je odvojeni poddomeni, na primer mail.example.com za naloge i news.example.com za newsletter. Neki provajderi takođe interno razdvajaju ova dva tipa. Postmark, na primer, opisuje svoje transakcione i broadcast „message streams“ kao infrastrukturu za slanje koja je odvojena, od septembra 2026.

Izbor provajdera

Aplikacija ne bi trebalo da šalje emailove sa sopstvenog servera. Provajderi za slanje brinu o infrastrukturi, reputaciji IP adresa, ponovnim pokušajima i obradi odbijenih poruka. Poznate opcije su Postmark, Resend, SendGrid, Amazon SES i Mailgun. Svaka ima HTTP API i SMTP pristup. Cene i planovi se menjaju, pa ih uporedite na njihovim sajtovima.

Šta da uporedite:

• Fokus. Neki provajderi se bave isključivo transakcionim emailom, a neki kombinuju transakcione i marketing poruke.
• Iskustvo za programere. Jasan API, zvanične biblioteke za vaš jezik i korisni logovi koji pokazuju da li je poruka isporučena, odbijena ili označena kao spam.
• Webhook-ovi za odbijene adrese, prijave i isporuke, da bi aplikacija mogla da reaguje.
• Šabloni, sačuvani kod provajdera ili u vašem kodu. Ako ih držite u kodu, mogu da se verzionišu i testiraju.
• Region i obrada podataka, ako imate zahteve o tome gde se podaci obrađuju.
• Cena pri vašem obimu, uključujući šta se dešava kad pređete besplatni nivo.

Za newsletter prema listi često bolje odgovara namenski alat za newsletter ili email marketing nego ugrađivanje kampanja u samu aplikaciju.

Podešavanje domena za slanje

Šaljite sa sopstvenog domena, na primer hello@example.com, a ne sa Gmail ili Outlook adrese. Pošta sa besplatne adrese poslata preko servisa treće strane ne prolazi provere autentifikacije i verovatno će biti filtrirana.

Razmislite o poddomenu namenjenom samo slanju. Resend, na primer, preporučuje slanje sa poddomena poput updates.example.com da bi se reputacija slanja izolovala (od septembra 2026). Tako DNS zapisi za email ostaju odvojeni od zapisa vašeg glavnog sajta.

Provajder će vam zatim dati DNS zapise koje dodajete tamo gde se upravlja DNS-om vašeg domena. Ako vam je DNS nov, kako rade domeni i DNS objašnjava zapise iz početka.

SPF

SPF (Sender Policy Framework) je TXT zapis koji navodi koji serveri smeju da šalju email za vaš domen. Primaoci proveravaju da li je server pošiljaoca na toj listi.

• Domen treba da ima samo jedan SPF zapis. Ako dodajete provajdera, spojite ga u postojeći zapis, a ne dodajte drugi.
• Pri proveri SPF dozvoljava najviše 10 DNS upita. Dugi lanci include: unosa mogu da pređu tu granicu i izazovu greške.
• Mnogi provajderi postavljaju SPF na return-path poddomenu koji vas traže da napravite, tako da glavni SPF zapis možda uopšte nećete menjati.

DKIM

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

DKIM je uglavnom ono što provajderov korak „verify domain“ proverava. Ne preskačite ga.

DMARC

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

• Poravnanje: domen u vidljivoj From adresi mora da se poklapa sa domenom koji je prošao SPF ili DKIM proveru.
• Politiku: šta da rade sa neispravnom poštom. p=none samo prijavljuje, p=quarantine tretira poruku kao sumnjivu, često kao spam, a p=reject je odbija.
• Izveštaje: gde da šalju zbirne izveštaje (rua=), da biste videli ko šalje u ime vašeg domena.

Razumna putanja je da počnete sa p=none i adresom za izveštaje, potvrdite da vaša legitimna pošta prolazi, pa pređete na quarantine, a na kraju na reject. Stroga politika takođe znatno otežava da drugi lažno predstavljaju vaš domen.

Šta traži Gmail

Od septembra 2026. Googleova pravila za pošiljaoce kažu:

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

Provajder obrađuje serverske delove. DNS zapise i odjavu obrađujete vi. Čak i ako ne šaljete ni blizu 5.000 dnevno, ispunjavanje pravila za masovne pošiljaoce je najjednostavniji način da budete sigurni.

Ugradnja slanja u aplikaciju

Kada je domen potvrđen:

1. Sačuvajte API ključ kao tajnu na serveru, nikada u kodu na frontu. Pogledajte šta su environment varijable i tajne.
2. Šaljite sa servera, nakon što radnja koja okida email uspe.
3. Ne terajte korisnika da čeka email. Za sve osim najjednostavnije aplikacije stavite slanje u red i ponovo pokušajte pri privremenim greškama, da spor odgovor provajdera ne uspori registraciju.
4. Beležite ishod: ID poruke i status od provajdera, bez beleženja ključa ili celog sadržaja poruke ako sadrži lične podatke.
5. Obradite webhook-ove za odbijene adrese i prijave: prestanite da šaljete na adrese koje trajno odbijaju poštu ili vas prijavljuju kao spam.

Prompt koji pokriva osnove:

Pošalji transakcioni email preko [PROVAJDER] koristeći serversku tajnu [ENV_NAME], sa adrese „Acme hello@mail.acme.com“. Pošalji dobrodošlicu posle registracije i potvrdu rezervacije kada se rezervacija sačuva. Šablone čuvaj u kodu, uz verziju u običnom tekstu uz HTML. Stavi slanje u red i ponovo pokušaj privremene greške do tri puta. Beleži greške sa provajderovom porukom, ali nikada ključ. Dodaj webhook endpoint koji označava adrese kao neisporučive pri trajnim odbijanjima i prijavama, i preskače te adrese u budućnosti.

Emailovi za nalog, kao što su linkovi za verifikaciju, magic linkovi i resetovanje lozinke, deo su prijave. Kako dodati prijavu u aplikaciju objašnjava kako se ti tokovi uklapaju; neka ovi linkovi budu jednokratni i kratkotrajni.

Navike za isporuku

Autentifikacija vam obezbeđuje da vas uzmu u obzir. Ponašanje vas održava u inboxu.

• Šaljite samo ono što ljudi očekuju. Potvrđene registracije, jasan pristanak za marketing, bez kupljenih lista.
• Učinite odjavu lakom za sve što nije strogo transakciono i poštujte je odmah.
• Zagrejte nove domene. Potpuno nov domen koji prvog dana šalje hiljade poruka deluje sumnjivo. Počnite sa transakcionom poštom i postepeno povećavajte obim.
• Držite liste čistim. Odmah uklanjajte trajno odbijene adrese i razmislite o uklanjanju onih koji dugo ništa nisu otvorili.
• Pišite kao čovek. Jasan naslov, prepoznatljivo ime pošiljaoca, deo u običnom tekstu, malo slika i linkovi ka vašem domenu. Izbegavajte skraćivače linkova.
• Pratite. Registrujte domen u Google Postmaster Tools i povremeno čitajte DMARC izveštaje.
• Koristite stvarnu adresu za odgovor koju neko čita. Odgovori su dobar signal i koristan izvor povratnih informacija.

Testiranje bez slanja spama ikome

• Koristite test režim ili sandbox provajdera ako ga ima, ili šaljite na adrese koje sami posedujete.
• Tokom razvoja šaljite na test inbox koji hvata sve poruke umesto na prave korisnike. Baza sa lažnim podacima koji izgledaju kao pravi adrese lak je način da slučajno pošaljete email nepoznatim ljudima.
• Proverite svaki šablon u nekoliko klijenata: Gmail u pregledaču, mail aplikaciju na telefonu, Outlook i tamnu temu.
• Pogledajte zaglavlja test emaila: pokazuju da li su SPF, DKIM i DMARC prošli.

Pravne osnove

Pravila se razlikuju od zemlje do zemlje. Uopšteno, marketing email u mnogim mestima zahteva pristanak, mora da identifikuje pošiljaoca i mora da nudi funkcionalnu odjavu. Transakcioni email se tretira drugačije, ali ne sme da se koristi za ubacivanje marketinga. Ako prikupljate adrese sa stranice za listu čekanja, recite šta ćete slati i čuvati i kada i kako se svaka osoba prijavila. Kada niste sigurni, proverite pravila tamo gde su vaši korisnici.

Checklista za email

• Provajder za slanje izabran; API ključ sačuvan kao serverska tajna
• Slanje sa sopstvenog domena ili poddomena, a ne sa besplatne adrese
• SPF, DKIM i DMARC zapisi dodati i prolaze
• Transakciona i marketing pošta odvojeni
• Slanja stavljena u red i ponovo pokušavana; ishodi zabeleženi
• Webhook-ovi za odbijanja i prijave obrađeni
• Odjava u netransakcionoj pošti, poštovana odmah
• Šabloni testirani u nekoliko klijenata; test pošta nikada ne stiže pravim korisnicima

Slanje emaila iz Mythex aplikacije

Mythex ne uključuje ugrađenu uslugu za slanje emaila za aplikacije koje gradite, zato donosite provajdera, na primer Resend, SendGrid ili Postmark. Njegov API ključ sačuvajte kao tajnu projekta. Agent može da zatraži karticu sa tajnama u chatu. Emailove koji su vam potrebni zatražite običnim rečima. Početni prompt imate u dokumentaciji u slanju emaila iz aplikacije. Ako ste domen kupili preko Mythex-a na Pro planu, TXT i CNAME zapise provajdera možete dodati u podešavanjima DNS-a domena; pogledajte prilagođene domene.

Pitanja