Príručky

Ako posielať e-maily z aplikácie (a dostať sa do doručenej pošty)

Na spoľahlivé posielanie e-mailov z aplikácie použite poskytovateľa odosielania e-mailov namiesto vlastnej schránky, odosielajte z adresy na vlastnej doméne a pridajte DNS záznamy, ktoré vám poskytovateľ dá, aby prešli SPF, DKIM aj DMARC. Transakčné e-maily — obnovenie hesla, potvrdenia, pozvánky — oddeľte od marketingových, každý typ posielajte len ľuďom, ktorí ho očakávajú, a spracovávajte odrazené správy a odhlásenia. Autentifikáciu najskôr dajte do poriadku; je to najčastejší dôvod, prečo e-maily z aplikácií končia v spame.

Transakčný vs. marketingový e-mail

Tieto dva typy e-mailov vyzerajú v kóde podobne, ale doručovatelia pošty s nimi aj zákon zaobchádzajú veľmi odlišne.

TransakčnýMarketingový (hromadný)
SpustenýTým, čo používateľ urobilVaším plánom alebo kampaňou
PríkladyPotvrdenie registrácie, obnovenie hesla, prihlasovací odkaz, potvrdenie platby, pripomienka rezervácie, „niekto odpovedal“Newsletter, oznámenie produktu, akcia, opätovné oslovenie
PríjemcoviaJeden človek narazMnoho naraz
SúhlasVyplýva z akcieTreba povolenie a jednoduché odhlásenie
NačasovanieMusí dorazit za sekundyMinúty sú v poriadku
Odkiaľ posielaťZ vašej aplikácie cez APIZ nástroja na newslettre alebo z broadcast funkcie poskytovateľa

Držte ich oddelene. Ak marketingová kampaň dostane sťažnosti na spam, nechcete, aby to odniesli resetovanie hesiel z rovnakého toku. Bežným prístupom sú oddelené subdomény — napríklad mail.example.com pre účtové e-maily a news.example.com pre newslettre — a niektorí poskytovatelia ich oddeľujú aj interne. Postmark napríklad uvádza, že jeho transakčné a broadcast „message streams“ bežia na oddelenej odosielacej infraštruktúre, ako stav k septembru 2026.

Výber poskytovateľa

Vaša aplikácia by nemala posielať e-maily sama zo svojho servera. Poskytovatelia odosielania riešia infraštruktúru, reputáciu IP adries, opakované pokusy a spracovanie odrazených správ. Známe možnosti zahŕňajú Postmark, Resend, SendGrid, Amazon SES a Mailgun; každý má HTTP API a prístup cez SMTP. Ceny a plány sa menia, preto ich porovnajte na ich stránkach.

Čo porovnávať:

  • Zameranie. Niektorí poskytovatelia sa sústreďujú na transakčné e-maily; iní kombinujú transakčné a marketingové.
  • Vývojárska skúsenosť. Prehľadné API, oficiálne knižnice pre váš jazyk a užitočné logy, ktoré ukazujú, či bola každá správa doručená, odrazená alebo označená ako spam.
  • Webhooky pre odrazy, sťažnosti a doručenia, aby na ne vaša aplikácia vedela reagovať.
  • Šablóny — uložené u poskytovateľa, alebo vo vašom kóde. Ak ich držíte v kóde, sú verzované a dajú sa testovať.
  • Región a spracovanie údajov, ak máte požiadavky na to, kde sa údaje spracúvajú.
  • Cenu pri vašom objeme, vrátane toho, čo sa stane pri prekročení bezplatnej úrovne.

Pre newslettre na zoznam je často lepším riešením dedikovaný nástroj na newslettre alebo e-mail marketing než budovanie kampaňových funkcií do vašej aplikácie.

Nastavte odosielaciu doménu

