SMTP — это фундамент всей электронной почты. И при этом, наверное, самая недопонятая её часть. Мы в поддержке постоянно сталкиваемся с одной и той же картиной: клиент настроил SMTP, сервер ответил «всё ок», а письма всё равно падают в спам, отлетают с ошибкой или просто бесследно растворяются. И почти всегда корень проблемы — в паре устойчивых мифов о том, что SMTP якобы умеет делать (а на самом деле нет).
Протоколу больше сорока лет, и, казалось бы, за это время мы должны были разобраться в нём досконально. Но нет — мифы живут и здравствуют. Давайте разберём пять самых частых и расставим точки над i.
А что такое SMTP на самом деле?
SMTP (Simple Mail Transfer Protocol) — это транспортный протокол. Его единственная задача — перенести письмо с одного сервера на другой. И с этой задачей он справляется прекрасно. Но именно — только с этой.
Представьте SMTP как курьера, который забрал у вас посылку и довёз её до проходной нужного здания. А вот что будет дальше — пустят ли его через охрану, дома ли получатель, попадёт ли посылка на правильный стол или потеряется в коридорах — курьер уже не контролирует. Его работа закончилась в тот момент, когда принимающая сторона расписалась в получении.
В терминах SMTP эта «расписка» — ответ сервера 250 OK. Протокол отвечает за рукопожатие между серверами: приветствие EHLO, команды MAIL FROM и RCPT TO, передачу самого письма и финальное подтверждение. Как только прилетело 250 OK — SMTP считает дело сделанным. А дойдёт ли письмо до инбокса, упадёт в спам или исчезнет — это уже отдельная история. И именно вокруг неё крутится большинство мифов.
Миф 1. «Письмо ушло по SMTP — значит, оно в инбоксе»
Это, пожалуй, самое дорогое заблуждение во всём email-маркетинге.
Ответ 250 OK от принимающего сервера означает ровно одно: сервер принял ваше письмо. Не доставил в инбокс, не показал получателю — просто принял на свою сторону. А дальше он волен делать с ним что угодно: положить в инбокс, отфильтровать в спам, поместить в карантин или тихо удалить, не сказав вам ни слова.
SMTP работает на транспортном уровне. А попадание в инбокс — это вопрос доставляемости, и зависит он совсем от других вещей: репутации отправителя, настроенной аутентификации, истории вовлечённости подписчиков, содержания письма. SMTP ни одну из этих вещей не контролирует.
Вывод простой: если вы разбираетесь, почему у рассылки низкие открытия или письма летят в спам, не стоит искать причину в логах SMTP. Смотрите на репутацию отправителя, на DKIM/SPF/DMARC и на качество вашей базы. SMTP тут ни при чём — он своё дело сделал.
Миф 2. «SMTP сам аутентифицирует отправителя»
SMTP придумали в более доверчивую эпоху. В оригинальном протоколе вообще нет механизма, который проверял бы, что отправитель — это действительно он. Сервер просто верит на слово тому, что написано в поле MAIL FROM. Именно поэтому подделка адресов (спуфинг) десятилетиями была — и остаётся — головной болью почтового мира.
Вся аутентификация надстроена поверх SMTP, а не встроена в него. SPF, DKIM и DMARC работают независимо от самого SMTP-рукопожатия. Даже SMTP AUTH — тот самый механизм с логином и паролем, который вы вводите при настройке подключения, — это отдельное расширение, а не часть базового протокола.
Что это значит на практике: 250 OK совершенно не гарантирует, что с вашей аутентификацией всё в порядке. Вы можете успешно передать письмо по SMTP — и всё равно улететь в спам или получить отказ, потому что SPF-запись битая, а DKIM-подпись не проходит проверку. Сначала настройте аутентификацию — за вас SMTP этого не сделает.
И тут есть важный нюанс именно для российских отправителей: требования к аутентификации только ужесточаются. Yandex, Mail.ru, Gmail и Outlook уже давно не пускают в инбокс письма без корректных SPF и DKIM, а для массовых рассылок всё чаще требуют и DMARC. Если вы давно не проверяли свои записи — сейчас самое время.
Кстати, у нас в Лаборатории есть бесплатные инструменты, которые помогут это сделать.
Миф 3. «SMTP шифрует письма по умолчанию»
Из коробки классический SMTP передаёт всё открытым текстом. Заголовки, содержимое письма, ваш логин и пароль — всё это потенциально видно любому, кто слушает соединение. На заре интернета это никого особо не волновало, а сегодня — это серьёзная проблема.
Шифрование пришло позже и тоже как отдельный слой. Два варианта покрывают почти все сценарии отправки:
STARTTLS — расширение протокола, которое позволяет «обновить» уже открытое нешифрованное соединение до зашифрованного. Ключевое слово здесь — «обновить»: если принимающий сервер не поддерживает STARTTLS, соединение может откатиться к открытой передаче. Это работает на портах 25 и 2525.
Implicit TLS (SMTPS) — соединение зашифровано с самой первой секунды, без открытой фазы вообще. У нас это порт 465.
Практический вывод: всегда настраивайте отправку с TLS и убедитесь, что ваш сервис его поддерживает. У нас, например, шифрование доступно на всех портах — выбирайте любой удобный. И не считайте, что раз письмо приняли, то соединение точно было зашифровано. Это разные вещи.
Миф 4. «Порт 25 — это правильный порт для отправки»
Порт 25 — самый первый SMTP-порт, ещё из 1982 года. И он же — порт, с которым вы вероятнее всего наживёте проблем.
Большинство хостингов и интернет-провайдеров блокируют исходящий 25-й порт на обычных (не серверных) сетях — именно потому, что его исторически нещадно эксплуатировали спамеры. У российских хостингов и облаков (Selectel, Timeweb, REG.RU, Yandex Cloud и других) это стандартная практика: 25-й порт закрыт по умолчанию. Если вы строите приложение, которое шлёт письма через 25-й порт, на многих сетях вы просто упрётесь в ошибку соединения, и письма никуда не уйдут.
Какие порты стоит знать:
- Порт 2525 — наш основной рекомендованный порт. Поддерживает STARTTLS, работает по той же логике, что и классический submission-порт, но почти не блокируется хостингами и файрволами. Если сомневаетесь, какой порт выбрать, — берите его.
- Порт 465 — Implicit TLS. Подходит, если ваше приложение умеет работать только с SSL-соединением.
- Порт 25 — только для серверной ретрансляции (server-to-server relay). Для отправки из приложения не годится и часто заблокирован.
Кстати, обратите внимание: порта 587, который часто называют «стандартным» для отправки, у нас нет — и это осознанное решение.
Подробно, почему так и чем 2525 лучше, мы разобрали в отдельной статье про SMTP-порты.
Миф 5. «Свой SMTP-сервер — это дешевле и проще»
Этот миф обычно всплывает, когда команда хочет сэкономить на стороннем сервисе или держать всю почтовую инфраструктуру у себя. На поверхности логика кажется здравой: ну сколько там того SMTP-сервера, поднимем за вечер.
На практике собственный SMTP-сервер — один из самых быстрых способов угробить свою доставляемость и потом долго не понимать, почему. Подняв свой сервер, вы берёте на себя всё то, чем SMTP не занимается: прогрев IP-адресов, обработку отказов (bounce) и жалоб, ведение списков подавления, регистрацию в постмастерах почтовых провайдеров, обслуживание TLS-сертификатов, мониторинг блок-листов и постоянное отслеживание меняющихся требований Yandex, Mail.ru, Gmail и других. Это, без преувеличения, отдельная полноценная работа — и именно вокруг неё сервисы рассылок годами строят свои инструменты.
Помимо операционной нагрузки, есть ещё проблема репутации: новые IP-адреса пробиваются в инбокс с большим трудом, пока не наработают историю отправок за время прогрева. А до тех пор значительная часть писем будет оседать в спаме.
Для большинства команд гораздо разумнее отдать всю эту инфраструктурную сложность сервису — и получить взамен логи, аналитику и инструменты доставляемости, которые иначе пришлось бы строить самим. А если вы ещё думаете, оставаться на SMTP или переходить на API, — мы сравнили оба подхода в отдельной статье.
Подведём итог
SMTP — не враг. Это удивительно живучий протокол, который исправно перевозит почту больше сорока лет, и понимание того, что он на самом деле делает, — первый шаг к чистой и стабильной отправке.
Если совсем коротко: SMTP доставляет ваше письмо из точки А в точку Б. Всё остальное — попадание в инбокс, аутентификация, шифрование, обработка отказов — это уже ваша зона ответственности, которую вы настраиваете поверх. Хорошая новость в том, что с современными инструментами выстроить эти слои несложно, если знать, с чего начать.
А если вы столкнулись с конкретной ошибкой при отправке — загляните в нашу Лабораторию: SMTP-тестер покажет подробный лог соединения в реальном времени и поможет понять, где именно что-то идёт не так. Ну а если не разберётесь сами — пишите в поддержку на support@dashamail.ru, поможем.
Удачной отправки!
Загрузка...