SMTP

SMTP, или Simple Mail Transfer Protocol, — сетевой протокол передачи электронной почты. Он используется, когда почтовый клиент отправляет письмо на Mail Server, а также когда один почтовый сервер передает сообщение другому серверу получателя.

SMTP отвечает прежде всего за отправку и маршрутизацию Email. Для получения и синхронизации почты пользователь обычно применяет другие протоколы и API, например IMAP.

Через SMTP работают корпоративные почтовые системы, формы обратной связи, интернет-магазины, CRM, ERP, сервисы уведомлений и приложения, которые отправляют пользователям письма.

SMTP можно представить как транспортную систему электронной почты: он принимает сообщение от отправителя и помогает доставить его на почтовый сервер получателя.

Что такое SMTP простыми словами

Пользователь пишет письмо в почтовом приложении и нажимает «Отправить».

Дальше происходит примерно такая цепочка:

User
↓
Mail Client
↓ SMTP
Outgoing Mail Server
↓ SMTP
Recipient Mail Server

SMTP определяет, как серверы договариваются о передаче сообщения, как указываются отправитель и получатель и как подтверждается результат доставки на очередной почтовый узел.

Расшифровка SMTP

SMTP расшифровывается как Simple Mail Transfer Protocol — простой протокол передачи почты.

Несмотря на слово Simple, современная почтовая инфраструктура включает множество дополнительных механизмов: TLS, Authentication, DNS, SPF, DKIM, DMARC, Anti-spam и очереди сообщений.

Для чего нужен SMTP

SMTP используется для:

• отправки писем из почтового клиента;
• передачи Email между Mail Servers;
• отправки уведомлений из сайтов;
• транзакционных писем интернет-магазинов;
• восстановления пароля;
• отправки счетов и чеков;
• уведомлений CRM и ERP;
• мониторинговых Alerts;
• автоматических отчетов;
• рассылок через специализированные сервисы.

Как работает SMTP

Упрощенно процесс выглядит так:

1. Приложение формирует Email.
2. Подключается к SMTP Server.
3. Проходит Authentication, если она требуется.
4. Передает Envelope Sender и список получателей.
5. Передает содержимое письма.
6. SMTP Server принимает сообщение в очередь.
7. Сервер определяет Mail Server домена получателя через DNS.
8. Пытается передать письмо следующему серверу.

SMTP Client

SMTP Client — программа или сервис, инициирующий передачу письма.

Им может быть:

• почтовое приложение;
• сайт;
• Backend;
• CRM;
• 1С;
• скрипт;
• система мониторинга;
• другой Mail Server.

SMTP Server

SMTP Server принимает почтовые сообщения и передает их дальше согласно настройкам маршрутизации.

Он может принимать письма от авторизованных пользователей, хранить их в Queue и устанавливать соединения с серверами доменов получателей.

SMTP и TCP/IP

SMTP работает как прикладной протокол поверх TCP.

SMTP
↓
TCP
↓
IP

TCP обеспечивает надежный поток данных между двумя сетевыми узлами, а SMTP определяет команды и формат почтового диалога.

SMTP-порты

В почтовой инфраструктуре используются разные Ports для разных сценариев.

Конкретные настройки необходимо брать у почтового провайдера или администратора.

Почему порт 25 часто не используют в приложении

Port 25 предназначен прежде всего для Server-to-Server Mail Transfer.

Для отправки писем пользователями и приложениями обычно используют Submission Service с Authentication.

Кроме того, хостинг-провайдеры могут ограничивать исходящий Port 25 для борьбы со Spam.

SMTP Submission

Submission — прием исходящей почты от авторизованного пользователя или приложения.

В этом сценарии клиент подключается к Mail Server, проходит Authentication и передает письмо для дальнейшей доставки.

Application
↓ Authenticated SMTP
Submission Server
↓
Internet Mail Servers

SMTP Authentication

SMTP Authentication подтверждает, что клиент имеет право отправлять письма через данный сервер.

Без Authentication неправильно настроенный Mail Server может превратиться в Open Relay и использоваться злоумышленниками для Spam.