Posielajte z vlastnej domény — hello@example.com, nie z adresy Gmail alebo Outlook. Pošta z bezplatnej schránky odoslaná cez službu tretej strany neprejde kontrolami autentifikácie a s vysokou pravdepodobnosťou skončí vo filtri.

Zvážte subdoménu určenú len na odosielanie. Resend napríklad odporúča odosielať zo subdomén, ako je updates.example.com, aby sa izolovala odosielacia reputácia (stav k septembru 2026). Zároveň sa tým oddelia e-mailové DNS záznamy od DNS vašej hlavnej stránky.

Poskytovateľ potom dá DNS záznamy, ktoré pridáte tam, kde sa spravuje DNS vašej domény. Ak je DNS pre vás nové, ako fungujú domény a DNS najskôr vysvetľuje jednotlivé záznamy.

SPF

SPF (Sender Policy Framework) je TXT záznam, ktorý uvádza, ktoré servery môžu posielať e-maily za vašu doménu. Príjemca kontroluje, či je odosielajúci server v zozname.

  • Doména by mala mať len jeden SPF záznam. Ak pridáte poskytovateľa, zlúčte ho do existujúceho záznamu namiesto pridávania druhého.
  • SPF pri vyhodnocovaní povoľuje najviac 10 DNS vyhľadávaní; dlhé reťazce záznamov include: ho môžu prekročiť a spôsobiť zlyhanie.
  • Mnohí poskytovatelia nastavujú SPF na subdoméne pre návratovú cestu (return-path), ktorú vás požiadajú vytvoriť, takže hlavný SPF záznam nemusíte vôbec meniť.

DKIM

DKIM (DomainKeys Identified Mail) pridáva ku každej správe kryptografický podpis. Poskytovateľ podpisuje súkromným kľúčom; vy zverejníte zodpovedajúci verejný kľúč ako DNS záznam (TXT alebo CNAME podľa poskytovateľa). Príjemcovia overujú podpis, aby potvrdili, že správa pochádza od autorizovaného odosielateľa a nebola po ceste zmenená.

Na tom je väčšinou založený krok poskytovateľa „overiť doménu“. Nepreskakujte ho.

DMARC

DMARC spája ostatné dva. Je to TXT záznam na _dmarc.yourdomain.com, ktorý hovorí príjemcom:

  • Zarovnanie: doména vo viditeľnej adrese odosielateľa musí zodpovedať doméne, ktorá prešla SPF alebo DKIM.
  • Politika: čo robiť s poštou, ktorá zlyhá — p=none (len hlásiť), p=quarantine (považovať za podozrivú, často do spamu) alebo p=reject.
  • Reporty: kam posielať súhrnné správy (rua=), aby ste videli, kto odosiela ako vaša doména.

Rozumná cesta je začať s p=none a adresou na reporty, potvrdiť, že legitímna pošta prechádza, potom prejsť na quarantine a nakoniec na reject. Prísna politika navyše výrazne sťažuje sfalšovanie vašej domény.

Čo vyžaduje Gmail

K septembru 2026 pravidlá Googlu pre odosielateľov hovoria:

  • Všetci odosielatelia na osobné účty Gmail potrebujú SPF alebo DKIM, platný forward a reverse DNS pre odosielajúce servery, TLS a mieru spamu v Postmaster Tools nižšiu než 0,3 %.
  • Hromadní odosielatelia (viac než 5 000 správ denne na Gmail) potrebujú SPF aj DKIM, DMARC záznam (politika p=none je povolená), zarovnanie domény odosielateľa a odhlásenie jedným kliknutím plus viditeľný odkaz na odhlásenie v marketingových a odberových správach.

Serverové časti rieši váš poskytovateľ. DNS záznamy a spracovanie odhlásení sú na vás. Aj keď ste ďaleko od 5 000 denne, splnenie pravidiel pre hromadných odosielateľov je najjednoduchší spôsob, ako byť v bezpečí.

Zabudujte odosielanie do aplikácie

