Любой сайт отправляет письма: подтверждения заказов, ссылки для сброса пароля, сообщения из формы обратной связи, напоминания о бронировании. О транзакционных письмах обычно никто заранее не думает, хотя от них зависит работа всего сайта. Как правило, их один раз настраивает разработчик, после чего к этой настройке больше не возвращаются.
А затем клиенты перестают получать подтверждения заказов и выясняется, что письма уже восемь месяцев попадают в спам. Ниже разберём, почему это происходит на любой платформе и как настроить отправку так, чтобы избежать проблемы.
Почему сбои транзакционной почты остаются незаметными
По умолчанию большинство платформ отправляет письма прямо с веб-сервера через встроенную почтовую функцию языка программирования. Во время проверки всё работает: вы смотрите письма в собственном ящике, а ваш почтовый сервис доверяет вашим сообщениям.
В рабочей среде проблема возникает по причинам, не связанным с кодом. У веб-сервера нет репутации отправителя, его IP-адрес используется совместно с другими клиентами хостинга, а письмо представляется отправленным с вашего домена, хотя приходит с сервера, которому домен не давал такого права. Почтовые сервисы воспринимают именно такую картину как подделку, поскольку чаще всего это и есть подделка. Поэтому требования Google к отправителям предусматривают обязательную аутентификацию.
Со стороны сайта сбой никак не заметен. Сайт сообщает об успешной отправке, в журналах нет ошибок, и ничто не указывает, что на стороне получателя письмо оказалось в папке «Спам». Транзакционная почта почти не сообщает о собственных неполадках, поэтому о проблеме обычно узнают лишь через несколько месяцев из жалобы клиента.
Одна и та же проблема на любой платформе
Проблема не ограничивается WordPress. Его обвиняют чаще всего лишь потому, что это самая распространённая платформа. Сам механизм везде одинаков.
WordPress по умолчанию использует функцию mail в PHP, то есть отправляет письма непосредственно с сервера со всеми описанными выше недостатками. Стандартное решение состоит в установке SMTP-плагина.
Shopify, Wix и Squarespace отправляют транзакционные письма через собственную инфраструктуру, за которой обычно хорошо следят. Однако без дополнительной настройки эти сервисы не всегда позволяют корректно авторизовать отправку с вашего домена. В результате письмо, указанное как отправленное от вашего имени, невозможно уверенно связать с вашим доменом.
Webflow, Ghost и собственные приложения устроены по-разному, но закономерность сохраняется: стандартный способ отправки редко проходит аутентификацию от имени вашего домена.
Для любой платформы решение одно: передавать транзакционные письма через аутентифицированное SMTP-соединение и использовать домен, DNS-записи которого разрешают этому соединению отправку.
Решение из трёх частей
Необходимы три компонента. Если настроить только два из них, письма всё равно могут попадать в спам.
SMTP-аккаунт для отправки. Вместо прямой отправки с веб-сервера сайт авторизуется на почтовом сервере и передаёт ему письмо. Такая возможность есть на любой платформе, либо изначально, либо через плагин.
DNS-записи, разрешающие отправку. В записи SPF должен быть указан сервер отправителя, а DKIM должен добавлять к письму проверяемую подпись. Без них даже аутентифицированная отправка выглядит для сервера получателя несанкционированной. Настройка самих записей описана в наших руководствах по SPF и DKIM.
Реально существующий адрес отправителя. Письма с адреса noreply@yourdomain.com, для которого не создан почтовый ящик, получают небольшой, но вполне реальный минус при оценке надёжности. Кроме того, ответы на них пропадают. У нас создание такого ящика ничего не стоит, поскольку оплата не зависит от количества пользователей.
Как отделить автоматические письма от переписки
При достаточно большом объёме транзакционные письма с сайта стоит отправлять по отдельному маршруту.
Автоматические и написанные людьми письма ведут себя по-разному, поэтому почтовые сервисы оценивают их по-разному. Всплеск из пятисот запросов на сброс пароля после инцидента безопасности совсем не похож на обычную переписку. Если оба вида писем отправляются одним путём, репутация автоматического трафика начинает влиять и на деловую переписку.
Отдельные SMTP-профили для доменов позволяют легко развести эти потоки. Домен приложения направляется по одному маршруту, а домен сотрудников по другому. Тогда проблема в одном потоке не затронет второй. Практическая настройка описана в материале про отдельный SMTP для каждого домена.
Некоторые компании полностью переносят автоматические письма на отдельный поддомен. Это полностью изолирует репутацию, но адрес отправителя выглядит чуть менее аккуратно. Целесообразность такого решения зависит от объёма отправки.
Когда нужен специализированный транзакционный сервис
Важно честно обозначить границу: при действительно больших объёмах специализированные сервисы транзакционной рассылки нужны неслучайно.
Если вы отправляете десятки тысяч писем в день, понадобятся события доставки для каждого сообщения, уведомления о возвратах через вебхуки, управление шаблонами и подробная аналитика. Ради этих задач такие сервисы и создаются, поэтому обычный почтовый хостинг не сможет выполнять их столь же хорошо.
Наши суточные лимиты рассчитаны на переписку, а не на массовые рассылки: 1 000 сообщений на ящик в тарифе Starter и до 2 500 в тарифе Agency. Транзакционная почта небольшого магазина или системы бронирования без труда укладывается в эти рамки. Для крупной платформы этого недостаточно. В таком случае правильнее подключить транзакционный сервис через отдельный SMTP-профиль. Так почтовый хостинг и массовая отправка останутся разделены, а пользоваться двумя почтовыми сервисами не придётся.
Как убедиться, что всё работает
Главное правило: проверять, а не предполагать, ведь сбои в этой категории остаются незаметными.
Инициируйте настоящее письмо: оформите тестовый заказ или запросите сброс пароля. Отправьте его на адреса у двух разных крупных почтовых провайдеров. Откройте заголовки и убедитесь, что проверки SPF и DKIM пройдены, а отчёт DMARC подтверждает согласованность доменов. Успешное прохождение всех трёх проверок означает, что настройка действительно завершена.
Повторяйте такую проверку раз в квартал, а также сразу после любых изменений DNS или хостинга. Чаще всего транзакционная почта ломается не при первоначальной настройке, а после изменения связанного с ней компонента. Например, после смены DNS-серверов почти никто не догадывается заново проверить подтверждения заказов.
Если письма доходят, но оказываются в спаме, собственная статистика доставки домена и отчёты DMARC обычно укажут причину быстрее, чем попытки наугад менять содержание.
