Kako slati e-poštu iz svoje aplikacije (i da stigne u inbox)

Da biste pouzdano slali e-poštu iz aplikacije, koristite pružatelja usluge slanja e-pošte umjesto vlastitog poštanskog sandučića, šaljite s adrese na vlastitoj domeni i dodajte DNS zapise koje pružatelj daje tako da SPF, DKIM i DMARC svi prolaze. Držite transakcijsku e-poštu — poništavanje lozinki, račune, potvrde — odvojeno od marketinške, šaljite svaku samo ljudima koji je očekuju i obrađujte odbijene poruke i odjave. Prvo postavite autentikaciju; to je najčešći razlog zbog kojeg e-pošta aplikacije završava u neželjenoj pošti.

Transakcijska i marketinška e-pošta

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

Držite ih odvojeno. Ako marketinška kampanja dobije prijave za spam, ne želite da zbog toga pate poruke za poništavanje lozinke iz istog toka. Čest pristup su odvojene poddomene — na primjer mail.example.com za račune i news.example.com za newslettere — a neki pružatelji ih interno također razdvajaju. Postmark, primjerice, opisuje svoje transakcijske i emisijske "tokove poruka" kao one koji rade na zasebnoj infrastrukturi za slanje (od rujna 2026.).

Odabir pružatelja

Vaša aplikacija ne bi trebala sama slati e-poštu sa svog poslužitelja. Pružatelji usluga slanja brinu o infrastrukturi, reputaciji IP adresa, ponovnim pokušajima i obradi odbijenih poruka. Poznate opcije uključuju Postmark, Resend, SendGrid, Amazon SES i Mailgun; svaka ima HTTP API i SMTP pristup, a cijene i planovi se mijenjaju, pa ih usporedite na njihovim stranicama.

Što usporediti:

• Fokus. Neki pružatelji se koncentriraju na transakcijsku e-poštu, drugi kombiniraju transakcijsku i marketinšku.
• Iskustvo za programere. Jasan API, službene biblioteke za vaš jezik, korisni dnevnici koji pokazuju je li svaka poruka isporučena, odbijena ili označena kao spam.
• Webhookovi za odbijene poruke, prijave i isporuke, kako bi aplikacija mogla reagirati.
• Predlošci — pohranjeni kod pružatelja ili u vašem kodu. Ako su u kodu, mogu se verzionirati i testirati.
• Regija i obrada podataka, ako imate zahtjeve o tome gdje se podaci obrađuju.
• Trošak pri vašem obujmu, uključujući što se događa kada premašite besplatni plan.

Za newslettere popisu često je bolji izbor namjenski alat za newslettere ili e-mail marketing nego ugrađivanje kampanja u vašu aplikaciju.

Postavite domenu za slanje

Šaljite s vlastite domene — hello@example.com, a ne s Gmail ili Outlook adrese. Pošta s besplatne adrese poslana preko vanjske usluge ne prolazi provjere autentikacije i vjerojatno će biti filtrirana.

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

Pružatelj vam potom daje DNS zapise koje dodajete tamo gdje se upravlja DNS-om vaše domene. Ako vam je DNS nov, kako rade domene i DNS najprije objašnjava zapise.

SPF

SPF (Sender Policy Framework) je TXT zapis koji navodi koji poslužitelji smiju slati e-poštu za vašu domenu. Primatelji provjeravaju je li poslužitelj pošiljatelja na popisu.

• Domena bi trebala imati samo jedan SPF zapis. Ako dodajete pružatelja, spojite ga u postojeći zapis umjesto dodavanja drugog.
• SPF pri evaluaciji dopušta najviše 10 DNS upita; dugi nizovi include: unosa mogu to premašiti i uzrokovati greške.
• Mnogi pružatelji postavljaju SPF na poddomeni za povratnu adresu koju od vas traže da napravite, pa možda uopće ne dirate svoj glavni SPF zapis.

DKIM

DKIM (DomainKeys Identified Mail) dodaje kriptografski potpis svakoj poruci. Pružatelj potpisuje privatnim ključem; vi objavljujete odgovarajući javni ključ kao DNS zapis (TXT ili CNAME, ovisno o pružatelju). Primatelji provjeravaju potpis kako bi potvrdili da je poruku poslao ovlašteni pošiljatelj i da nije promijenjena na putu.

Korak "provjera domene" kod vašeg pružatelja uglavnom se odnosi na DKIM. Nemojte ga preskočiti.

DMARC

DMARC povezuje ta dva. To je TXT zapis na _dmarc.yourdomain.com koji primateljima govori:

• Poravnanje: domena u vidljivoj adresi pošiljatelja mora se podudarati s domenom koja je prošla SPF ili DKIM.
• Politiku: što učiniti s porukama koje ne prolaze — p=none (samo prijavi), p=quarantine (tretiraj kao sumnjivu, često spam) ili p=reject.
• Izvješća: kamo slati zbirna izvješća (rua=), kako biste vidjeli tko šalje u vaše ime.

Razuman put je početi s p=none i adresom za izvješća, potvrditi da vaša legitimna pošta prolazi, zatim prijeći na quarantine i u konačnici na reject. Stroga politika također drastično otežava drugima krivotvorenje vaše domene.

Što Gmail zahtijeva

Od rujna 2026. Googleove smjernice za pošiljatelje kažu:

• Svi pošiljatelji na osobne Gmail račune trebaju SPF ili DKIM, valjani unaprijed i obrnuti DNS za poslužitelje za slanje, TLS i stopu spama u Postmaster Tools ispod 0,3%.
• Masovni pošiljatelji (više od 5.000 poruka dnevno na Gmail) trebaju SPF i DKIM, DMARC zapis (dopuštena je politika p=none), poravnanje domene pošiljatelja i jednoklik odjavu te vidljivu poveznicu za odjavu na marketinškim i pretplatničkim porukama.

