Hogyan küldj e-maileket az alkalmazásodból (és jussanak be a postaládába)

Ahhoz, hogy az alkalmazásod megbízhatóan küldjön e-maileket, használj e-mail-küldő szolgáltatót a saját postafiókod helyett, a saját domaineden lévő címről küldj, és add hozzá a szolgáltató által adott DNS-rekordokat, hogy az SPF, a DKIM és a DMARC mind átmenjen. A tranzakciós e-maileket — jelszó-visszaállítás, nyugták, visszaigazolások — tartsd el a marketing e-mailtől, mindkettőt csak olyan embereknek küldd, akik számítanak rá, és kezeld a visszapattanásokat és a leiratkozásokat. Előbb a hitelesítést állítsd be rendesen; ez a leggyakoribb oka annak, hogy az alkalmazás e-mailjei a spam mappába kerülnek.

Tranzakciós vs. marketing e-mail

Ezt a két típust a kódban hasonlónak lehet látni, de a postafiók-szolgáltatók és a jog nagyon eltérően kezeli őket.

Tartsd őket külön. Ha egy marketingkampány spam-panaszokat kap, nem szeretnéd, hogy ugyanabból a csatornából küldött jelszó-visszaállítások is ezt megszenvedjék. Gyakori megoldás a külön aldomain — például mail.example.com a fiókos e-mailekhez és news.example.com a hírlevelekhez —, és egyes szolgáltatók belsőleg is szétválasztják a kettőt. A Postmark például 2026 szeptemberében úgy írta le a tranzakciós és a körlevél-„üzenetfolyamait”, hogy azok külön küldési infrastruktúrán futnak.

Szolgáltató kiválasztása

Az alkalmazásod ne a saját szerveréről küldjön e-mailt. A küldő szolgáltatók kezelik az infrastruktúrát, az IP-hírnevet, az újrapróbálkozásokat és a visszapattanások feldolgozását. Ismert lehetőségek a Postmark, a Resend, a SendGrid, az Amazon SES és a Mailgun; mindegyiknek van HTTP API-ja és SMTP-hozzáférése. Az árak és a csomagok változnak, ezért hasonlítsd össze őket a saját oldalaikon.

Mit érdemes összevetni:

• Fókusz. Egyes szolgáltatók a tranzakciós e-mailre specializálódnak, mások a tranzakciós és a marketing e-mailt is kínálják.
• Fejlesztői élmény. Átlátható API, hivatalos könyvtárak a nyelvedhez, hasznos naplók, amelyek megmutatják, hogy egy üzenet kézbesítve lett-e, visszapattant-e vagy spamnek lett jelölve.
• Webhookok a visszapattanásokhoz, panaszokhoz és kézbesítésekhez, hogy az alkalmazásod reagálhasson.
• Sablonok — a szolgáltatónál tárolva, vagy a saját kódodban. A kódban tartott sablonok verziózhatók és tesztelhetők.
• Régió és adatkezelés, ha vannak követelményeid arra vonatkozóan, hol dolgozzák fel az adatokat.
• Költség a te mennyiségeden, beleértve azt is, mi történik, ha túllépsz az ingyenes keretet.

Listának szóló hírlevelekhez gyakran jobb egy külön hírlevél- vagy e-mail-marketing eszköz, mint kampányfunkciókat építeni az alkalmazásba.

Állítsd be a küldő domaint

A saját domainedről küldj — hello@example.com, ne Gmail- vagy Outlook-címről. Az ingyenes postafiók-címről harmadik fél szolgáltatásán keresztül küldött levél nem megy át a hitelesítési ellenőrzéseken, és valószínűleg kiszűrik.

Gondolj egy külön aldomainre csak a küldéshez. A Resend például azt javasolja, hogy olyan aldomainről küldj, mint updates.example.com, hogy elkülönítsd a küldési hírnevet (2026 szeptemberében). Így az e-mailes DNS-rekordok is elkülönülnek a főoldaladétól.

A szolgáltató ezután DNS-rekordokat ad, amelyeket ott kell hozzáadnod, ahol a domained DNS-e van kezelve. Ha a DNS új neked, a hogyan működnek a domainek és a DNS előbb a rekordokat magyarázza el.

SPF

Az SPF (Sender Policy Framework) egy TXT-rekord, amely felsorolja, mely szerverek küldhetnek e-mailt a domaineden. A fogadó oldal ellenőrzi, hogy a küldő szerver szerepel-e a listán.