Логин и пароль SMTP

Приложению часто выдают отдельные SMTP Credentials.

Например:

Host: smtp.example.com
Port: 587
Username: notifications@example.com
Password: ********

Credentials являются секретом и не должны храниться прямо в исходном коде.

SMTP и TLS

SMTP Traffic может защищаться TLS.

Шифрование необходимо, чтобы Credentials и содержимое писем не передавались открыто между клиентом и сервером на соответствующем участке соединения.

STARTTLS

STARTTLS позволяет начать SMTP-соединение и затем переключить его на защищенный TLS Channel.

После успешного TLS Handshake дальнейший SMTP Traffic передается внутри зашифрованного соединения.

Implicit TLS

В некоторых конфигурациях TLS устанавливается сразу при создании TCP Connection, до передачи обычных SMTP-команд.

Клиент и Server должны быть настроены на одинаковую модель.

SMTP и HTTPS

SMTP и HTTPS решают разные задачи.

HTTPS используется для Web Requests, а SMTP — для передачи Email.

Современный Email Provider может также предоставлять HTTP API для отправки писем, поэтому приложение иногда может выбирать между SMTP и REST API.

SMTP или Email API

Для простой интеграции SMTP часто достаточно. Для большого объема транзакционной почты API может предоставлять более удобную аналитику и управление событиями.

SMTP и IMAP

SMTP используется для отправки почты, а IMAP — для чтения и синхронизации писем в Mailbox.

SMTP и POP3

POP3 также относится к получению почты, а не к ее отправке.

Поэтому в классической настройке почтового клиента SMTP отвечает за Outgoing Mail, а IMAP или POP3 — за Incoming Mail.

SMTP Envelope

При передаче Email SMTP использует так называемый Envelope.

В нем указываются технический отправитель и получатели сообщения.

Эти значения не обязательно полностью совпадают с визуальными Headers From и To внутри письма.

MAIL FROM

SMTP-команда MAIL FROM задает Envelope Sender.

Этот адрес важен для обработки ошибок доставки и некоторых антиспам-механизмов.

RCPT TO

RCPT TO задает Envelope Recipient.

Если письмо направляется нескольким пользователям, команда может повторяться для каждого адресата.

DATA

После указания отправителя и получателей Client передает команду DATA и затем содержимое Email.

В него входят Headers и Body.

Пример SMTP-диалога

EHLO client.example.com
MAIL FROM:
RCPT TO:
DATA
Subject: Test

Hello
.

Это упрощенный пример. В реальном соединении могут присутствовать TLS, Authentication и дополнительные возможности.

HELO и EHLO

В начале сессии SMTP Client представляет себя серверу.

EHLO используется расширенной моделью SMTP и позволяет Server сообщить поддерживаемые Extensions.

SMTP Extensions

Современный SMTP расширяет базовый протокол дополнительными возможностями, например Authentication, TLS и передачей более сложных типов данных.

Client узнает поддерживаемые функции после соответствующего приветствия Server.

Email Headers

Внутри сообщения находятся Headers:

From: Company 
To: user@example.net
Subject: Your order
Date: ...

Они описывают письмо на прикладном уровне.

From и Envelope Sender

Поле From, которое пользователь видит в Mail Client, и SMTP Envelope Sender решают разные задачи.

Антиспам-системы анализируют их вместе с SPF, DKIM и DMARC.

To, Cc и Bcc

To и Cc являются видимыми Headers письма.

Bcc используется для отправки копии получателю без отображения его адреса остальным участникам.

Фактическая доставка определяется SMTP Envelope Recipients.

Email Body

Body содержит основной текст письма.

Он может быть Plain Text, HTML или включать несколько представлений через MIME.

MIME

MIME расширяет формат электронной почты и позволяет передавать:

• HTML;
• вложения;
• изображения;
• разные Character Encodings;
• несколько частей сообщения.

SMTP транспортирует такое сообщение как почтовые данные.

SMTP и вложения

