Тут возникает вопрос: если SMTP такой универсальный, почему нельзя отправлять письма напрямую через него? Можно, но есть несколько «но», о которых я расскажу дальше.
А пока немного теории.
Обычному пользователю знание SMTP не нужно, достаточно воспользоваться интерфейсом любого почтовика. С помощью команд из почтовика он будет отправлять запросы к серверу получателя.
Вот пример того, как выглядит общение серверов изнутри (SMTP-сессия):
Пример SMTP-сессии
$ telnet expamle.com 25 — мы пробуем подключиться к example.com по 25 порту, который как раз используется для передачи почты.
Trying example.com...
Connected to example.com.
Escape character is '^]'.
220 mailserver at example.com greets you. Make love not war! — подключение удалось.
HELO test.com
250 example.com — поприветствовали друг друга с помощью команды HELO, сервер получателя ответил командой 250, что значит, что возможно дальнейшее «общение».
MAIL FROM: <test@test.com > — мы говорим, от кого хотим отправить письмо.
250 2.1.0 Ok — сервер отвечает, что готов принять письмо от этого адресата (бывают ситуации, когда адрес внесен в блэклист на стороне получателя, и тогда уже здесь начнутся ошибки.
RCPT TO: <user@example.com> — мы говорим, кому хотим отправить письмо.
250 2.1.5 Ok — сервер отвечает, что готов принять письмо для этого получателя (если адреса не существует, то здесь сервер может сказать что-то вроде 550 No such user here.
DATA — сообщаем серверу, что начинаем передавать письмо.
354 End data with <CR><LF>.<CR><LF> — сервер отвечает, в каком виде он хочет видеть конец письма.
FROM: test@test.com — начинаем передавать письмо вместе с техническими заголовками.
TO: user@example.com
SUBJECT: test mail from test subject
test body
. — показываем, что мы закончили передачу письма.
250 2.0.0 Ok: queued as 1CF5FC0AAE — сервер отвечает, что принял письмо для доставки и назначил ему id 1CF5FC0AAE (по нему, в случае недоставки, системный администратор принимающего сервера сможет найти, что стало с письмом.
QUIT — сообщаем, что сеанс связи закончен.
221 2.0.0 Bye — сервер прощается с нами.
Connection closed by foreign host. — соединение обрывается.
Это пример самой простой SMTP-сессии. Она может быть намного сложнее, если получателей будет несколько или сервер получателя потребует аутентификацию и шифрование.
Кажется, что мешает подробно изучить документацию по SMTP и отправлять массовые рассылки через своё SMTP-решение? С этим есть проблема.
Предлагаю посмотреть на разные способы отправки массовых рассылок и оценить их по 3 параметрам: необходимость в доработках, доставляемость писем и цена.
Ящик на бесплатной почте (Mail.ru, Gmail)
Сервис транзакционных рассылок (например, Unisender Go)
Сервис рассылок (например, Unisender)
Почти все почтовые провайдеры (Gmail, Mail.ru) предоставляют доступ к ящику по SMTP. Тем не менее отправлять массовые рассылки с бесплатной почты не получится.
Ящики на Gmail, Mail.ru или Яндексе бесплатные. На этом преимущества для отправки массовых писем заканчиваются.
Пока вы отправляете небольшое количество писем, вас может устраивать бесплатная почта. Но если подписчиков много, вы столкнётесь с ограничениями по количеству писем.
У большинства почтовых сервисов максимум 500 писем в день, больше отправить не дадут. Более того, если мы попробуем перешагнуть через допустимый порог, то ящик заблокируют, а все письма начнут попадать в «Спам».
Почтовые провайдеры не могут допустить, чтобы с их серверов отправляли спам. Он ухудшает репутацию серверов почтовиков — из-за этого даже нормальные письма могут не дойти до «Входящих».
Вывод: не подходит для массовых рассылок.
Многие интернет-провайдеры дают пользователям почту на своём домене.
Этот способ похож на предыдущий: почта интернет-провайдера подходит для личной переписки, но не для массовых рассылок. Отправка писем идёт через IP-адреса провайдера — они не могут допустить, чтобы через них проходил спам. Поэтому на большинстве таких ящиков тоже стоит ограничение на количество писем в сутки.
Вывод: не подходит для массовых рассылок.
Плюсы покупки хостинга — вы получаете email-адрес на том же домене, на котором будет располагаться ваш сайт. Это удобно, допустим, когда у вас есть небольшой интернет-магазин, и вам нужно отправлять сообщения со статусом заказа.
Но когда возникнет необходимость массовых рассылок, вы можете столкнуться с ограничениями и трудностями.
Часто хостинг располагается на общих IP-адресах хостинг провайдера, а это значит, что параллельно с вами на данном IP-адреса может находиться еще кто-то, и отправлять спам. Ваши письма из-за этого тоже будут попадать в спам. Именно из-за этого часто провайдеры ограничивают возможность рассылок для владельцев хостинга, и требуют покупки VPS (виртуального сервера) или выделенного сервера, что приводит нас к следующему пункту.
Вывод: подходит для массовых рассылок, если купить виртуальный сервер и настроить его.
Как мы уже сравнили в начале, SMTP — это про всё, что касается отправки и доставки сообщения до получателя. Что именно отправлять и как отправлять — ваша ответственность. SMTP подходит для всего: транзакционных писем, массовых рассылок или личной переписки.
Простота. SMTP — простой протокол: его легко протестировать и внедрить (особенно, если у вас уже было SMTP-решение до этого).
Использование SMTP требует меньше знаний для внедрения, чем, скажем, использование Web API (на котором построены сервисы транзакционных писем). SMTP хорошо изучен, для него есть подробная документация. Непредвиденные обстоятельства вроде внезапной смены протокола или изменения работы каких-то методов, сведены к минимуму.
Чтобы запустить SMTP-сервер, нужно разобраться, как работает протокол, и изучить набор необходимых команд.
Подробный отчёт об ошибках. Используя SMTP, вы сразу получаете ответ о доставке или ошибке доставки сообщения. Многие сервисы не дают развернутый ответ о причинах недоставки. Если письмо не дошло, то чаще всего они просто выведут причину: несуществующий адрес, блокировка сообщения как спама.
SMTP-сессия покажет, на каком именно этапе возникла ошибка доставки. Иногда это полезно. Например, если ошибка возникла на этапе передачи данных MAIL FROM (смотрите пример SMTP-сессии), то ваш обратный адрес не нравится серверу получателя.
Грейлистинг. Протокол SMTP требует постоянного общения сервера отправителя и получателя. Недостаточно отправить один запрос на отправку письма. Сначала серверы должны «поздороваться», потом отправитель должен сообщить, от кого письмо, потом предоставить содержание письма. На каждый из этих этапов мы ждём ответ сервера получателя. Когда отправляется одно письмо, трудностей не возникает.
Но когда отправляется много писем, может, например, включиться грейлистинг. Это технология защиты от спама, когда сервер получателя сознательно отвечает вашему SMTP-серверу, что он недоступен. В этом случае SMTP, рассылающие спам, обычно прекращают попытки. Знание о таком поведении необходимо закладывать в логику работы вашего SMTP сервера. Например, в сервисах рассылок повторные попытки отправки автоматизированы — письма лучше доходят до получателей.
Необходимость глубокой доработки. Чтобы настроить полноценный email-маркетинг на своём SMTP-сервере, нужно много доработок. Например, чтобы следить за открытиями и переходами из писем, нужны специальные заголовки или трек-пиксели. И так с каждым инструментом — чтобы его сделать, нужно звать разработчиков.
Протокол. SMTP поддерживают не все провайдеры. Некоторые не дают его использовать, чтобы не допустить спама.
Вывод: подходит для массовых рассылок, но нужна глубокая доработка со стороны разработчиков.
В основе сервисов транзакционных рассылок тоже лежит SMTP. Но разработчики заранее потрудились и дописали к нему API-методы. Это команды, которыми мы можем вызывать разные функции: отправку письма, отписку от рассылки, создание шаблона письма, получение статистики. В обычном SMTP для всего этого нужны доработки.
Поясню, что это значит, на примере сервиса транзакционных рассылок Unisender Go. Это курьер, который доставит письмо. Можно отправлять рассылки и самому, а можно нанять курьера. С его помощью можно персонализировать рассылку, использовать шаблоны, трекинг прочтений и переходов по ссылкам. Это удобно и сильно экономит время для работы.
Из главных преимуществ такого подхода:
Для того, что использовать сервис транзакционных писем, обычно требуются доработки программистов для внедрения отправки писем через Web API-сервис.
Также API намного больше подвержены изменениям. Если SMTP не меняется, API методы могут поменяться, что потребует изменения кода на вашей стороне.
Вывод: подходит для массовых рассылок, есть много готовых функций, которые в SMTP пришлось бы дорабатывать.
Если считать SMTP почтовым отделением, а сервис транзакционных писем — курьерской службой, то сервис рассылок — это целый отдел работы с почтой, глава которого — вы.
Благодаря удобному веб-интерфейсу, редактору писем, менеджеру контактов вы можете легко подготовить и отправить рассылку. Кроме того, в сервисах рассылок можно анализировать рассылки, сегментировать получателей по различным параметрам, проводить сплит-тесты и много чего другого.
Все инструменты уже готовы для работы, в большинстве случаев привлекать разработчиков не потребуется.
Из недостатков сервиса рассылок можно выделить меньшую скорость работы по сравнению с сервисами транзакционных писем — сервис рассылок обрабатывает меньше писем за единицу времени. Но если в вашей базе не сотни тысяч подписчиков, и вам не нужно доставлять письма в течение нескольких секунд после отправки (что необходимо для транзакционных писем), то вы не заметите разницы.
Данные о ваших подписчиках будут храниться на серверах сервиса рассылки. Если вы используете CRM-систему, её нужно будет интегрировать с базой контактов в сервисе рассылки. В Unisender для этого есть готовые решения.
Вывод: через сервис рассылок можно отправлять массовые рассылки без дополнительных доработок. Разработчиков зовут в редких случаях: например, если нужно настроить сложные сценарии автоматизации или привязать другой сервис по API.
SMTP — удобный протокол, на котором работают почти все приложения для отправки почты. Но если вы захотите сделать свой SMTP-сервер для массовых рассылок, придётся попотеть: прикрутить обработку статусов доставки, обход грейлистинга, удобную статистику писем, отписку от рассылки.
Всё это можно сделать, но проще взять сервис транзакционных рассылок, в котором эти функции уже реализованы. Разработчики нужны только для того, чтобы интегрировать его с вашей CRM-системой.
Следующая ступенька — сервисы рассылок. В них все функции вшиты в удобный пользовательский интерфейс. Кроме базовых возможностей, в сервисах рассылки можно собирать письма и формы подписки, работать с базой контактов, настраивать автоматические цепочки и проводить сплит-тесты. И всё это без привлечения программистов.
Unisender — платформа автоматизации маркетинга. Удобные конструкторы, 100+ шаблонов и интеграций, гибкие тарифы. До 1500 писем бесплатно.
Делимся новостями и свежими статьями, рассказываем о новинках сервиса
Искренние письма о работе и жизни. Свежие статьи из блога. Эксклюзивные кейсы и интервью с экспертами диджитала.
