Jak posílat e-maily z vaší aplikace (a dostat se do doručené pošty)

Chcete-li z aplikace spolehlivě posílat e-maily, používejte poskytovatele odesílání e-mailů místo vlastní poštovní schránky, odesílejte z adresy na vlastní doméně a přidejte DNS záznamy, které vám poskytovatel dá, aby prošla kontrola SPF, DKIM i DMARC. Transakční e-maily — obnovení hesla, potvrzení, notifikace — držte odděleně od marketingových, každý typ posílejte jen lidem, kteří ho očekávají, a řešte odrazy (bounces) a odhlášení. Autentizaci nejdřív zprovozněte; je to nejčastější důvod, proč e-maily z aplikací končí ve spamu.

Transakční vs marketingový e-mail

Tyto dva typy e-mailů vypadají v kódu podobně, ale poskytovatelé schránek i zákon s nimi zacházejí velmi rozdílně.

Držte je oddělené. Pokud marketingová kampaň dostane stížnosti na spam, nechcete, aby kvůli tomu trpěly obnovy hesel ze stejného streamu. Běžný přístup jsou samostatné subdomény — například mail.example.com pro účtové e-maily a news.example.com pro newslettery — a některí poskytovatelé oba typy oddělují i interně. Postmark například od září 2026 popisuje své transakční a broadcastové „message streamy“ tak, že běží na oddělené odesílací infrastruktuře.

Výběr poskytovatele

Vaše aplikace by neměla posílat e-maily přímo ze svého serveru. Poskytovatelé odesílání se starají o infrastrukturu, reputaci IP adres, opakované pokusy a zpracování odrazů. Mezi známé možnosti patří Postmark, Resend, SendGrid, Amazon SES a Mailgun; každý má HTTP API i přístup přes SMTP. Ceny a tarify se mění, takže je porovnejte na jejich webech.

Co porovnávat:

• Zaměření. Někteří poskytovatelé se soustředí na transakční e-maily, jiní kombinují transakční i marketingové.
• Vývojářský komfort. Přehledné API, oficiální knihovny pro váš jazyk, užitečné logy ukazující, zda byla zpráva doručena, odrazena nebo označena jako spam.
• Webhooky pro odrazy, stížnosti a doručení, aby na ně aplikace mohla reagovat.
• Šablony — uložené u poskytovatele, nebo ve vašem kódu. Uložení v kódu znamená verzování a možnost testování.
• Region a zpracování dat, pokud máte požadavky na to, kde se data zpracovávají.
• Cena při vašem objemu, včetně toho, co se stane, když překročíte bezplatný limit.

Pro newslettery posílané na seznam se často hodí specializovaný nástroj pro newslettery nebo e-mailový marketing lépe než kampaňové funkce vestavěné do aplikace.

Nastavení odesílací domény

Odesílejte z vlastní domény — hello@example.com, ne z adresy Gmail nebo Outlook. Pošta z bezplatné poštovní schránky odeslaná přes službu třetí strany neprojde kontrolou autentizace a bude pravděpodobně filtrována.

Zvažte subdoménu určenou jen pro odesílání. Resend například doporučuje odesílat ze subdomén, jako je updates.example.com, aby se izolovala odesílací reputace (stav k září 2026). Zároveň tím zůstanou e-mailové DNS záznamy oddělené od záznamů hlavního webu.

Poskytovatel pak dá DNS záznamy, které přidáte tam, kde se spravuje DNS vaší domény. Pokud je pro vás DNS nová věc, nejdřív vysvětluje záznamy článek jak fungují domény a DNS.

SPF

SPF (Sender Policy Framework) je TXT záznam, který uvádí, které servery smějí za vaši doménu odesílat e-maily. Příjemci kontrolují, zda odesílající server je na tomto seznamu.

• Doména by měla mít pouze jeden SPF záznam. Přidáte-li poskytovatele, sloučte ho do stávajícího záznamu, nepřidávejte druhý.
• SPF při vyhodnocení povoluje nejvýše 10 DNS dotazů; dlouhé řetězce položek include: ho mohou překročit a způsobit selhání.
• Mnoho poskytovatelů nastavuje SPF na subdoméně pro návrat pošty (return-path), kterou vás požádají vytvořit, takže hlavní SPF záznam se možná vůbec nedotknete.