Keď je doména overená:

  1. Uložte API kľúč ako tajomstvo na serveri — nikdy nie vo frontend kóde. Pozrite si čo sú premenné prostredia a tajomstvá.
  2. Odosielajte zo servera až po tom, ako akcia, ktorá e-mail spúšťa, úspešne prebehne.
  3. Nenechajte používateľa čakať na e-mail. Pri všetkom nad najjednoduchšiu aplikáciu odosielanie zaraďte do fronty a pri dočasných chybách ho opakujte, aby pomalá odpoveď poskytovateľa nespomaľovala registráciu.
  4. Zaznamenávajte výsledok — ID správy a stav od poskytovateľa — bez kľúča a bez celého obsahu správ s osobnými údajmi.
  5. Spracovávajte webhooky pre odrazy a sťažnosti. Prestaňte posielať na adresy, ktoré natvrdo odrazia alebo vás označia ako spam.

Prompt, ktorý pokrýva základy:

Odosielaj transakčné e-maily cez [PROVIDER] pomocou serverového tajomstva [ENV_NAME], z adresy „Acme hello@mail.acme.com“. Po registrácii pošli uvítací e-mail a po uložení rezervácie potvrdenie rezervácie. Šablóny drž v kóde, s textovou verziou popri HTML. Odosielanie zaraďuj do fronty a pri dočasných chybách opakuj až trikrát. Chyby zapisuj s chybovou správou poskytovateľa, ale do logu nikdy nedávaj API kľúč. Pridaj webhook endpoint, ktorý pri natvrdo odrazených správach a sťažnostiach označí adresy ako nedoručiteľné a v budúcnosti ich preskočí.

Účtové e-maily — overovacie odkazy, prihlasovacie odkazy a obnovenie hesla — sú súčasťou prihlasovania. Ako pridať prihlasovanie do aplikácie vysvetľuje, ako tieto toky do seba zapadajú; tieto odkazy nech sú jednorazové a krátkodobé.

Návyky pre doručiteľnosť

Autentifikácia zabezpečí, že vás pošta zoberie do úvahy. Správanie vás udrží v doručenej pošte.

  • Posielajte len to, čo ľudia očakávajú. Potvrdené registrácie, jasný súhlas s marketingom, žiadne kúpené zoznamy.
  • Odhlásenie nech je jednoduché pri všetkom, čo nie je striktne transakčné, a rešpektujte ho okamžite.
  • Zahrievajte nové domény. Nová doména, ktorá v prvý deň odošle tisíce správ, pôsobí podozrivo. Začnite transakčnou poštou a objem zvyšujte postupne.
  • Čistite zoznamy. Natvrdo odrazené adresy odstráňte hneď a zvážte odstránenie ľudí, ktorí dlho nič neotvorili.
  • Píšte ako človek. Jasný predmet, rozpoznateľné meno odosielateľa, textová časť a málo obrázkov a odkazov na vašu vlastnú doménu. Vyhýbajte sa skracovačom odkazov.
  • Sledujte. Zaregistrujte doménu v Google Postmaster Tools a občas čítajte DMARC reporty.
  • Používajte skutočnú adresu na odpoveď, ktorú niekto číta. Odpovede sú dobrý signál aj užitočná spätná väzba.

Testovanie bez obťažovania niekoho

  • Použite testovací režim alebo sandbox poskytovateľa, ak ho má, alebo posielajte na adresy, ktoré vlastníte.
  • Vo vývoji posielajte na testovaciu schránku typu catch-all, nie reálnym používateľom; databáza naplnená reálne vyzerajúcimi adresami je jednoduchý spôsob, ako omylom napísať cudzím ľuďom.
  • Každú šablónu si pozrite v niekoľkých klientoch — Gmail vo webe, e-mailová aplikácia v telefóne, Outlook — a aj v tmavom režime.
  • Pozrite sa na hlavičky testovacieho e-mailu: ukážu, či prešli SPF, DKIM a DMARC.