• Egy domainhez csak egy SPF-rekord tartozhat. Ha szolgáltatót adsz hozzá, az új beállítást olvaszd bele a meglévő rekordba, ne adj hozzá másodikat.
• Az SPF kiértékelésekor legfeljebb 10 DNS-lekérdezés engedélyezett; a hosszú include: láncok túlléphetik ezt, és hibát okozhatnak.
• Sok szolgáltató az SPF-et egy visszaútvonal-aldomainen állítja be, amelyet létrehozni kérnek tőled, így a főoldali SPF-rekordhoz egyáltalán nem kell nyúlnod.

DKIM

A DKIM (DomainKeys Identified Mail) minden üzenethez kriptográfiai aláírást ad. A szolgáltató privát kulccsal ír alá; te a hozzá tartozó nyilvános kulcsot DNS-rekordként teszed közzé (TXT vagy CNAME, a szolgáltatótól függően). A fogadók az aláírást ellenőrzik, hogy megbizonyosodjanak arról, hogy a küldő jogosult volt, és az üzenetet útközben nem módosították.

A szolgáltató „domain ellenőrzése” lépése nagyrészt erről szól. Ne hagyd ki.

DMARC

A DMARC összefogja a másik kettőt. Ez egy TXT-rekord a _dmarc.yourdomain.com címen, amely megmondja a fogadóknak:

• Igazítás: a látható feladó (From) címben lévő domainnek egyeznie kell azzal a domainnel, amely átment az SPF- vagy a DKIM-ellenőrzésen.
• Szabály: mit tegyenek a sikertelen levelekkel — p=none (csak jelentés), p=quarantine (gyanúsnak kezelés, gyakran spam) vagy p=reject.
• Jelentések: hová küldjék az összesített jelentéseket (rua=), hogy lásd, ki küld a domained nevében.

Jó út, ha a p=none szabállyal és egy jelentési címmel indulsz, megnézed, hogy a jogos leveleid átmennek-e, majd áttérsz a quarantine-ra, végül a reject-re. A szigorú szabály azt is sokkal nehezebbé teszi, hogy mások a domaineden nevében hamisítsanak.

Mit követel meg a Gmail

A Google 2026 szeptemberében érvényes küldési irányelvei szerint:

• Minden küldőnek, aki személyes Gmail-fiókokba küld, kell SPF vagy DKIM, érvényes előre és fordított DNS a küldő szervereknek, TLS, és a Postmaster Tools-ban a spam-arány 0,3% alatt van.
• Tömeges küldőknek (naponta 5000-nél több üzenet Gmail-címekre) kell SPF és DKIM, DMARC-rekord (a p=none szabály megengedett), a From-domain igazítása, valamint egy kattintásos leiratkozás és látható leiratkozási link a marketing- és feliratkozott üzeneteken.

A szerveroldali részeket a szolgáltató intézi. A DNS-rekordok és a leiratkozások kezelése a tiéd. Akkor is, ha messze vagy a napi 5000-től, a tömeges küldők szabályainak betartása a legegyszerűbb módja annak, hogy biztonságban legyél.

Építsd bele a küldést az alkalmazásba

Miután a domain ellenőrzött:

1. Tárold az API-kulcsot szerveroldali titokként — soha ne a front-end kódban. Lásd mik a környezeti változók és a titkok.
2. Küldj a szerverről, miután az e-mailt kiváltó művelet sikeres.
3. Ne várasd a felhasználót az e-mailre. A legegyszerűbb alkalmazásnál túl, sorba állítva küldj, és ismételd meg az átmeneti hibákat, hogy egy lassú szolgáltatói válasz ne lassítsa a regisztrációt.
4. Naplózd az eredményt — a szolgáltató üzenetazonosítóját és státuszát —, de ne naplózd a kulcsot vagy a személyes adatokat tartalmazó teljes üzenettörzset.
5. Kezeld a webhookokat a visszapattanásokhoz és panaszokhoz: állj le azoknak a címeknek a küldésével, amelyek végleg visszapattannak vagy spamnek jelölnek.

Egy prompt, amely az alapokat lefedi:

Küldj tranzakciós e-mailt [PROVIDER] szolgáltatóval a [ENV_NAME] szerver-titokkal, a feladó „Acme hello@mail.acme.com”. Küldj üdvözlő e-mailt regisztráció után, és foglalás-visszaigazolást, amikor a foglalás mentésre kerül. A sablonokat kódban tartsd, a HTML mellett egy egyszerű szöveges változattal. Sorba állított küldés, és az átmeneti hibákat legfeljebb háromszor próbáld újra. A hibákat a szolgáltató hibaüzenetével naplózd, de az API-kulcsot soha. Adj hozzá egy webhook-végpontot, amely a végleges visszapattanásoknál és panaszoknál nem kézbesíthetőnek jelöli a címeket, és a későbbiekben kihagyja ezeket.

