Како да испраќате е-пошта од вашата апликација (и да стигнува во примачкото)

За да испраќате е-пошта од вашата апликација сигурно, користете провајдер за испраќање е-пошта, а не сопствено сандаче, испраќајте од адреса на ваш домен и додајте ги DNS записите што ги дава провајдерот, така што SPF, DKIM и DMARC да поминуваат. Držете ја трансакциската е-пошта — лозинки, потврди, фактури — одделно од маркетиншката, испраќајте секоја само до луѓе што ја очекуваат, и управувајте со неиспорачаните пораки и одјавите. Прво средете ја автентикацијата; тоа е најчестата причина app е-поштата да заврши во спам.

Трансакциска наспроти маркетиншка е-пошта

Овие два вида е-пошта во кодот изгледаат слично, но инбокс провајдерите и законот ги третираат многу различно.

Држете ги одвоени. Ако маркетиншка кампања добие пријави за спам, не сакате тоа да ги погоди и лозинките за промена што се испраќаат од истиот тек. Вообичаен пристап се одделни поддомени — на пример mail.example.com за сметките и news.example.com за билтените — а некои провајдери ги одвојуваат и внатрешно. Postmark, на пример, ги опишува своите трансакциски и емитувачки „текови на пораки“ како работење на одделна инфраструктура за испраќање, од септември 2026 година.

Избор на провајдер

Вашата апликација не треба сама да испраќа е-пошта од свој сервер. Провајдерите за испраќање ја управуваат инфраструктурата, репутацијата на IP адресите, повторните обиди и обработката на неиспорачани пораки. Познати опции се Postmark, Resend, SendGrid, Amazon SES и Mailgun; секој има HTTP API и SMTP пристап, а цените и плановите се менуваат, па споредете ги на нивните страници.

Што да споредите:

• Фокус. Некои провајдери се концентрирани на трансакциска е-пошта; други ги комбинираат трансакциската и маркетиншката.
• Искуство за програмери. Јасен API, официјални библиотеки за вашиот јазик, корисни логови кои покажуваат дали секоја порака е испорачана, вратена или означена како спам.
• Webhook-ови за неиспорачани, пријави и испораки, за апликацијата да може да реагира.
• Шаблони — зачувани кај провајдерот или во вашиот код. Чувањето во кодот ги прави верзионирани и подложни на тестирање.
• Регион и обработка на податоци, ако имате барања за тоа каде се обработуваат податоците.
• Трошок при вашиот обем, вклучувајќи што се случува кога ќе ја надминете бесплатната големина.

За билтени до список, алатка за маркетинг по е-пошта често е подобар избор отколку да градите кампањи во самата апликација.

Поставете го вашиот домен за испраќање

Испраќајте од ваш домен — hello@example.com, а не адреса на Gmail или Outlook. Пораката од бесплатно сандаче, испратена преку услуга од трета страна, не минува проверките за автентикација и најверојатно ќе биде филтрирана.

Размислете за поддомен наменет само за испраќање. Resend, на пример, препорачува испраќање од поддомени како updates.example.com за да се изолира репутацијата на испраќањето (од септември 2026). Исто така, ги држи DNS записите за е-пошта одделно од главната страница.

Провајдерот потоа ви дава DNS записи што треба да ги додадете таму каде се управува DNS-от на вашиот домен. Ако DNS ви е нов, како функционираат домените и DNS прво ги објаснува записите.

SPF

SPF (Sender Policy Framework) е TXT запис со список на сервери што смеат да испраќаат е-пошта за вашиот домен. Примачот проверува дали серверот што испраќа е на списокот.

• Доменот треба да има само еден SPF запис. Ако додадете провајдер, спојте го во постоечкиот запис, не додавајте втор.
• SPF при евалуација дозволува најмногу 10 DNS барања; долги синџири од include: записи можат да ја надминат оваа граница и да предизвикаат неуспех.
• Многу провајдери го поставуваат SPF на поддомен за враќање (return-path) што ви го бараат да го создадете, па можеби воопшто нема да го допирате главниот SPF запис.

DKIM

DKIM (DomainKeys Identified Mail) додава криптографски потпис на секоја порака. Провајдерот потпишува со приватен клуч; вие го објавувате соодветниот јавен клуч како DNS запис (TXT или CNAME, во зависност од провајдерот). Примачите го проверуваат потписот за да потврдат дека пораката е од овластен испраќач и дека не е изменета по патот.

Чекорот „провери домен“ кај провајдерот во голема мера е за DKIM. Не го прескокнувајте.

DMARC

DMARC ги поврзува другите две. Тоа е TXT запис на _dmarc.yourdomain.com кој им кажува на примачите:

• Усогласеност (alignment): доменот во видливата адреса „Од“ мора да се совпаѓа со доменот што поминал SPF или DKIM.
• Политика: што да се направи со пораките што не минуваат — p=none (само известување), p=quarantine (се третира како сомнително, често спам) или p=reject.
• Извештаи: на која адреса да се испраќаат агрегираните извештаи (rua=), за да видите кој испраќа во име на вашиот домен.

Разумен пат е да почнете со p=none и адреса за извештаи, да потврдите дека легитимната пошта минува, па да преминете на quarantine и на крајот на reject. Строга политика исто така многу го отежнува лажното претставување на вашиот домен од други.

Што бара Gmail

Од септември 2026 година, правилата на Google за испраќачи велат:

• Сите испраќачи до лични сметки на Gmail треба да имаат SPF или DKIM, валиден прав и обратен DNS за серверите што испраќаат, TLS и стапка на спам во Postmaster Tools под 0,3%.
• Масовни испраќачи (повеќе од 5.000 пораки дневно до Gmail) треба да имаат SPF и DKIM, DMARC запис (дозволена е политика p=none), усогласеност на доменот „Од“ и едноклучна одјава плус видлив линк за одјава кај маркетиншките и претплатничките пораки.