Právne základy

Pravidlá sa líšia podľa krajiny. Vo všeobecnosti marketingový e-mail v mnohých miestach vyžaduje súhlas, musí identifikovať odosielateľa a musí ponúkať funkčné odhlásenie; transakčný e-mail sa posudzuje inak, ale nemal by slúžiť na nenápadné vkladanie marketingu. Ak zbierate adresy z stránky s čakacou listinou, uveďte, čo a kedy budete posielať a ukladať a ako sa každý človek prihlásil. V pochybnostiach skontrolujte pravidlá v krajinách, kde sú vaši používatelia.

Kontrolný zoznam e-mailov

  • Poskytovateľ odosielania vybraný; API kľúč uložený ako serverové tajomstvo
  • Odosielanie z vlastnej domény alebo subdomény, nie z bezplatnej schránky
  • SPF, DKIM a DMARC záznamy pridané a prechádzajú
  • Transakčná a marketingová pošta oddelené
  • Odosielanie zaradené do fronty a opakované; výsledky zaznamenané
  • Webhooky pre odrazy a sťažnosti spracované
  • Odhlásenie pri nie transakčnej pošte, rešpektované okamžite
  • Šablóny otestované v niekoľkých klientoch; testovacia pošta nikdy nedorazí reálnym používateľom

Posielanie e-mailov z aplikácie v Mythexe

Mythex neobsahuje pre aplikácie, ktoré staviate, vstavanú službu na odosielanie e-mailov, takže si prinesiete poskytovateľa ako Resend, SendGrid alebo Postmark. Jeho API kľúč uložte ako tajomstvo projektu — agent si ho môže vyžiadať cez kartu so tajomstvom v chate — a e-maily, ktoré potrebujete, si vyžiadajte obyčajnými slovami. Dokumentácia má štartovací prompt v odosielanie e-mailov z vašej aplikácie. Ak ste doménu kúpili cez Mythex na pláne Pro, TXT a CNAME záznamy poskytovateľa môžete pridať v nastaveniach DNS domény; pozrite si vlastné domény.

Otázky

Aký je rozdiel medzi transakčným a marketingovým e-mailom?

Transakčný e-mail sa spustí tým, čo používateľ urobil, a je očakávaný — napríklad obnovenie hesla, potvrdenie objednávky alebo rezervácie. Marketingový e-mail sa posiela mnohým ľuďom podľa vášho plánu, napríklad newslettre a oznámenia. Majú iné pravidlá súhlasu a najlepšie je posielať ich z oddelených tokov alebo subdomén.

Prečo mi e-maily z aplikácie končia v spame?

Obvyklé príčiny sú odosielacia doména bez nastaveného SPF, DKIM a DMARC, odosielanie z bezplatnej adresy ako Gmail cez službu tretej strany, nová doména bez reputácie alebo obsah a odkazy, ktoré pripomínajú spam. Najskôr opravte autentifikáciu, potom sa pozrite na obsah a objem.

Môžem posielať e-maily aplikácie z môjho účtu Gmail?

Na zopár osobných testovacích správ možno, ale nie pre skutočnú aplikáciu. Použite poskytovateľa odosielania e-mailov s vlastnou doménou, nastavte DNS záznamy, ktoré vám dá, a odosielajte z adresy na tejto doméne.

Potrebujem DMARC?

V praxi áno. Od septembra 2026 Google vyžaduje DMARC od každého, kto odosiela viac než 5 000 správ denne na adresy Gmail, a DMARC záznam navyše chráni vašu doménu pred sfalšovaním. Začiatok s politikou p=none je v poriadku, kým kontrolujete reporty.

Mythex · Pricing · Vytvorte čokoľvek s AI · Šablóny webov a aplikácií · Mythex v porovnaní · Slovník pojmov tvorby aplikácií s AI · Bezplatné nástroje na tvorbu aplikácií s AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)