Как да изпращате имейли от вашето приложение (и да попадат във входящата поща)

За да изпращате имейли от приложението си надеждно, използвайте доставчик на имейл услуги вместо собствена пощенска кутия, изпращайте от адрес в собствен домейн и добавете DNS записите, които доставчикът ви дава, така че SPF, DKIM и DMARC да минават успешно. Пазете транзакционните имейли – потвърждения на парола, разписки, потвърждения – отделно от маркетинговите, изпращайте всеки вид само до хора, които го очакват, и обработвайте отскочилите съобщения и отписванията. Първо наредете удостоверяването – то е най-честата причина имейлите от приложения да попадат в спама.

Транзакционен срещу маркетингов имейл

Тези два вида имейли изглеждат подобно в кода, но входящите пощи и законите ги третират много различно.

Дръжте ги отделно. Ако маркетингова кампания получи оплаквания за спам, не искате смяната на паролите от същия поток да пострада заради нея. Често срещан подход са отделни поддомейни – например mail.example.com за имейли към акаунти и news.example.com за бюлетини, а някои доставчици разделят двата вида сами. Postmark, например, описва своите транзакционни и масови „потоци на съобщения“ като работещи на отделна инфраструктура за изпращане към септември 2026 г.

Избор на доставчик

Приложението ви не трябва да изпраща имейли само от собствения си сървър. Доставчиците на имейл услуги поемат инфраструктурата, репутацията на IP адресите, повторните опити и обработката на отскочилите съобщения. Познати варианти са Postmark, Resend, SendGrid, Amazon SES и Mailgun; всеки има HTTP API и SMTP достъп, а цените и плановете се променят, затова ги сравнете на техните сайтове.

На какво да обърнете внимание:

• Фокус. Някои доставчици се концентрират върху транзакционни имейли, други съчетават транзакционни и маркетингови.
• Удобство за разработчици. Ясен API, официални библиотеки за вашия език, полезни записи, които показват дали всяко съобщение е доставено, отскочило или маркирано като спам.
• Webhooks за отскочили съобщения, оплаквания и доставки, за да може приложението ви да реагира.
• Шаблони – съхранявани при доставчика или във вашия код. Ако ги пазите в кода, те са versioned и могат да се тестват.
• Регион и обработка на данните, ако имате изисквания къде се обработват данните.
• Цена при вашия обем, включително какво става, когато надхвърлите безплатния лимит.

За бюлетини до списък специализиран инструмент за бюлетини или имейл маркетинг често е по-подходящ от това да вграждате функции за кампании в приложението си.

Настройте домейна за изпращане

Изпращайте от собствен домейн – 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 на поддомейн за връщане, който ви карат да създадете, така че може изобщо да не пипате основния си 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 и процент на спам под 0,3% в Postmaster Tools.
• Масовите податели (повече от 5000 съобщения на ден към Gmail) трябва да имат SPF и DKIM, DMARC запис (допустима е политика p=none), съвпадение на домейна в „От“ и едно-кликово отписване плюс видима връзка за отписване в маркетинговите и абонаментните съобщения.

Доставчикът ви поема сървърните части. DNS записите и обработката на отписванията са ваша отговорност. Дори ако сте далеч от 5000 на ден, спазването на правилата за масови податели е най-простият начин да сте в безопасност.

Вградете изпращането в приложението

След като домейнът е потвърден:

1. Съхранявайте API ключа като тайна на сървъра – никога в кода за интерфейса. Вижте какво представляват променливите на средата и тайните.
2. Изпращайте от сървъра след като действието, което задейства имейла, е успешно.
3. Не карайте потребителя да чака имейла. За нещо по-голямо от най-простото приложение поставете изпращането на опашка и повтаряйте при временни грешки, за да не забави бавен отговор на доставчика регистрацията.
4. Записвайте резултата – идентификатора и статуса на съобщението от доставчика – без да записвате ключа или пълното съдържание с лични данни.
5. Обработвайте webhooks за отскочили съобщения и оплаквания: спрете изпращането към адреси, които окончателно отскачат или ви маркират като спам.

Подкана, която покрива основите:

Изпращай транзакционни имейли с [PROVIDER], като използваш тайната на сървъра [ENV_NAME], от „Acme hello@mail.acme.com“. Изпрати имейл добре дошли след регистрация и потвърждение на резервация след запазване. Пази шаблоните в кода, с текстова версия заедно с HTML. Поставяй изпращанията на опашка и повтаряй временните грешки до три пъти. Записвай грешките с отговора на доставчика, но никога не записвай API ключа. Добави webhook крайна точка, която маркира адресите като недоставяеми при окончателни отскоци и оплаквания, и пропускай тези адреси за в бъдеще.

Имейлите за акаунта – линкове за потвърждение, magic links и смяна на парола – са част от входа в системата. Как да добавите вход в приложението си обяснява как се свързват тези потоци; направете линковете еднократни и с кратък живот.

Навици за доставимост

Удостоверяването ви прави доверени. Поведението ви държи в входящата поща.

• Изпращайте само това, което хората очакват. Потвърдени регистрации, ясно съгласие за маркетинг, без купени списъци.
• Направете отписването лесно при всичко, което не е строго транзакционно, и го спазвайте веднага.
• Загрявайте новите домейни. Нов домейн, който в първия ден изпраща хиляди съобщения, изглежда подозрително. Започнете с транзакционната поща и увеличавайте обема постепенно.
• Поддържайте списъците чисти. Премахвайте окончателно отскочилите адреси незабавно и обмислете премахване на хора, които отдавна не са отворили нищо.
• Пишете като човек. Ясен заглавен ред, разпознаваемо име в „От“, текстова част, малко изображения и връзки към собствения ви домейн. Избягвайте съкращаващи връзки.
• Наблюдавайте. Регистрирайте домейна си в Google Postmaster Tools и от време на време преглеждайте DMARC отчетите.
• Използвайте реален адрес за отговор, който някой чете. Отговорите са добър сигнал и полезна обратна връзка.

Тестване, без да спамите никого

• Използвайте тестовия режим или sandbox на доставчика, където има такъв, или изпращайте до адреси, които са ваши.
• В разработка изпращайте до тестова входяща кутия, която приема всичко, вместо до реални потребители; база данни, пълна с адреси, които изглеждат истински, е лесен начин да пишете на непознати по погрешка.
• Проверявайте всеки шаблон в няколко клиента – Gmail в браузър, пощенско приложение на телефона, Outlook – и в тъмен режим.
• Разгледайте заглавките на тестовия имейл: те показват дали SPF, DKIM и DMARC са минали успешно.

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

Правилата се различават по държави. В общи линии маркетинговите имейли изискват съгласие на много места, трябва да посочват изпращача и да предлагат работещо отписване; транзакционните имейли се третират различно, но не бива да се използват, за да се вмъква маркетинг. Ако събирате адреси от страница за списък на чакащите, кажете какво ще изпращате и съхранявате, както и кога и как се е регистрирал всеки човек. При съмнение проверете правилата там, където са вашите потребители.

Контролен списък за имейли

• Избран доставчик на имейли; API ключът е съхранен като тайна на сървъра
• Изпращане от собствен домейн или поддомейн, а не от безплатен адрес
• Добавени SPF, DKIM и DMARC записи и те минават успешно
• Транзакционната и маркетинговата поща са разделени
• Изпращанията са на опашка и се повтарят; резултатите се записват
• Обработват се webhooks за отскочили съобщения и оплаквания
• Отписване при не-транзакционната поща, спазвано незабавно
• Шаблоните са тествани в няколко клиента; тестовата поща никога не стига до реални потребители

Изпращане на имейли от приложение в Mythex

Mythex не включва вградена услуга за изпращане на имейли за приложенията, които създавате, затова използвате доставчик като Resend, SendGrid или Postmark. Съхранете API ключа му като тайна на проекта – агентът може да поиска това с карта за тайни в чата – и опишете с прости думи имейлите, които ви трябват. Документацията има примерна подкана в изпращане на имейл от вашето приложение. Ако сте купили домейна си през Mythex в Pro, можете да добавите TXT и CNAME записите на доставчика в DNS настройките на домейна; вижте собствени домейни.

Въпроси