Файл не передается как отдельное независимое SMTP-соединение.

Attachment кодируется как часть MIME Message.

Из-за кодирования размер письма может быть больше исходного размера файла.

Ограничение размера письма

Mail Servers устанавливают максимальный размер сообщения.

Если пользователь пытается отправить очень большой архив, Server может отклонить его.

Для больших файлов часто удобнее использовать Object Storage или File Sharing и отправлять ссылку.

SMTP Queue

Mail Server обычно не обязан доставить письмо мгновенно.

После приема оно помещается в Queue.

Server пытается найти Mail Server получателя и передать сообщение.

Почему письмо может идти несколько минут

Получающий Server может временно не отвечать, DNS может быть недоступен или удаленная сторона возвращает временную ошибку.

Тогда отправляющий Mail Server оставляет сообщение в Queue и повторяет попытку позже.

Retry

SMTP рассчитан на Store-and-forward модель.

Временная ошибка не обязательно означает окончательную потерю письма.

Server может повторять доставку по собственной политике до истечения допустимого срока.

SMTP Status Codes

SMTP Server возвращает числовые ответы.

Временная ошибка SMTP

Ответ класса 4xx обычно сообщает, что доставку стоит попробовать повторить.

Например, Mailbox Server временно перегружен.

Постоянная ошибка SMTP

Ответ 5xx может означать, что адрес не существует, сообщение нарушает Policy или Server окончательно отказывается его принимать.

Бесконечно повторять такую доставку обычно нет смысла.

Bounce

Bounce — уведомление о невозможности доставки письма.

Оно может появиться из-за:

• несуществующего Mailbox;
• неверного домена;
• переполненного ящика;
• отклонения Anti-spam;
• проблемы Policy;
• истечения срока Retry.

Hard Bounce и Soft Bounce

В системах Email Marketing ошибки часто делят на Hard и Soft Bounce.

Hard Bounce обычно связан с устойчивой причиной, например несуществующим адресом.

Soft Bounce — с временной проблемой.

Точная классификация зависит от почтового сервиса.

DNS и SMTP

SMTP тесно связан с DNS.

Чтобы отправить письмо на:

user@example.com

Mail Server должен определить, какие серверы принимают почту домена example.com.

MX Record

MX, или Mail Exchange Record, указывает Mail Servers, принимающие Email для домена.

Отправляющий Server запрашивает DNS и получает список Mail Exchangers.

Приоритет MX

Для домена может быть несколько MX Records с разным приоритетом.

Это позволяет использовать резервные Mail Servers.

Конкретная логика выбора определяется SMTP и DNS-конфигурацией.

SMTP и A Record

После получения имени Mail Server через MX необходимо определить его IP Address через DNS A или AAAA Record.

Только затем устанавливается сетевое соединение.

SMTP и IPv6

Mail Server может обмениваться почтой через IPv4 или IPv6 при корректной DNS, Routing и Firewall Configuration.

При Dual Stack необходимо следить за репутацией и настройками обоих сетевых путей.

SPF

SPF позволяет домену через DNS указать, какие почтовые системы имеют право отправлять Email от его имени в рамках проверяемой модели Envelope Sender.

Получающий Server может использовать эту информацию как один из антиспам-сигналов.

Зачем нужен SPF

Без SPF злоумышленнику проще попытаться отправлять письма, визуально связанные с чужим доменом.

SPF не решает проблему подделки почты полностью, но является важной частью современной Email Authentication.

DKIM

DKIM добавляет к письму криптографическую подпись.

Mail Server получателя получает Public Key из DNS и проверяет, соответствует ли Signature содержимому сообщения.

Это помогает подтвердить, что подписанные части письма не были незаметно изменены после подписания.

Private Key DKIM

Отправляющий Mail Server хранит Private Key и подписывает им исходящие письма.

Этот ключ необходимо защищать как Secret.

DMARC

DMARC связывает проверки SPF и DKIM с доменом, видимым пользователю в поле From, и позволяет владельцу домена публиковать Policy обработки писем, не прошедших проверки.