DKIM

DKIM (DomainKeys Identified Mail) přidává ke každé zprávě kryptografický podpis. Poskytovatel podepisuje soukromým klíčem; odpovídající veřejný klíč publikujete jako DNS záznam (TXT nebo CNAME podle poskytovatele). Příjemci kontrolují podpis, aby ověřili, že zpráva pochází od oprávněného odesílatele a cestou nebyla změněna.

Krok „ověřit doménu“ u poskytovatele se většinou týká právě DKIM. Nepřeskakujte ho.

DMARC

DMARC spojuje ostatní dva mechanismy dohromady. Je to TXT záznam na _dmarc.yourdomain.com, který příjemcům říká:

• Shodu (alignment): doména ve viditelné adrese odesílatele musí odpovídat doméně, která prošla SPF nebo DKIM.
• Politiku: co dělat s nevyhovující poštou — p=none (pouze hlásit), p=quarantine (považovat za podezřelou, často spam) nebo p=reject (odmítnout).
• Reporty: kam posílat souhrnné zprávy (rua=), abyste viděli, kdo odesílá jménem vaší domény.

Rozumný postup je začít s p=none a adresou pro reporty, ověřit, že vaše legitimní pošta prochází, a pak přejít na quarantine a nakonec na reject. Přísná politika také výrazně ztíží podvrhávání vaší domény.

Co vyžaduje Gmail

Podle pokynů Googlu pro odesílatele platných od září 2026:

• Všichni odesílatelé na osobní účty Gmailu potřebují SPF nebo DKIM, platné dopředné i zpětné DNS záznamy pro odesílající servery, TLS a míru spamu v Postmaster Tools pod 0,3 %.
• Hromadní odesílatelé (více než 5 000 zpráv denně na Gmail) potřebují SPF a DKIM, záznam DMARC (politika p=none je povolena), shodu domény v odesílateli a odhlášení jedním kliknutím spolu s viditelným odkazem na odhlášení u marketingových a odebíraných zpráv.

Serverové části řeší váš poskytovatel. DNS záznamy a zpracování odhlášení jsou vaše. I když jste daleko od 5 000 denně, splnění pravidel pro hromadné odesílatele je nejjednodušší cesta, jak být v bezpečí.

Zabudování odesílání do aplikace

Až je doména ověřena:

1. Uložte API klíč jako tajný údaj na serveru — nikdy ve frontend kódu. Viz co jsou proměnné prostředí a tajné údaje.
2. Odesílejte ze serveru až po úspěšném provedení akce, která e-mail spouští.
3. Uživatel nemá čekat na e-mail. U čehokoli složitějšího než nejjednodušší aplikace řaďte odeslání do fronty a při dočasných chybách opakujte pokus, aby pomalá odpověď poskytovatele nezpomalovala registraci.
4. Zaznamenávejte výsledek — ID zprávy a stav od poskytovatele — bez logování klíče nebo celého těla zprávy s osobními údaji.
5. Zpracovávejte webhooky pro odrazy a stížnosti: přestaňte posílat na adresy, které tvrdě odrazí (hard bounce) nebo které označily vaši poštu jako spam.

Prompt, který pokrývá základy:

Posílej transakční e-maily přes [POSKYTOVATEL] pomocí serverového tajného klíče [NÁZEV_PROMĚNNÉ], z adresy „Acme hello@mail.acme.com“. Po registraci pošli uvítací e-mail a po uložení rezervace potvrzení rezervace. Šablony drž v kódu, s textovou verzí vedle HTML. Odesílání řaď do fronty a dočasné chyby opakuj až třikrát. Chyby loguj s chybovou zprávou poskytovatele, ale nikdy s API klíčem. Přidej webhook endpoint, který při tvrdých odrazech a stížnostech označí adresy jako nedoručitelné a v budoucnu je přeskočí.

