Cum trimiți emailuri din aplicația ta (și ajung în inbox)

Ca să trimiți emailuri din aplicație fiabil, folosește un furnizor de trimitere de email, nu propria căsuță poștală, trimite de pe o adresă de pe propriul domeniu și adaugă înregistrările DNS pe care ți le oferă furnizorul, astfel încât SPF, DKIM și DMARC să treacă toate. Păstrează emailurile tranzacționale — resetări de parolă, chitanțe, confirmări — separate de cele de marketing, trimite fiecare doar persoanelor care se așteaptă la el și gestionează respingerile (bounces) și dezabonările. Rezolvă autentificarea mai întâi; este cel mai frecvent motiv pentru care emailurile aplicațiilor ajung în spam.

Emailuri tranzacționale vs. de marketing

Cele două tipuri arată asemănător în cod, dar sunt tratate foarte diferit de furnizorii de inbox și de lege.

Ține-le separate. Dacă o campanie de marketing primește plângeri de spam, nu vrei ca resetările de parolă din același flux să sufere din cauza ei. O abordare obișnuită sunt subdomeniile separate — de exemplu mail.exemplu.ro pentru emailurile de cont și news.exemplu.ro pentru newslettere — iar unii furnizori separă cele două intern. Postmark, de exemplu, descrie fluxurile sale de mesaje tranzacționale și de broadcast ca rulând pe infrastructuri de trimitere separate, începând cu septembrie 2026.

Alegerea furnizorului

Aplicația ta nu ar trebui să trimită emailuri direct de pe propriul server. Furnizorii de trimitere se ocupă de infrastructură, reputația IP-urilor, reîncercări și procesarea respingerilor. Printre opțiunile cunoscute se numără Postmark, Resend, SendGrid, Amazon SES și Mailgun; fiecare are un API HTTP și acces SMTP, iar prețurile și planurile se schimbă, așa că compară-le pe site-urile lor.

Ce să compari:

• Focusul. Unii furnizori se concentrează pe emailul tranzacțional; alții combină tranzacțional și marketing.
• Experiența de dezvoltator. API clar, biblioteci oficiale pentru limbajul tău, jurnale utile care arată dacă fiecare mesaj a fost livrat, respins sau marcat ca spam.
• Webhook-uri pentru respingeri, plângeri și livrări, ca aplicația ta să poată reacționa.
• Șabloane — stocate la furnizor sau în codul tău. Dacă le ții în cod, sunt versionate și pot fi testate.
• Regiune și gestionarea datelor, dacă ai cerințe despre locul unde sunt procesate datele.
• Costul la volumul tău, inclusiv ce se întâmplă când depășești un nivel gratuit.

Pentru newslettere către o listă, un instrument dedicat de newsletter sau de email marketing este adesea o alegere mai bună decât să construiești funcții de campanie în aplicația ta.

Configurează domeniul de expediere

Trimite de pe propriul domeniu — hello@exemplu.ro, nu o adresă Gmail sau Outlook. Mesajele trimise de pe o căsuță gratuită printr-un serviciu terț eșuează verificările de autentificare și sunt probabil filtrate.

Ia în calcul un subdomeniu doar pentru trimitere. Resend, de exemplu, recomandă trimiterea de pe subdomenii precum updates.exemplu.ro, ca să izoleze reputația de expediere (la data din septembrie 2026). Astfel, înregistrările DNS pentru email rămân separate de cele ale site-ului principal.

Furnizorul îți oferă apoi înregistrările DNS de adăugat acolo unde este gestionat DNS-ul domeniului tău. Dacă DNS-ul îți este nou, cum funcționează domeniile și DNS-ul explică mai întâi înregistrările.

SPF

SPF (Sender Policy Framework) este o înregistrare TXT care listează serverele care au voie să trimită email pentru domeniul tău. Destinatarii verifică dacă serverul care trimite este pe listă.