Также DMARC поддерживает механизм отчетности.

SPF, DKIM и DMARC

На практике для корпоративного домена желательно корректно настроить все три механизма.

SMTP и Spam

Email является популярным каналом злоупотреблений, поэтому получающие серверы анализируют множество сигналов.

На доставляемость могут влиять:

• репутация IP;
• репутация Domain;
• SPF;
• DKIM;
• DMARC;
• содержание письма;
• жалобы пользователей;
• частота отправки;
• качество списка получателей.

Почему письмо попадает в Spam

Успешный SMTP Response означает, что принимающий сервер принял письмо для дальнейшей обработки, но не гарантирует попадание во «Входящие».

После SMTP Delivery сообщение может быть классифицировано Anti-spam системой и помещено в Spam Folder.

SMTP Delivery не равна прочтению

SMTP не сообщает, прочитал ли пользователь письмо.

Даже успешная доставка означает только определенный этап передачи сообщения.

Open Tracking и Click Tracking реализуются на более высоком прикладном уровне и также имеют ограничения.

Open Relay

Open Relay — Mail Server, который позволяет посторонним отправлять через себя Email произвольным получателям без нормальной Authorization.

Такой сервер быстро используется спамерами и может попасть в Reputation Blocklists.

Как избежать Open Relay

Mail Server должен четко различать:

• локальных получателей;
• авторизованных пользователей;
• доверенные сети;
• внешние попытки Relay.

Пересылка внешней почты должна разрешаться только согласно установленной Policy.

SMTP и Firewall

Mail Server должен принимать только необходимый Mail Traffic.

Например, Internet-facing MX Server принимает Server-to-Server SMTP, а Submission Server может иметь отдельные Rules для клиентов.

Management Ports при этом не следует открывать всему интернету.

Исходящий SMTP и Firewall

Некоторым Application Servers не требуется напрямую отправлять SMTP в интернет.

Можно разрешить им соединение только с корпоративным Mail Relay.

Application → Corporate SMTP Relay: allow
Application → Internet SMTP: deny

Так исходящая почта централизуется.

SMTP Relay

SMTP Relay принимает письмо от доверенного приложения или Server и передает его дальше.

Это позволяет не настраивать внешнюю Email Delivery отдельно на каждом приложении.

Зачем нужен корпоративный SMTP Relay

Через Relay удобно централизовать:

• Authentication;
• DKIM Signing;
• Logging;
• Rate Limits;
• IP Reputation;
• правила отправителей.

SMTP Smart Host

Smart Host — промежуточный Mail Server, через который организация направляет исходящую почту вместо прямой доставки каждому домену получателя.

Например, локальная CRM передает все Email специализированному провайдеру.

SMTP и NAT

Если Mail Server находится за NAT, внешняя и внутренняя адресация должны быть согласованы с DNS и Firewall.

Для входящего SMTP может использоваться DNAT, а для исходящего — стабильный Public IP.

Почему стабильный Public IP важен для Mail Server

Получающие почтовые системы учитывают IP Reputation и DNS Configuration.

Постоянная предсказуемая инфраструктура обычно удобнее для управления доставляемостью, чем случайная смена внешних адресов.

Reverse DNS

Mail Systems часто учитывают PTR Record, связывающий Public IP с Domain Name.

Некорректный Reverse DNS может ухудшить доверие принимающих серверов.

HELO Name и DNS

Mail Server представляет себя во время SMTP Session.

Корректное согласование имени Server, DNS и сетевой конфигурации является частью нормальной почтовой инфраструктуры.

SMTP и облако

В Cloud приложение часто не поднимает собственный Mail Server, а использует Managed Email Provider.

Application
↓ SMTP or API
Email Provider
↓
Recipient Mail Servers

Это снимает часть задач по Reputation, очередям и доставке.

Почему облачные провайдеры ограничивают SMTP

Открытый исходящий SMTP с виртуальных машин может использоваться для Spam.

Поэтому Cloud Provider может применять ограничения к определенным Ports или требовать отдельного согласования.