A fiókos e-mailek — megerősítő linkek, bejelentkező linkek és jelszó-visszaállítások — a bejelentkezés részei. A hogyan adj bejelentkezést az alkalmazásodhoz bemutatja, hogyan illeszkednek ezek a folyamatok; ezeket a linkeket tedd egyszer használhatóvá és rövid életűvé.

Kézbesíthetőségi szokások

A hitelesítés azt éri el, hogy figyelembe vegyenek. A viselkedés tartja meg a postaládában.

• Csak azt küldd, amit az emberek várnak. Megerősített regisztrációk, tiszta hozzájárulás a marketinghez, vásárolt listák nélkül.
• Könnyű leiratkozás minden olyan üzeneten, amely nem szigorúan tranzakciós, és azonnal tiszteletben tartva.
• Melegítsd fel az új domaineket. Egy frissen regisztrált domain, amely az első napon ezreket küld, gyanúsnak tűnik. Kezdd a tranzakciós levelekkel, és fokozatosan növeld a mennyiséget.
• Tartsd tisztán a listákat. A végleges visszapattanásokat azonnal távolítsd el, és fontold meg azok eltávolítását, akik régóta semmit nem nyitottak meg.
• Úgy írj, mint egy ember. Világos tárgy, felismerhető feladónév, egyszerű szöveges rész, kevés kép, és linkek a saját domaineden. Kerüld a link-rövidítőket.
• Figyelj. Regisztráld a domaint a Google Postmaster Tools-ban, és időnként olvasd a DMARC-jelentéseket.
• Valódi válaszcímet használj, amelyet valaki olvas. A válaszok jó jelzések, és hasznos visszajelzést adnak.

Tesztelés úgy, hogy senkit ne spamelj

• Használd a szolgáltatód teszt módját vagy homokozóját, ahol van ilyen, vagy küldj olyan címekre, amelyek a tiéd.
• Fejlesztés közben a valódi felhasználók helyett egy fogó (catch-all) tesztpostafiókba küldj; a valódi-nak látszó címekkel teli, feltöltött adatbázis könnyű módja annak, hogy véletlenül idegeneknek írj.
• Ellenőrizd minden sablont több kliensben — Gmail weben, telefonos levelezőben, Outlookban — és sötét módban is.
• Nézd meg egy tesztlevél fejléceit: megmutatják, hogy átment-e az SPF, a DKIM és a DMARC.

Jogi alapok

A szabályok országonként eltérnek. Általánosságban: sok helyen a marketing e-mailhez hozzájárulás kell, meg kell nevezni a feladót, és működő leiratkozást kell kínálni; a tranzakciós e-mailre más szabályok vonatkoznak, de nem szabad vele marketinget becsempészni. Ha egy várólista-oldalon gyűjtesz címeket, mondd meg, mit és mikor küldesz, és hogyan tárolod az egyes emberek regisztrációját. Kétség esetén nézd meg a szabályokat ott, ahol a felhasználóid vannak.

E-mail ellenőrzőlista

• Küldő szolgáltató kiválasztva; az API-kulcs szerveroldali titokként tárolva
• Küldés a saját domainedről vagy aldomainedről, nem ingyenes postafiókból
• SPF, DKIM és DMARC rekordok hozzáadva és átmennek
• A tranzakciós és a marketing levelek szét vannak választva
• A küldések sorba állítva, újrapróbálva; az eredmények naplózva
• A visszapattanási és panasz-webhookok kezelve
• Leiratkozás a nem tranzakciós leveleken, azonnal tiszteletben tartva
• Sablonok több kliensben tesztelve; a teszt-levelek soha nem jutnak valódi felhasználókhoz

E-mail küldése Mythex-alkalmazásból

A Mythex nem tartalmaz beépített e-mail-küldő szolgáltatást az általad épített alkalmazásokhoz, ezért egy szolgáltatót kell hoznod, például Resendet, SendGridet vagy Postmarkot. Az API-kulcsát projekt-titokként tárold — az ügynök egy titok-kártyán keresztül kérheti a chaten —, és egyszerű szavakkal kérd a szükséges e-maileket. A dokumentációban a küldj e-mailt az alkalmazásodból oldalon van kezdő prompt. Ha Pro csomagban a Mythexen keresztül vetted a domainedet, a szolgáltató TXT- és CNAME-rekordjait a domain DNS-beállításaiban adhatod hozzá; lásd az egyéni domainek oldalt.

Kérdések