• Un domeniu ar trebui să aibă o singură înregistrare SPF. Dacă adaugi un furnizor, unește-l în înregistrarea existentă, în loc să adaugi a doua.
• SPF permite cel mult 10 interogări DNS la evaluare; lanțuri lungi de intrări include: pot depăși limita și pot cauza eșecuri.
• Mulți furnizori setează SPF pe un subdomeniu de tip return-path pe care îl cer să îl creezi, așa că s-ar putea să nu atingi deloc înregistrarea SPF principală.

DKIM

DKIM (DomainKeys Identified Mail) adaugă o semnătură criptografică fiecărui mesaj. Furnizorul semnează cu o cheie privată; tu publici cheia publică corespunzătoare ca înregistrare DNS (TXT sau CNAME, în funcție de furnizor). Destinatarii verifică semnătura ca să confirme că mesajul vine de la un expeditor autorizat și că nu a fost modificat pe drum.

DKIM este, în mare parte, miezul pasului de „verificare domeniu” al furnizorului tău. Nu-l sări.

DMARC

DMARC leagă celelalte două. Este o înregistrare TXT la _dmarc.domeniultau.ro care le spune destinatarilor:

• Aliniere: domeniul din adresa vizibilă From trebuie să corespundă domeniului care a trecut SPF sau DKIM.
• Politică: ce să facă cu mesajele care eșuează — p=none (doar raportează), p=quarantine (tratează ca suspect, adesea spam) sau p=reject.
• Rapoarte: unde să fie trimise rapoartele agregate (rua=), ca să vezi cine trimite în numele domeniului tău.

O cale rezonabilă este să începi cu p=none și o adresă de raportare, să confirmi că mesajele tale legitime trec, apoi să treci la quarantine și, în final, la reject. O politică strictă face și mult mai greu ca alții să îți falsifice domeniul.

Ce cere Gmail

Din septembrie 2026, ghidurile de expeditor ale Google spun:

• Toți expeditorii către conturi Gmail personale au nevoie de SPF sau DKIM, de DNS direct și invers valid pentru serverele de trimitere, de TLS și de o rată de spam sub 0,3% în Postmaster Tools.
• Expeditorii în volum mare (mai mult de 5.000 de mesaje pe zi către Gmail) au nevoie de SPF și DKIM, de o înregistrare DMARC (politica p=none este permisă), de aliniere a domeniului From și de dezabonare dintr-un singur clic, plus un link vizibil de dezabonare la mesajele de marketing și cele la care te-ai abonat.

Furnizorul se ocupă de partea de server. Înregistrările DNS și gestionarea dezabonărilor sunt ale tale. Chiar dacă nu ajungi la 5.000 pe zi, respectarea regulilor pentru volum mare este cel mai simplu mod de a fi în siguranță.

Construiește trimiterea în aplicație

Odată ce domeniul este verificat:

1. Stochează cheia API ca secret pe server — niciodată în codul din front-end. Vezi ce sunt variabilele de mediu și secretele.
2. Trimite de pe server, după ce acțiunea care declanșează emailul a reușit.
3. Nu face utilizatorul să aștepte după email. Pentru orice depășește cea mai simplă aplicație, pune trimiterea în coadă și reîncearcă la erorile temporare, ca un răspuns lent al furnizorului să nu încetinească înscrierea.
4. Înregistrează rezultatul — ID-ul mesajului și statusul de la furnizor — fără să înregistrezi cheia sau corpurile complete ale mesajelor cu date personale.
5. Tratează webhook-urile pentru respingeri și plângeri: oprește trimiterea către adresele care sunt respinse definitiv sau care te marchează ca spam.

Un prompt care acoperă elementele de bază:

Trimite email tranzacțional cu [FURNIZOR] folosind secretul de server [NUME_VARIABILĂ], de la „Acme hello@mail.acme.com”. Trimite un email de bun venit după înscriere și o confirmare de rezervare după ce rezervarea este salvată. Păstrează șabloanele în cod, cu o versiune text simplu alături de HTML. Pune trimiterile în coadă și reîncearcă erorile temporare de până la trei ori. Înregistrează erorile cu eroarea furnizorului, dar niciodată cheia API. Adaugă un endpoint de webhook care marchează adresele ca nelivrabile la respingeri definitive și plângeri, și le sare la trimiterile viitoare.