Для приложений часто проще использовать внешний SMTP Relay.

SMTP и Docker

Container Application не обязательно должен запускать собственный Mail Server.

Обычно Backend получает SMTP Host и Credentials через Configuration или Secrets и отправляет Email внешнему Relay.

SMTP Credentials в Docker

Пароль нельзя записывать непосредственно в Dockerfile или публичный Compose Repository.

Используйте Secrets, Environment Management или специализированное хранилище секретов.

SMTP и Kubernetes

Kubernetes Application также может использовать внешний SMTP Service.

Credentials хранятся в Secret Management, а Network Policy может ограничивать исходящие соединения только разрешенным Mail Endpoint.

SMTP и Serverless

Serverless Function может отправлять Email через SMTP, если среда позволяет создавать необходимые Connections.

Но HTTP Email API иногда удобнее из-за короткого жизненного цикла Functions и управления сетевыми соединениями.

SMTP и 1С

1С и связанные сервисы могут отправлять Email через корпоративный SMTP Server.

Например:

• счета;
• акты;
• уведомления;
• отчеты;
• напоминания клиентам.

Для этого настраиваются SMTP Host, Port, Encryption и Credentials.

SMTP в CRM

CRM может использовать SMTP для отправки менеджерами писем клиентам или автоматических уведомлений.

При большом количестве сообщений важно разделять обычную персональную почту и массовые автоматические рассылки.

Транзакционные письма

Transactional Email отправляется в ответ на конкретное действие пользователя.

Примеры:

• подтверждение регистрации;
• сброс Password;
• чек;
• статус заказа;
• уведомление о входе.

Такие письма критичны для работы приложения и требуют надежного мониторинга.

Маркетинговые рассылки

Массовые маркетинговые Email создают другой профиль нагрузки и требования к Subscription Management, Reputation и отписке.

Их часто отправляют через специализированную Email Marketing Platform, а не через обычный корпоративный Mailbox.

Почему нельзя отправлять массовую рассылку с обычного ящика

Mail Provider может применять Limits, а резкий рост объема ухудшает Reputation домена или IP.

Кроме того, маркетинговый процесс должен управлять Unsubscribe, Bounce и Complaint Events.

Rate Limit SMTP

Mail Server может ограничивать количество сообщений или получателей за определенный период.

Приложение должно учитывать эти ограничения и использовать очередь, а не пытаться отправить десятки тысяч Email одновременно.

SMTP Queue в приложении

Не рекомендуется заставлять пользователя ждать завершения SMTP Delivery при каждом действии.

Например:

User creates order
↓
Application saves order
↓
Message Queue
↓
Email Worker
↓ SMTP
Mail Provider

Так временная проблема почты не блокирует оформление заказа.

Retry в приложении

Если SMTP Server временно недоступен, Email Worker может повторить отправку.

Но необходимо ограничить число попыток и отслеживать окончательные ошибки.

Duplicate Email

Если приложение не знает, был ли Request принят Mail Server до Network Timeout, бездумный Retry может создать повторное письмо.

Для обычного уведомления это не всегда критично, но процесс должен учитывать потенциальные дубликаты.

SMTP Timeout

Client должен устанавливать разумные Timeouts на Connection и SMTP Operations.

Без Timeout зависший Mail Server может надолго занять Worker или Thread приложения.

Connection Pooling

При большой частоте отправки приложение может повторно использовать SMTP Connections, если Library и Server это поддерживают.

Так уменьшается количество TCP и TLS Handshakes.

Почему нельзя держать SMTP Connection бесконечно

Mail Server может закрывать неактивные Sessions, выполнять Maintenance или применять Limits.

Client должен корректно восстанавливать Connection.

SMTP и кодировка

Email может содержать русский текст, Emoji и другие Unicode Symbols.

MIME Headers и Content-Type должны корректно описывать Character Encoding, иначе получатель увидит поврежденный текст.

HTML-письма

SMTP может транспортировать Email с HTML Body.