Účtové e-maily — ověřovací odkazy, magic linky a obnovení hesla — jsou součástí přihlášení. Jak přidat přihlášení do aplikace vysvětluje, jak tyto postupy zapadají do sebe; tyto odkazy udělejte jednorázové a krátkodobé.

Návyky pro doručitelnost

Autentizace zajistí, že vás poskytovatel bere v úvahu. Chování vás udrží v doručené poště.

• Posílejte jen to, co lidé čekají. Potvrzené registrace, jasný souhlas s marketingem, žádné koupené seznamy.
• Odhlášení musí být snadné u všeho, co není striktně transakční, a musí se dodržet okamžitě.
• Zahřívejte nové domény. Úplně nová doména, která hned první den odešle tisíce zpráv, působí podezřele. Začněte transakční poštou a objem zvyšujte postupně.
• Udržujte seznamy čisté. Tvrdé odrazy odstraňte okamžitě a zvažte odstranění lidí, kteří dlouho nic neotevřeli.
• Pište přirozeně. Srozumitelný předmět, rozpoznatelné jméno odesílatele, textová část, málo obrázků a odkazy na vaši vlastní doménu. Vyhněte se zkracovačům odkazů.
• Sledujte. Zaregistrujte doménu v Google Postmaster Tools a čas od času čtěte reporty DMARC.
• Používejte skutečnou adresu pro odpovědi, na kterou někdo čte. Odpovědi jsou dobrý signál i užitečná zpětná vazba.

Testování bez spamování kohokoli

• Použijte testovací režim nebo sandbox poskytovatele, pokud ho má, nebo posílejte na adresy, které vlastníte.
• Ve vývoji posílejte do testovací schránky typu catch-all místo skutečným uživatelům; naplněná databáze reálně vypadajících adres je snadný způsob, jak náhodou napsat cizím lidem.
• Každou šablonu zkontrolujte v několika klientech — Gmail ve webovém prohlížeči, poštovní aplikace v telefonu, Outlook — a v tmavém režimu.
• Podívejte se do hlaviček testovacího e-mailu: ukazují, zda prošly SPF, DKIM a DMARC.

Právní základy

Pravidla se liší podle země. Obecně platí, že marketingové e-maily v mnoha místech vyžadují souhlas, musí identifikovat odesílatele a musí nabízet funkční odhlášení; transakční e-maily jsou posuzovány jinak, ale nemají se zneužívat k vkládání marketingu. Pokud sbíráte adresy přes stránku čekací listiny, uveďte, co budete posílat a ukládat, a kdy a jak se každý člověk zaregistroval. Když si nejste jisti, zkontrolujte pravidla v zemích, kde jsou vaši uživatelé.

Kontrolní seznam e-mailů

• Vybrán poskytovatel odesílání; API klíč uložen jako tajný údaj na serveru
• Odesílání z vlastní domény nebo subdomény, ne z bezplatné poštovní schránky
• Přidány záznamy SPF, DKIM a DMARC a procházejí kontrolou
• Transakční a marketingová pošta jsou oddělené
• Odesílání je řazeno do fronty a opakováno; výsledky se logují
• Zpracovány webhooky pro odrazy a stížnosti
• Odhlášení u netransakční pošty, dodržované okamžitě
• Šablony otestovány v několika klientech; testovací pošta nikdy nedorazí skutečným uživatelům

Odesílání e-mailů z aplikace Mythex

Mythex pro aplikace, které stavíte, neobsahuje vestavěnou službu pro odesílání e-mailů, takže přinesete vlastního poskytovatele, například Resend, SendGrid nebo Postmark. Jeho API klíč uložte jako tajný údaj projektu — agent si ho může vyžádat kartou s tajným údajem v chatu — a požadované e-maily popište běžnou řečí. Startovací prompt najdete v dokumentaci v části odeslání e-mailu z vaší aplikace. Pokud jste doménu koupili přes Mythex na tarifu Pro, můžete přidat TXT a CNAME záznamy poskytovatele v nastavení DNS domény; viz vlastní domény.

Otázky