Emailurile de cont — linkurile de verificare, linkurile magice și resetările de parolă — fac parte din autentificare. Cum adaugi autentificare în aplicația ta explică cum se leagă aceste fluxuri; fă aceste linkuri de unică folosință și cu valabilitate scurtă.

Obiceiuri pentru livrabilitate

Autentificarea te face luat în considerare. Comportamentul te ține în inbox.

• Trimite doar ce se așteaptă oamenii. Înscrieri confirmate, consimțământ clar pentru marketing, fără liste cumpărate.
• Fă dezabonarea ușoară la orice ce nu este strict tranzacțional și respect-o imediat.
• Încălzește domeniile noi. Un domeniu nou care trimite mii de mesaje din prima zi pare suspect. Începe cu emailurile tranzacționale și crește volumul treptat.
• Menține listele curate. Scoate imediat adresele respinse definitiv și ia în calcul eliminarea persoanelor care nu au deschis nimic de mult timp.
• Scrie ca un om. Un subiect clar, un nume From recognoscibil, o parte text simplu, puține imagini și linkuri către propriul domeniu. Evită scurtătoarele de linkuri.
• Monitorizează. Înregistrează-ți domeniul în Google Postmaster Tools și citește din când în când rapoartele DMARC.
• Folosește un reply-to real, pe care îl citește cineva. Răspunsurile sunt un semnal bun și feedback util.

Testează fără să trimiți spam nimănui

• Folosește modul de test sau sandbox al furnizorului, acolo unde există, sau trimite către adrese pe care le deții.
• În dezvoltare, trimite către o căsuță de test care primește tot în loc de utilizatori reali; o bază de date plină cu adrese care arată real este o cale ușoară să trimiți emailuri din greșeală unor străini.
• Verifică fiecare șablon în câteva clienți — Gmail în browser, aplicația de mail de pe telefon, Outlook — și în modul întunecat.
• Uită-te la anteturile unui email de test: arată dacă au trecut SPF, DKIM și DMARC.

Bazele juridice

Regulile diferă de la o țară la alta. În linii mari, emailul de marketing necesită consimțământ în multe locuri, trebuie să identifice expeditorul și trebuie să ofere o dezabonare funcțională; emailul tranzacțional este tratat diferit, dar nu ar trebui folosit ca să strecori marketing. Dacă strângi adrese de pe o pagină de listă de așteptare, spune ce vei trimite și stoca, când și cum s-a înscris fiecare persoană. Când ai dubii, verifică regulile din țările în care sunt utilizatorii tăi.

Lista de verificare pentru email

• Furnizor de trimitere ales; cheia API stocată ca secret de server
• Trimitere de pe propriul domeniu sau subdomeniu, nu de pe o căsuță gratuită
• Înregistrările SPF, DKIM și DMARC adăugate și care trec verificarea
• Emailul tranzacțional și cel de marketing separate
• Trimiteri puse în coadă și reîncercate; rezultate înregistrate
• Webhook-uri pentru respingeri și plângeri tratate
• Dezabonare la emailurile non-tranzacționale, respectată imediat
• Șabloane testate în mai mulți clienți; emailurile de test nu ajung niciodată la utilizatori reali

Trimiterea de email dintr-o aplicație Mythex

Mythex nu include un serviciu integrat de trimitere de email pentru aplicațiile pe care le construiești, așa că aduci tu un furnizor, precum Resend, SendGrid sau Postmark. Stochează cheia API ca secret de proiect — agentul îl poate cere prin un card de secrete în chat — și cere emailurile de care ai nevoie în cuvinte simple. Documentația are un prompt de pornire în trimiterea de email din aplicația ta. Dacă ți-ai cumpărat domeniul prin Mythex în planul Pro, poți adăuga înregistrările TXT și CNAME ale furnizorului în setările DNS ale domeniului; vezi domeniile personalizate.

Întrebări