При этом HTML Email должен учитывать ограничения почтовых клиентов и не полагаться на те же возможности JavaScript и CSS, что обычный сайт.

Plain Text версия

Полезно добавлять Text Alternative для HTML Email.

Это улучшает совместимость и позволяет клиенту выбрать подходящее представление.

SMTP и ссылки

Антиспам-системы анализируют Domains и URLs внутри письма.

Подозрительные Redirects, скомпрометированные Domains или большое количество сомнительных Links могут негативно повлиять на доставку.

Email Spoofing

Spoofing — попытка отправить сообщение так, чтобы оно выглядело как письмо от другого отправителя.

SMTP исторически не был построен вокруг строгой проверки визуального From, поэтому современные системы используют SPF, DKIM и DMARC.

Phishing

Фишинговое письмо пытается заставить пользователя передать Password, открыть вредоносный файл или выполнить опасное действие.

SMTP является транспортом и сам по себе не определяет, является содержание мошенническим.

Для защиты используются Mail Security Gateway, Anti-spam, Attachment Scanning и обучение пользователей.

SMTP и антивирус

Mail Gateway может проверять Attachments на Malware до помещения письма в Mailbox.

Но отсутствие срабатывания Antivirus не гарантирует абсолютную безопасность вложения.

SMTP и DLP

Для исходящей корпоративной почты DLP может анализировать содержание сообщений и предотвращать отправку конфиденциальных данных наружу.

Так SMTP становится частью общей Data Security Architecture.

SMTP Logs

Mail Server Logs помогают диагностировать доставку.

Полезные данные:

Message-ID

Email обычно содержит Message-ID, позволяющий различать сообщения.

Он полезен при поиске письма в Logs нескольких Mail Systems.

SMTP Queue Monitoring

Резкий рост очереди может означать:

• проблему DNS;
• блокировку исходящего Traffic;
• недоступность Mail Provider;
• Reputation Problem;
• неправильные Credentials;
• массовую ошибку приложения.

Какие метрики SMTP контролировать

SMTP и Observability

Для бизнес-приложения полезно отслеживать не только технический SMTP Response, но и конечное состояние Email Workflow.

Например, Password Reset Email должен быть поставлен в очередь, успешно передан Provider и не получить Hard Bounce.

SMTP Health Check

Открытый TCP Port еще не означает, что почта реально отправляется.

Для полноценной проверки можно периодически выполнять контролируемую отправку тестового сообщения и отслеживать результат.

Типичные ошибки SMTP

1. Неправильный Host.
2. Неправильный Port.
3. Несовпадающий режим TLS.
4. Неверные Credentials.
5. Firewall блокирует исходящее соединение.
6. Провайдер блокирует Port 25.
7. Не настроен SPF.
8. Нет DKIM.
9. Ошибочная DMARC Policy.
10. Приложение не обрабатывает временные ошибки.

SMTP Authentication Failed

Если Server отклоняет Authentication, нужно проверить Username, Password, разрешенный метод входа и требования Provider.

Также Password приложения может отличаться от обычного Password пользователя.

Connection Timeout

Timeout чаще указывает на проблему Network, Firewall, Routing или неверный Port.

Если Authentication Error уже получена, значит TCP и SMTP Connection как минимум частично работают.

Connection Refused

Ошибка может означать, что на указанном Host и Port нет слушающего SMTP Service или соединение активно отклоняется сетевым устройством.

TLS Error

Причинами могут быть неправильный режим Encryption, Certificate Validation, устаревшие параметры клиента или сетевой Proxy.

Отключать проверку Certificate ради обхода проблемы в Production не следует.

Письма перестали доходить после смены SMTP Provider

Необходимо проверить:

1. SPF.
2. DKIM.
3. DMARC.
4. Envelope Sender.
5. From Domain.
6. DNS.
7. IP Reputation.
8. Bounce Logs.

Одной замены SMTP Host может быть недостаточно.

Как безопасно настроить SMTP в приложении

Шаг 1. Использовать отдельные Credentials

Не используйте личный Mailbox администратора.

Шаг 2. Включить TLS

