Defaults.Exposed › Исправления › Guides
Письма с контактной формы уходят в спам — исправляем отправку с веб-сервера (2026)
Опубликовано 2026-07-08
Данные по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 миллионам оценённых доменов. См. как мы выставляем оценки.
Письма с контактной формы и с сайта попадают в спам, потому что ваш веб-сервер отправляет их без аутентификации — без авторизации по SPF и без DKIM-подписи. Надёжное решение — направить эту почту через аутентифицированный SMTP, а не вносить сервер в белые списки. 46,4% из 261 086 232 доменов, оценённых в переписи Defaults.Exposed (данные на 2026-06-29), вообще не публикуют SPF-запись.
Порядок действий имеет значение, и большинство инструкций описывают его задом наперёд. Запустите бесплатное сканирование, чтобы увидеть, что ваш домен публикует на самом деле; направьте почту сайта через аутентифицированный SMTP (вашего почтового провайдера или транзакционный почтовый сервис), чтобы письма получали настоящую DKIM-подпись; исправьте адрес From у формы; и только в крайнем случае добавляйте IP сервера в SPF.
Почему письма с моего сайта уходят в спам?
Потому что важно, кто на самом деле их отправляет. Когда посетитель отправляет вашу контактную форму, письмо шлёт не ваш почтовый провайдер — веб-сервер формирует его сам, обычно через PHP-функцию mail(). С точки зрения принимающей стороны такое сообщение:
- приходит с IP-адреса, который не авторизован вашей SPF-записью (ваш SPF покрывает почтового провайдера, а не хостинг сайта);
- не несёт DKIM-подписи, то есть ничто криптографически не связывает его с вашим доменом;
- часто уходит с IP-адреса виртуального хостинга, репутацию которого формируют сотни чужих сайтов.
Неаутентифицированная почта с IP смешанной репутации — ровно то, для чего существуют спам-фильтры: Gmail и Outlook видят случайный сервер, выдающий себя за вас. Общая картина мрачна: 46,4% доменов вообще не публикуют SPF, и лишь 10,59% (27 640 987 из 261 086 232 оценённых доменов, перепись на 2026-06-29) применяют политику DMARC с реальными санкциями.
Почему это особенно касается сайтов на WordPress?
WordPress отправляет всю свою почту — уведомления с форм, сброс паролей, подтверждения заказов — через одну функцию, wp_mail(), которая по умолчанию оборачивает PHP-функцию mail() на веб-сервере. Любой сайт на WordPress, который никто сознательно не перенастраивал, «из коробки» является неаутентифицированным отправителем. Плагины форм (Contact Form 7, WPForms, Gravity Forms) передают почту всё той же функции: выглядит как проблема плагина, но на деле это проблема транспорта.
Решение — не другой плагин форм, а SMTP-плагин (WP Mail SMTP и его аналоги), который перенаправляет всё, что отправляет wp_mail(), через настоящую аутентифицированную почтовую учётную запись — инфраструктуру, которую ваш SPF уже авторизует, с прикреплённой DKIM-подписью.
Каким способом отправки должен пользоваться сайт?
| Способ отправки | SPF | DKIM | Переживёт смену хостинга? | Вердикт |
|---|---|---|---|---|
PHP mail() / стандартный wp_mail() с веб-сервера | не проходит | нет | н/д — сломан везде | сама проблема, а не вариант |
| Аутентифицированный SMTP через вашего почтового провайдера (Google Workspace, Microsoft 365 и т. п.) | проходит | подписано | да — не зависит от хостинга | решение для большинства сайтов |
| Транзакционный почтовый сервис (SES, Postmark, Brevo и т. п.) с подтверждённым доменом | проходит | подписано | да | решение при больших объёмах (интернет-магазины, крупные формы) |
| IP веб-сервера, добавленный в вашу SPF-запись | проходит (только SPF) | нет | нет — молча ломается при смене IP | лишь запасной вариант — см. ниже |
Для нескольких уведомлений в день SMTP через почтовый ящик, за который вы уже платите, — кратчайший путь; при реальных объёмах для этого создан транзакционный сервис. Оба варианта дают вам DKIM — короткий путь с внесением IP в белый список не даёт его никогда.
Как исправить доставляемость писем с контактной формы?
- Запустите бесплатное сканирование на defaults.exposed, прежде чем что-либо менять. Оно покажет, какие записи SPF, DKIM и DMARC ваш домен публикует на самом деле — чините ли вы транспорт формы, отсутствующую запись или и то и другое. SPF нет вообще? Начните с как исправить SPF.
- Создайте отдельную SMTP-учётную запись для сайта — например,
[email protected]у вашего почтового провайдера или подтверждённый домен отправки в транзакционном сервисе. Используйте пароль приложения или API-ключ, который можно отозвать, а не пароль от чьего-то личного ящика. - Направьте почту сайта через неё. WordPress: установите SMTP-плагин и укажите в нём эту учётную запись. Другие стеки: настройте почтовый модуль фреймворка вместо локальной
mail(). - Исправьте адрес From (антипаттерн описан ниже): в From должен стоять ваш собственный домен; адрес посетителя — в Reply-To.
- Если отправителем выступает транзакционный сервис, добавьте его DKIM-записи (обычно пару CNAME), чтобы почта подписывалась вашим доменом — действия в DNS повторяют пошаговые инструкции по настройке SPF.
- Отправьте тестовую заявку и просканируйте домен заново. В заголовках должно быть
spf=passиdkim=passдля вашего домена; затем устраните всё остальное, что отметит сканирование, с помощью исправления SPF и исправления DKIM.
Почему форма отправляет письма «от имени» адреса посетителя?
Самая распространённая самострельная ошибка в настройке форм — а многие плагины раньше делали так по умолчанию: уведомление приходит From: адрес посетителя, чтобы можно было нажать «Ответить». Это удобно — и это подделка. У вашего сервера нет права отправлять почту от имени [email protected] — такое письмо не проходит SPF и DKIM для gmail.com, а политика DMARC у Gmail предписывает получателям отправлять его в спам или отклонять. Исправление не стоит ничего:
- From: адрес на вашем собственном домене (SMTP-учётная запись из шага 2)
- Reply-To: адрес посетителя — ответ по-прежнему уходит прямо ему
Это поддерживает каждый популярный плагин форм; это два поля в настройках уведомлений.
Почему бы просто не добавить IP сервера в мою SPF-запись?
Это решение, за которое первым делом хватаются на форумах, — и оно не зря лишь запасной вариант. Добавление ip4:<server> (или механизма a для вашего хостинга) в SPF действительно заставляет формальную проверку проходить — но:
- На виртуальном хостинге вы авторизуете посторонних. IP принадлежит серверу, а не вам; каждый другой сайт на этом сервере теперь может отправлять проходящую SPF почту от имени вашего домена.
- Это ломается молча. Хостинги переносят серверы и меняют IP, не предупреждая вас; ваш SPF продолжает авторизовать адрес, с которого вы съехали месяцы назад.
- Это не даёт вам DKIM. SPF сам по себе ломается при пересылке и не может привести вас к принудительной политике DMARC так, как это делает подпись.
Оставьте этот путь для действительно безвыходного случая: выделенный сервер со статическим IP под вашим контролем и приложение, не умеющее работать по SMTP, — и, если возможно, дополните его DKIM-подписью на самом сервере.
А проверяет ли SPF вообще адрес, который форма ставит в «From»?
Нет — и на этом спотыкается половина самостоятельных диагнозов. Получатели проверяют SPF по домену Return-Path (RFC5321.MailFrom), а не по заголовку From. Веб-серверы часто подставляют в Return-Path собственное имя хоста, так что ваша SPF-запись вообще не участвовала в проверке — получатель проверял SPF для srv0421.examplehost.com. Аутентифицированный SMTP исправляет и это: Return-Path становится вашим доменом, и прохождение SPF наконец засчитывается вам. Поэтому же важен DKIM — для выравнивания DMARC нужен пройденный тест, привязанный к домену в From, а DKIM-подпись путешествует вместе с сообщением.
Часто задаваемые вопросы
Исправит ли SMTP-плагин также письма о сбросе пароля и письма WooCommerce?
Да. В WordPress всё проходит через wp_mail(), поэтому его перенаправление одним махом чинит уведомления с форм, сброс паролей и письма о заказах.
Нужны ли мне записи SPF и DKIM, если я использую SMTP-плагин? Да — плагин меняет то, какая инфраструктура отправляет вашу почту, а записи — то, что её авторизует. Если ваш домен входит в те 46,4% из 261 086 232 оценённых доменов без SPF-записи (перепись, 2026-06-29), один только аутентифицированный SMTP вас не спасёт. Полный набор записей описан в чек-листе почты для нового домена.
Письма с моей формы проходят SPF, но всё равно не проходят DMARC — почему? Почти всегда это описанный выше антипаттерн с подделкой From, либо SPF проходит для домена Return-Path хостинга, а не вашего. Сначала исправьте From/Reply-To; если всё ещё не проходит, недостающее звено — выровненная DKIM-подпись, см. «DKIM signature not valid». Если, помимо сайта, не проходят и SaaS-инструменты, порядок исправления описан в руководстве по SPF для SaaS.
Стоит ли всё это усилий ради контактной формы с небольшим трафиком? Обычно именно через форму приходят деньги — пропущенная заявка означает клиента, о потере которого вы даже не узнали. А исправление бесплатно; барьер лишь в том, чтобы понять: неаутентифицированным отправителем всё это время был веб-сервер.
Отправьте владельцу отчёт
Если вы разработчик или подрядчик, который это чинит: когда тестовая заявка проходит проверки, повторно запустите бесплатное сканирование и перешлите отчёт с оценкой владельцу сайта — датированное, написанное простым языком свидетельство того, что домен аутентифицируется корректно, и артефакт, который понадобится при следующем продлении киберстраховки или анкете безопасности от клиента. Если вы владелец и читаете это, потому что заявки перестали приходить: отправьте эту страницу и отчёт о сканировании тому, кто отвечает за ваш сайт, — работа на один вечер, с наглядным «до и после».
Проверьте свой домен → · SPF не проходит для ваших SaaS-инструментов? → · Исправить SPF → · Как мы выставляем оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.