Vaš pružatelj brine o poslužiteljskim dijelovima. DNS zapise i obradu odjava radite vi. Čak i ako ste daleko od 5.000 dnevno, ispunjavanje pravila za masovne pošiljatelje najjednostavniji je način da budete sigurni.

Ugradite slanje u aplikaciju

Kada je domena potvrđena:

1. Pohranite API ključ kao tajnu na poslužitelju — nikada u kodu za prednji dio. Pogledajte što su varijable okruženja i tajne.
2. Šaljite s poslužitelja 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 i ponovno pokušajte pri privremenim greškama, tako da spor odgovor pružatelja ne uspori registraciju.
4. Zabilježite ishod — ID poruke i status kod pružatelja — bez bilježenja ključa ili cijelih sadržaja poruka s osobnim podacima.
5. Obradite webhookove za odbijene poruke i prijave: prestanite slati na adrese koje su trajno odbijene ili su vas prijavile kao spam.

Upit koji pokriva osnove:

Pošalji transakcijsku e-poštu preko [PROVIDER] koristeći poslužiteljsku tajnu [ENV_NAME], s adrese "Acme hello@mail.acme.com". Pošalji dobrodošlicu nakon registracije i potvrdu rezervacije nakon što se rezervacija spremi. Čuvaj predloške u kodu, uz verziju za običan tekst pored HTML-a. Stavi slanje u red i ponovno pokušaj privremene greške do tri puta. Bilježi greške s pružateljevom porukom o grešci, ali nikada API ključ. Dodaj webhook krajnju točku koja označava adrese kao nedostupne pri trajnim odbijanjima i prijavama i preskače ih u budućnosti.

E-poruke računa — poveznice za potvrdu, magične poveznice i poništavanje lozinki — dio su prijave. Kako dodati prijavu u svoju aplikaciju objašnjava kako se ti tokovi uklapaju; neka te poveznice budu jednokratne i kratkotrajne.

Navike za isporučivost

Autentikacija vam daje šansu 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 popisa.
• Neka odjava bude jednostavna za sve što nije strogo transakcijsko i odmah je poštujte.
• Zagrijavajte nove domene. Potpuno nova domena koja prvog dana šalje tisuće poruka izgleda sumnjivo. Počnite s transakcijskom poštom i obujam povećavajte postupno.
• Držite popise čistima. Odmah uklonite trajno odbijene adrese i razmislite o uklanjanju ljudi koji već dugo ništa nisu otvorili.
• Pišite kao čovjek. Jasan predmet, prepoznatljivo ime pošiljatelja, dio za običan tekst, malo slika i poveznice na vašu domenu. Izbjegavajte skraćivače poveznica.
• Pratite. Registrirajte domenu u Google Postmaster Tools i povremeno čitajte DMARC izvješća.
• Koristite pravu adresu za odgovor koju netko čita. Odgovori su dobar signal i koristan povratni podatak.

Testiranje bez slanja spama nekome

• Koristite testni način ili sandbox svog pružatelja gdje ga ima, ili šaljite na adrese koje sami posjedujete.
• U razvoju šaljite na testni inbox koji hvata sve poruke umjesto na prave korisnike; baza s popunjenim realno izgledajućim adresama lak je način da slučajno pošaljete e-poštu nepoznatim ljudima.
• Provjerite svaki predložak u nekoliko klijenata — Gmail u pregledniku, aplikaciju za e-poštu na telefonu, Outlook — i u tamnom načinu.
• Pogledajte zaglavlja testne poruke: pokazuju prolaze li SPF, DKIM i DMARC.

Pravne osnove

Pravila se razlikuju od države do države. Općenito, marketinška e-pošta na mnogim mjestima treba pristanak, mora označiti pošiljatelja i mora imati funkcionalnu odjavu; transakcijska e-pošta tretira se drugačije, ali se ne smije koristiti za ubacivanje marketinga. Ako adrese prikupljate preko stranice za listu čekanja, recite što ćete slati i pohranjivati te kada i kako se svaka osoba prijavila. Kad niste sigurni, provjerite pravila tamo gdje su vaši korisnici.

Popis za e-poštu

• Odabran pružatelj slanja; API ključ pohranjen kao tajna na poslužitelju
• Slanje s vlastite domene ili poddomene, ne s besplatne adrese
• Dodani SPF, DKIM i DMARC zapisi koji prolaze
• Transakcijska i marketinška pošta odvojene
• Slanja stavljena u red i ponovno pokušavana; ishodi zabilježeni
• Obrađeni webhookovi za odbijene poruke i prijave
• Odjava na nietransakcijskoj pošti, odmah poštovana
• Predlošci testirani u više klijenata; testna pošta nikada ne dolazi pravim korisnicima

Slanje e-pošte iz Mythex aplikacije

Mythex ne uključuje ugrađenu uslugu slanja e-pošte za aplikacije koje izrađujete, pa donosite pružatelja poput Resenda, SendGrida ili Postmarka. Njegov API ključ pohranite kao tajnu projekta — agent ga može zatražiti karticom za tajne u chatu — i zatražite e-poruke koje trebate običnim riječima. Dokumentacija ima početni upit u slanje e-pošte iz aplikacije. Ako ste domenu kupili preko Mythexa na Pro planu, TXT i CNAME zapise pružatelja možete dodati u DNS postavkama domene; pogledajte prilagođene domene.

Pitanja