Credentials и содержимое должны передаваться по защищенному соединению.

Шаг 3. Хранить пароль в Secret Manager

Не помещайте SMTP Password в Git.

Шаг 4. Ограничить Sender

Application Account должен отправлять только с предусмотренных адресов.

Шаг 5. Настроить SPF, DKIM и DMARC

Это улучшает аутентификацию домена и управляемость доставки.

Шаг 6. Добавить Queue и Retry

Временный сбой почты не должен ломать основную бизнес-операцию.

Шаг 7. Мониторить Bounce

Ошибки доставки нужно видеть и анализировать.

Шаг 8. Ограничить массовую отправку

Учитывайте Rate Limits Provider.

Практический пример

Интернет-магазин должен отправлять клиентам подтверждения заказов.

Backend после успешной записи заказа в Database создает задачу в Message Queue.

Email Worker получает задачу и формирует письмо с номером заказа.

Worker подключается к SMTP Submission Server через TLS и проходит Authentication под отдельной учетной записью notifications@example.com.

SMTP Provider принимает сообщение и помещает его в собственную Queue. Затем через DNS определяет MX Server домена получателя и выполняет доставку.

Исходящие письма подписываются DKIM. Для домена настроены SPF и DMARC.

Если SMTP временно недоступен, Worker повторяет попытку позже. При постоянной ошибке событие отправляется в Monitoring.

SMTP Password хранится в Secret Manager, а не в Application Repository.

Marketing Newsletter отправляется через отдельную систему, чтобы массовая рассылка не влияла на Reputation критичных транзакционных писем.

SMTP для бизнеса

SMTP остается основным стандартным протоколом передачи Email и поддерживается практически любой корпоративной системой.

Через него можно быстро подключить CRM, 1С, сайт, мониторинг или ERP к существующей почтовой инфраструктуре.

Для бизнеса при этом важна не только сама возможность отправить письмо. Необходимо обеспечить доставляемость, защиту домена от Spoofing, контроль Bounce, безопасное хранение Credentials и наблюдаемость почтовой очереди.

Преимущества SMTP

• широкая совместимость;
• стандартный протокол;
• поддержка существующими бизнес-системами;
• возможность использовать внешний Relay;
• TLS и Authentication;
• Store-and-forward доставка;
• поддержка вложений через MIME.

Недостатки SMTP

• сам по себе не гарантирует попадание во «Входящие»;
• требует дополнительных SPF, DKIM и DMARC;
• подвержен злоупотреблениям при неправильной настройке;
• для современной аналитики Email API может быть удобнее;
• массовая отправка требует управления Reputation;
• не предназначен для чтения Mailbox.

Когда использовать SMTP

SMTP подходит, если приложение или корпоративная система уже умеет работать с Mail Server через стандартные настройки Host, Port, Login и Password.

Это типичный вариант для 1С, CRM, мониторинга, принтеров, серверов и Legacy Applications.

Когда лучше использовать Email API

HTTP API может быть удобнее, если Backend должен получать подробные Delivery Events, управлять Templates, Metadata и аналитикой через одну программную платформу.

Но Email Provider внутри своей инфраструктуры все равно взаимодействует с глобальной почтовой системой через соответствующие Mail Protocols.

Связанные термины

Краткий итог

SMTP — протокол передачи электронной почты, используемый для отправки сообщений от приложений и пользователей на Mail Server и для дальнейшего обмена между почтовыми серверами.

SMTP работает поверх TCP и использует разные Ports в зависимости от сценария. Для клиентской отправки обычно применяется SMTP Submission с Authentication и TLS, а Server-to-Server доставка связана с отдельной почтовой инфраструктурой.

Для надежной корпоративной почты одного SMTP недостаточно. Необходимо правильно настроить DNS, MX, SPF, DKIM и DMARC, защищать Credentials, обрабатывать Queue и Bounce и контролировать Reputation отправителя. В приложениях отправку Email желательно выполнять асинхронно через очередь, чтобы временная проблема Mail Server не останавливала основную бизнес-операцию.