обзор · бесплатный smtp-сервис

Что продуктовой команде оценить при выборе бесплатного SMTP-сервиса?

Оценивайте бесплатный SMTP-сервис как зависимость продакшена с ограничениями, а не как бесплатное имя хоста. Выясните, идёт ли речь о постоянном бесплатном тарифе или об истекающем пробном периоде; какие письма, получатели, байты, журналы, события и обращения в поддержку учитываются в лимитах; что происходит при достижении предела и требуются ли платёжные данные или автоматическая оплата перерасхода. Затем протестируйте обязательный TLS, учётные данные с ограниченными правами, подтверждённые домены отправителя, SPF, DKIM, DMARC-выравнивание, поведение при частичном приёме получателей, ответы 4xx и 5xx, отказы (bounce), жалобы, стоп-листы, хранение, экспорт и удаление данных. Оцените стоимость миграции до запуска и никогда не приравнивайте приём письма бесплатным тарифом к доставке или попаданию во «Входящие».

Определяйте «бесплатно» по действующему договору

Словом «бесплатно» могут называть постоянный лимит, ограниченный по времени пробный период, стартовые кредиты, тестирование только на подтверждённых получателях или платный тариф с временными кредитами. Читайте актуальные цены и условия провайдера в день оценки. Фиксируйте валюту, регион, налоги, требование банковской карты, срок окончания пробного периода, включённые единицы, поведение при перерасходе, поведение при блокировке и то, какие функции исчезают при переходе на более низкий тариф. Не полагайтесь на сниппеты из поиска, старые сравнительные статьи, скриншоты или чат с отделом продаж без надёжной ссылки на договор. AWS SES, Resend и Mailgun публикуют на своих официальных страницах разные актуальные модели цен и включённые возможности; ни одну из них не стоит считать взаимозаменяемой. Привяжите к решению URL изученной страницы и дату фиксации и запланируйте повторную проверку перед запуском, потому что предложения провайдеров могут меняться. Бесплатный вход не отменяет затрат на разработку, DNS, мониторинг, конфиденциальность, инциденты и миграцию.

Моделируйте нагрузку в тарифицируемых и операционных единицах

Оцените число писем, получателей, вложений, байтов, запросов к API или SMTP, доставок событий, входящих писем, хранимого содержимого, срок хранения журналов, число доменов, участников команды и окружений. Письмо с несколькими получателями может расходовать квоту иначе, чем транзакционное письмо одному получателю. Повторы, тестовый трафик, прогрев, отказы и повторные доставки вебхуков могут увеличивать объём. Рассчитайте средний спрос, пиковую минуту, пиковый час, дневной, месячный и сезонный спрос, а также запас на рост и инциденты. Держите ограничения частоты в приложении ниже лимитов провайдера и защищайте тенантов друг от друга. Выясните, что происходит, когда единицы закончились: жёсткое отклонение, отложенная доставка, автоматическое списание, урезанные функции или незаметная потеря журналов. Бесплатный тариф, который покрывает вызовы отправки, но не включает полезную историю событий, поддержку или экспорт стоп-листа, в эксплуатации может обойтись дороже небольшого платного тарифа. Перед продакшеном сверьте наблюдаемые счётчики аккаунта на контролируемом трафике.

Требуйте защищённой отправки через SMTP

SMTP-сервис для продакшена должен документировать защищённую отправку, поддерживаемые порты, поведение TLS, механизмы аутентификации, требования к сертификатам, область действия учётных данных и их ротацию. Предпочитайте обязательный TLS и отказ в соединении при отсутствии STARTTLS, ошибке сертификата, несовпадении имени хоста или неподдерживаемом протоколе. Храните учётные данные в управляемой системе секретов и никогда — в коде браузера, мобильных приложениях, исходном коде, образах, журналах, URL, аналитике, тикетах или промптах. Разделяйте полномочия для продакшена, тестов, тенантов и администрирования. Выясните, ограничивает ли бесплатный тариф учётные данные, исходные IP-адреса, домены, регионы или число одновременных подключений. RFC 8314 рекомендует отказаться от открытых протоколов в пользу TLS для отправки и доступа к почте, а RFC 4954 определяет аутентификацию SMTP как расширение протокола, а не как авторизацию на уровне продукта. Приложение всё равно должно авторизовать бизнес-событие, отправителя, тенанта, получателя, шаблон и класс письма, прежде чем открывать SMTP-соединение.

Проверьте адрес отправителя и владение DNS