Провајдерот ги среди серверските делови. DNS записите и управувањето со одјавите се ваша одговорност. Дури и ако сте далеку под 5.000 дневно, исполнувањето на правилата за масовни испраќачи е најлесниот начин да бидете безбедни.

Вградете го испраќањето во апликацијата

Кога ќе се верификува доменот:

1. Чувајте го API клучот како тајна на серверот — никогаш во кодот на предниот дел. Видете што се променливи на околината и тајни.
2. Испраќајте од серверот, по успешното дејство што ја активира е-поштата.
3. Не правете го корисникот да чека на е-пошта. За нешто повеќе од наједноставна апликација, ставете го испраќањето во ред и повторувајте го при привремени грешки, за бавен одговор од провајдерот да не го забави регистрацијата.
4. Запишувајте го исходот — ID на пораката и статусот од провајдерот — без да го запишувате клучот или целосните содржини на пораките со лични податоци.
5. Обработувајте webhook-ови за неиспорачани пораки и пријави: престанете да испраќате на адреси што трајно се неиспорачани или ве пријавиле за спам.

Промпт што ги покрива основите:

Испраќај трансакциска е-пошта со [PROVIDER] користејќи ја серверската тајна [ENV_NAME], од „Acme hello@mail.acme.com“. Испрати е-порака добредојде по регистрација и потврда за резервација откако ќе се зачува резервацијата. Чувај ги шаблоните во кодот, со текстуална верзија покрај HTML. Испраќањата стави ги во ред и повторувај привремени грешки до три пати. Запишувај грешки со грешката од провајдерот, но никогаш го клучот од API. Додај webhook крајна точка што ги означува адресите како неиспорачливи при трајни неиспорачувања и пријави, и прескокнувај ги во идните испраќања.

Сметките за е-пошта — линкови за верификација, магични линкови и промена на лозинка — се дел од најавувањето. Како да додадете најава во апликацијата опфаќа како се поврзуваат овие текови; направете ги овие линкови еднократни и краткотрајни.

Навики за испорака

Автентикацијата ве прави доверливи. Однесувањето ве задржува во инбоксот.

• Испраќајте само она што луѓето го очекуваат. Потврдени регистрации, јасна согласност за маркетинг, без купени листи.
• Олеснете ја одјавата кај сè што не е строго трансакциско, и почитувајте ја веднаш.
• Загрејте ги новите домени. Нов домен што на првиот ден испраќа илјадници пораки изгледа сомнително. Почнете со трансакциската пошта и постепено зголемувајте го обемот.
• Чистете ги списоците. Отстранувајте трајно неиспорачани адреси веднаш и размислете за отстранување на луѓе што долго време ништо не отвориле.
• Пишувајте како човек. Јасен наслов, препознатливо име „Од“, текстуална верзија, малку слики и линкови до ваш домен. Избегнувајте скратувачи на линкови.
• Следете. Регистрирајте го доменот во Google Postmaster Tools и повремено читајте ги DMARC извештаите.
• Користете вистинска адреса за одговор што некој ја чита. Одговорите се добар сигнал и корисна повратна информација.

Тестирање без спамирање никого

• Користете тест-режим или sandbox на провајдерот таму каде што постои, или испраќајте на адреси што ви припаѓаат.
• Во развој, испраќајте до тест-сандаче што прима сè наместо до вистински корисници; семе-база полна со адреси што изгледаат вистински е лесен начин случајно да испратите е-пошта до непознати.
• Проверете секој шаблон во неколку клиенти — Gmail во прелистувач, апликација за пошта на телефон, Outlook — и во темен режим.
• Погледнете ги заглавјата на тест-пораката: тие покажуваат дали SPF, DKIM и DMARC минале.

Правни основи

Правилата се разликуваат од земја до земја. Генерално, маркетиншката е-пошта во многу места бара согласност, мора да го идентификува испраќачот и мора да нуди функционална одјава; трансакциската е-пошта се третира поинаку, но не треба да се користи за потајно вметнување маркетинг. Ако собирате адреси од страница за листа на чекање, кажете што и кога ќе испраќате и чувате и како секој се пријавил. Кога сте во недоумица, проверете ги правилата таму каде што се вашите корисници.

Список за проверка за е-пошта

• Избран провајдер за испраќање; API клучот чуван како тајна на серверот
• Испраќање од ваш домен или поддомен, не од бесплатно сандаче
• Додадени и минуваат SPF, DKIM и DMARC записи
• Трансакциската и маркетиншката пошта се одделени
• Испраќањата се ставени во ред и повторувани; исходите се запишани
• Обработени webhook-ови за неиспорачани пораки и пријави
• Одјава кај не-трансакциската пошта, почитувана веднаш
• Шаблоните тестирани во неколку клиенти; тест-пошта никогаш не стигнува до вистински корисници

Испраќање е-пошта од апликација на Mythex

Mythex не вклучува вграден сервис за испраќање е-пошта за апликациите што ги градите, па донесувате провајдер, како Resend, SendGrid или Postmark. Чувајте го неговиот API клуч како тајна на проектот — агентот може да побара тајна преку картичка за тајни во разговорот — и побарајте ги е-порачките што ви требаат со едноставни зборови. Документацијата има почетен промпт во испраќање е-пошта од вашата апликација. Ако го купивте доменот преку Mythex на Pro, можете да ги додадете TXT и CNAME записите на провајдерот во DNS поставките на доменот; видете сопствени домени.

Прашања