Как настроить почту сайта: SMTP, SPF, DKIM и DMARC для надежной доставки писем

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

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

В этой статье разберем, как правильно настроить почту сайта, зачем нужен SMTP, какие DNS-записи отвечают за репутацию домена и как проверить, что сообщения действительно доходят до получателей.

Почему почта сайта не должна работать через случайный сервер

Многие сайты отправляют письма через стандартную функцию сервера. Такой способ может работать на небольшом тестовом проекте, но для коммерческого сайта он создает сразу несколько рисков:

• письма отправляются с технического адреса, который не связан с доменом компании;
• сервер не имеет настроенной аутентификации отправителя;
• сообщения попадают в спам из-за отсутствия SPF, DKIM или DMARC;
• хостинг ограничивает количество отправляемых писем;
• ошибки доставки не записываются и остаются незаметными;
• злоумышленники могут попытаться использовать домен для поддельной рассылки.

Кроме того, отправка через встроенную почтовую функцию часто не дает нормального контроля над параметрами письма. Нельзя уверенно определить, какой сервер отправил сообщение, прошла ли проверка домена и почему конкретный адрес получателя отклонил письмо.

Для сайта лучше использовать отдельный SMTP-сервис или SMTP-сервер корпоративной почты. В этом случае приложение проходит авторизацию, отправляет сообщения через контролируемый канал и получает технический ответ о результате операции.

Что такое SMTP и зачем он нужен сайту

SMTP — протокол, с помощью которого почтовые программы и сайты передают исходящие сообщения почтовым серверам. Когда посетитель заполняет форму, сайт формирует письмо и передает его SMTP-серверу. Сервер проверяет учетные данные, принимает сообщение и пытается доставить его почтовому серверу получателя.

На практике сайт может использовать несколько вариантов отправки:

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

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

Какие данные нужны для подключения SMTP

Обычно провайдер предоставляет следующие параметры:

• адрес SMTP-сервера;
• порт подключения;
• логин или адрес отправителя;
• пароль либо отдельный пароль приложения;
• тип шифрования, например TLS или SSL;
• разрешенный адрес отправителя.

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

Как выбрать адрес отправителя

Для системных сообщений лучше использовать адрес на собственном домене, например no-reply@company.example или support@company.example. Такой адрес понятен пользователю и согласуется с доменом сайта.

Однако адрес no-reply не всегда подходит для бизнеса. Если письмо содержит предложение связаться с компанией, лучше использовать адрес, на который действительно отвечают. Для уведомлений о заявке можно настроить:

• адрес отправителя — корпоративный адрес сайта;
• адрес получателя — менеджер или отдел продаж;
• адрес для ответа — почта клиента из формы.

Нельзя бездумно подставлять пользовательский email в поле отправителя. Например, если посетитель указал адрес на бесплатном почтовом сервисе, сайт не должен отправлять сообщение от его имени. Такая схема нарушает проверку домена и часто приводит к отклонению письма.

Правильнее указывать пользовательский адрес в поле Reply-To. Тогда менеджер сможет нажать «Ответить» и написать клиенту, а фактическим отправителем останется подтвержденный адрес сайта.

SPF: как подтвердить разрешенные серверы

SPF — DNS-запись, которая сообщает почтовым системам, какие серверы имеют право отправлять письма от имени домена. Получающий сервер сверяет IP-адрес отправителя с правилами SPF и учитывает результат при оценке сообщения.

SPF хранится в TXT-записи домена. Ее значение зависит от конкретного провайдера. Поэтому нельзя копировать случайную запись из инструкции для другого сервиса. В нее должны входить именно те серверы и диапазоны, которые разрешены вашим почтовым провайдером.

Общий принцип выглядит так:

• в домене создается одна TXT-запись SPF;
• в нее добавляется разрешение для SMTP-провайдера;
• при необходимости указываются другие легитимные источники отправки;
• в конце выбирается политика для серверов, которых нет в списке.

Ключевая ошибка — создание нескольких SPF-записей для одного домена. Почтовые системы могут не объединить их корректно, поэтому итоговая проверка завершится ошибкой. Если письма отправляются через несколько сервисов, их правила объединяют в одну запись.

Что проверить в SPF

• существует ли только одна SPF-запись;
• указан ли актуальный SMTP-провайдер;
• удалены ли старые сервисы, которыми компания больше не пользуется;
• не превышено ли допустимое количество DNS-запросов при обработке записи;
• соответствует ли политика требованиям бизнеса.

SPF не шифрует письмо и не доказывает, что сообщение не изменялось после отправки. Он отвечает только на вопрос, разрешено ли конкретному серверу отправлять письма от имени домена. Для полноценной защиты его используют вместе с DKIM и DMARC.

DKIM: электронная подпись исходящих писем

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

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

Для настройки DKIM обычно выполняют следующие действия:

1. создают домен или отправителя в панели почтового сервиса;
2. получают имя селектора и значение открытого ключа;
3. добавляют TXT-запись в DNS;
4. ждут обновления DNS;
5. запускают проверку домена в панели провайдера;
6. отправляют тестовое письмо и проверяют наличие DKIM-подписи.

Имя DKIM-записи обычно содержит селектор. Он нужен, чтобы домен мог использовать несколько ключей одновременно. Это удобно при переходе между сервисами или при разделении почты разных систем.

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

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

Если провайдер предлагает длинный ключ, панель DNS должна корректно сохранить его как TXT-значение. При ручном вводе лучше сверяться с документацией регистратора и не менять содержимое записи самостоятельно.

DMARC: правила проверки и защита домена

DMARC определяет, что делать с письмами, которые не проходят проверку SPF и DKIM. Кроме того, он связывает результаты этих проверок с доменом, который видит получатель в поле отправителя.

DMARC помогает решать две задачи:

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

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

1. начинают с режима мониторинга, при котором письма не блокируются;
2. изучают отчеты и находят легитимные источники отправки;
3. исправляют SPF, DKIM и настройки сервисов;
4. переходят к более строгой политике для непрошедших проверку сообщений.

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

Что показывают DMARC-отчеты

Отчеты помогают увидеть, какие серверы пытаются отправлять почту с домена и проходят ли сообщения проверку. В них можно обнаружить:

• законные отправки от корпоративной почты;
• сообщения от подключенного SMTP-сервиса;
• неактуальные записи и старые платформы;
• подозрительную активность от неизвестных источников;
• несоответствие домена в адресе отправителя.

Сырые отчеты DMARC не всегда удобны для ручного анализа. Для постоянного контроля применяют специализированные инструменты, которые группируют данные и показывают источники отправки в понятном виде.

Как связать SPF, DKIM и DMARC

Эти технологии выполняют разные функции, поэтому одна не заменяет другую.

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

В идеальной конфигурации сайт отправляет письмо через авторизованный SMTP-сервис. Сервис подписывает сообщение DKIM, его сервер указан в SPF, а домен отправителя согласуется с политикой DMARC. В результате почтовая система получателя видит согласованную цепочку подтверждений.

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

Как настроить отправку заявок с сайта

Форма заявки должна не просто отправлять письмо, а корректно обрабатывать весь процесс передачи данных. Минимальная схема выглядит так:

1. пользователь заполняет форму;
2. сервер проверяет обязательные поля и формат данных;
3. данные передаются в систему отправки;
4. письмо отправляется менеджеру через SMTP;
5. пользователь получает понятное подтверждение;
6. результат отправки записывается в журнал.

Не стоит показывать посетителю сообщение «Заявка отправлена», если SMTP-сервер вернул ошибку. Сайт должен различать успешное принятие сообщения и сбой доставки. При технической проблеме пользователь может увидеть нейтральное уведомление с предложением повторить попытку или связаться с компанией другим способом.

Какие поля должны быть в письме

• тема с понятным типом обращения;
• дата и время получения;
• имя клиента;
• телефон или email;
• текст обращения;
• название страницы, с которой отправлена форма;
• метки рекламного источника, если они используются;
• технический идентификатор заявки.

Не следует включать в письмо секретные данные, пароли и полные платежные реквизиты. Если заявка содержит чувствительную информацию, безопаснее передавать менеджеру ссылку на защищенную запись в админке, а не размещать все данные в обычном email.

Безопасность почтовой формы

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

При разработке формы необходимо:

• проверять длину и формат каждого поля на сервере;
• ограничивать частоту отправки с одного адреса и IP;
• защищать форму от автоматических запросов;
• экранировать пользовательские данные в HTML-письме;
• не разрешать произвольные адреса в поле отправителя;
• проверять наличие CSRF-защиты для соответствующего сценария;
• не показывать посетителям внутренние ошибки SMTP;
• вести журнал ошибок без сохранения лишних персональных данных.

Если письмо формируется в HTML, пользовательский текст нельзя вставлять в него без обработки. Иначе злоумышленник может внедрить разметку, которая изменит внешний вид сообщения или будет использоваться в атаке на почтовый интерфейс.

Для отправки от имени сайта следует применять фиксированный подтвержденный адрес. Значение поля From не должно полностью контролироваться посетителем. Его адрес можно передавать в Reply-To, предварительно проверив формат.

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

Транзакционное письмо связано с действием пользователя или операцией в системе. К нему относятся подтверждение регистрации, восстановление пароля, уведомление о заказе и ответ на заявку. Пользователь ожидает такое сообщение, поэтому его доставка особенно важна.

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

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

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

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

Попадание в спам редко объясняется одной причиной. Почтовые системы оценивают совокупность технических и поведенческих сигналов.

Основные причины

• отсутствуют или не совпадают SPF, DKIM и DMARC;
• домен отправителя не согласуется с SMTP-сервисом;
• письма отправляются с плохой репутацией IP-адреса;
• пол