Требуйте домен From, принадлежащий организации, и задокументированный процесс подтверждения домена. Составьте перечень: SMTP MAIL FROM или обратный путь (return path), видимый From, домен DKIM d= и селектор, IP-адреса отправки и обработка ответов. Опубликуйте одну корректную SPF-политику, включающую реальный путь, настройте подпись DKIM с защищёнными ключами и проверьте DMARC-выравнивание с видимым доменом From. Подтверждение у провайдера — свидетельство того, что одна проверка настройки пройдена; оно не доказывает согласие получателей, правильную маршрутизацию в продакшене, репутацию или попадание во «Входящие». Разберитесь, какими DNS-записями владеет провайдер, а какие остаются в авторитативной зоне организации. Сохраните прежние значения и шаги отката. Не используйте для идентичности в продакшене домен From, принадлежащий только провайдеру: это ухудшает переносимость и может сделать DMARC-выравнивание или единство бренда зависимыми от поставщика. Проверяйте исходный код полученных писем для каждого потока и окружения.

Требуйте полезных результатов на уровне получателя

Сервис должен различать приём по SMTP или API, отказ по конкретному получателю, временную отсрочку, постоянный сбой, последующий отказ (bounce), жалобу, отписку и добавление в стоп-лист провайдером. Проверьте, как эти результаты доставляются, аутентифицируются, повторяются, упорядочиваются, хранятся и экспортируются на бесплатном тарифе. Аутентифицируйте вебхуки до разбора, проверяйте свежесть и защищайтесь от повторного воспроизведения, надёжно сохраняйте события до подтверждения и связывайте их с попытками, принадлежащими приложению. Храните области принятых и отклонённых получателей отдельно. Повторяйте временные сбои, допускающие повторную попытку, с ограниченной задержкой, джиттером (jitter), лимитом попыток и лимитом возраста очереди. Прекращайте автоматическую отправку после постоянного сбоя адреса, жалобы или отписки в соответствующей области. Панель без экспортируемых данных создаёт операционную привязку к поставщику. Событие delivered у провайдера часто описывает приём сервером назначения, а не итоговую папку в почтовом ящике. Открытия и клики — это инструменты измерения вовлечённости, и технологии защиты приватности могут их искажать.

Изучите лимиты, которых нет на странице цен

Страницы с ценами редко содержат весь операционный договор. Изучите актуальную документацию: число получателей, размер письма, размер вложений, частота подключений, одновременные сессии, частота запросов к API, DNS-домены, шаблоны, попытки доставки вебхуков, срок хранения событий, ёмкость стоп-листа и ограничения на получателей в пробном периоде. Выясните, требуют ли платного тарифа поддержка, журналы аудита, выделенные IP-адреса, региональная обработка, маршруты входящей почты или функции для соответствия требованиям. Проверяйте на реальном аккаунте, потому что у новых или пробных аккаунтов лимиты могут быть ниже, либо может действовать ручная проверка. Фиксируйте каждый лимит с URL источника и датой наблюдения. Не проектируйте систему впритык к максимуму: оставляйте запас на изменения у провайдера, повторы и восстановление после инцидентов. Если приложение может незаметно превысить лимит через передаваемые пользователем массивы получателей или вложения, сначала введите более строгое ограничение в продукте. Считайте незадокументированные или неясные лимиты риском, а не неограниченной ёмкостью.

Оцените конфиденциальность, безопасность и защиту от злоупотреблений

Составьте карту того, где по регионам находятся содержимое писем, данные получателей, заголовки, полезная нагрузка событий, IP-адреса, журналы, доступ поддержки, резервные копии и субподрядчики. Минимизируйте пользовательские метаданные и не помещайте секреты или лишние персональные данные в теги и заголовки. Уточните, как хранятся и удаляются данные бесплатных аккаунтов, в том числе после закрытия. Проверьте изоляцию тенантов, ролевой доступ, MFA, историю аудита, ротацию учётных данных, подпись вебхуков, авторизацию изменений стоп-листа и уведомления об инцидентах. Протестируйте внедрение заголовков, произвольный выбор отправителя, избыточное число получателей, злоупотребление вложениями, поиск событий другого тенанта и повторное воспроизведение. Бесплатные тарифы — частая мишень для злоупотреблений, поэтому провайдеры могут вводить автоматические проверки или быстро блокировать аккаунты; продукту нужны надёжная очередь и безопасный способ приостановки. Никогда не обходите защиту от злоупотреблений сменой аккаунтов, доменов, учётных данных или IP-адресов. Храните состояние согласий и стоп-листа вне провайдера, чтобы блокировка или миграция не уничтожили защиту получателей.

Рассчитайте стоимость ухода до начала отправки

Скройте специфичные для провайдера поля за одним адаптером и сохраняйте модель событий приложения независимой. Составьте перечень: хост и аутентификация SMTP, полезная нагрузка API, шаблоны, домены отправителя, обратные пути, селекторы DKIM, вебхуки, названия событий, идентификаторы писем, теги, стоп-листы, маршруты входящей почты и журналы. Требуйте экспорта стоп-листа и истории эксплуатации в форматах, которые продукт может проверить. Миграция должна сохранить ключи бизнес-событий, историю попыток, согласия, безопасность получателей и владение адресами отправителя. Протестируйте второй транспорт на контролируемых адресах, но не настраивайте его как автоматический обход при постоянных сбоях получателя или нарушениях политики. Оцените окна изменений DNS, ротацию учётных данных, конвертацию шаблонов, параллельную обработку вебхуков, предотвращение дубликатов и хранение старых событий. Самый дешёвый бесплатный тариф может оказаться неверным выбором, если уход с него означает потерю данных, смену адреса отправителя или перестройку механизмов безопасности в разгар инцидента.

Проведите оцениваемую проверку до продакшена

Составьте репрезентативную матрицу тестов: согласование TLS и ошибка сертификата, аутентификация и ротация, подтверждённые и неавторизованные отправители, простое и multipart-содержимое, Unicode, вложения, частичный приём получателей, временные и постоянные ответы, тайм-аут после DATA, отказы, жалобы, отписки, повторное воспроизведение вебхуков, события не по порядку, исчерпание квоты, истечение тарифа, экспорт и закрытие аккаунта. Используйте отдельных контролируемых получателей и никогда — реальные списки клиентов. Оценивайте отдельно безопасность, корректность, доказательность данных, ёмкость, конфиденциальность, поддержку, переносимость и совокупную стоимость. Блокируйте запуск при отсутствии проверки TLS, общих секретах без ротации, раскрытии данных между тенантами, отсутствии обработки постоянных сбоев, невозможности экспорта стоп-листа, незаметном перерасходе или неясных сроках хранения. Повторяйте проверку при изменении тарифа, пути отправки, домена или договора с провайдером. Бесплатный тариф может подойти для ограниченной низкорисковой нагрузки, только если механизмы контроля и план ухода соответствуют тем же стандартам, что и для платной зависимости.

Оцените текущие тарифы SendHQ

У SendHQ нет бесплатного тарифа. Новые рабочие пространства получают контролируемый пробный период для интеграции на 100 доставок на email-адрес аккаунта или адрес симулятора AWS SES. Актуальные цены платных тарифов, лимиты и возможности смотрите на странице тарифов SendHQ.

Частые вопросы

Безопасен ли бесплатный SMTP-сервис для продакшена?

Для ограниченной нагрузки — да, но только если выполнены все требования: TLS, учётные данные с ограниченными правами, аутентификация отправителя, безопасность получателей, доказательность данных, конфиденциальность, ёмкость, поддержка и миграция.

Чем бесплатный тариф отличается от пробного периода?

Бесплатный тариф — это постоянный лимит на действующих условиях; пробный период истекает или расходует временный кредит. Проверьте действующий договор и поведение при достижении предела.

Какие единицы должна сравнивать команда?

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

Доказывает ли приём письма бесплатным SMTP доставку?

Нет. Приём — лишь один этап у провайдера или в транспорте. Приём сервером получателя, последующий отказ, фильтрация в почтовом ящике, попадание во «Входящие» и реакция человека — отдельные результаты.

Можно ли хранить единственный стоп-лист у провайдера?

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

Как обрабатывать исчерпание квоты?

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

Нужны ли SPF, DKIM и DMARC при использовании бесплатных сервисов?

Адресу отправителя по-прежнему нужны корректная аутентификация и выравнивание. Бесплатный тариф не меняет требований получателей, владения доменом или безопасности DNS.

Есть ли у SendHQ бесплатный тариф?

Нет. Новые рабочие пространства получают контролируемый пробный период для интеграции на 100 доставок на email-адрес аккаунта или адрес симулятора AWS SES.

Источники

Что почитать дальше

Как выбрать SMTP-релейОценивайте SMTP-релеи по безопасности отправки, аутентификации, очередям, поведению повторов, лимитам, событиям доставки, стоп-листу, изоляции и удобству миграции.Как оценить SMTP-релей GoogleОценивайте SMTP-релей Google Workspace по модели авторизации, TLS, адресу отправителя, квотам, обработке ошибок, аутентификации, наблюдаемости и рискам миграции.Руководство по внедрению email API для продуктовых командСпроектируйте безопасную интеграцию email API: подтверждённые домены, отправка через очередь, стабильные идентификаторы, контролируемые повторы, события доставки, стоп-лист и изоляция тенантов.Как выбрать сервис доставляемости emailОценивайте сервисы доставляемости по охвату, доказательной базе, аутентификации, петлям обратной связи, стоп-листам, конфиденциальности, переносимости и соответствию вашим процессам.Порты SMTP 25, 465 и 587: практическое руководствоВыберите правильный порт SMTP по роли и режиму TLS, а затем диагностируйте сбои подключения, рукопожатия, аутентификации и приёма письма.