Если письма с WordPress не приходят, сначала выясни, где прерывается цепочка: форма не создала уведомление, сайт не передал письмо почтовому сервису или получатель его не принял. Сообщение «Заявка отправлена» на странице не подтверждает доставку письма.
Проверяй одну отправку за раз и записывай её время. Так легче сопоставить действие на сайте с журналом плагина и отчётом почтового сервиса. Для теста используй свои адреса и нейтральный текст без данных реальных клиентов.
Определи, какие письма пропали
- Только уведомления одной формы — начни с её настроек и обработки запроса.
- Не приходят также системные письма — проверь общий способ отправки WordPress.
- На один адрес приходит, на другой нет — изучи ответ принимающего сервера и фильтрацию.
- Тестовое письмо SMTP-плагина приходит, а заявка нет — вернись к форме: тест мог обойти её логику.
Проверь папки спама, правила пересылки, заполненность ящика и точное написание получателя. Если проблема возникла после переноса, выясни, сохранились ли настройки почты и разрешает ли новый хостинг исходящие подключения к выбранному сервису.
Проверь форму и адреса уведомлений
В настройках формы найди включённое уведомление, адрес получателя и условия его отправки. Некоторые формы сохраняют заявку в базе отдельно от письма. Если запись появилась, данные дошли до сайта, но уведомление всё ещё могло не сформироваться. Если записи нет, проверь ошибки формы, антиспам и серверную обработку.
Посмотри, что происходит после нажатия кнопки на мобильном и настольном устройстве. Красивое сообщение может показываться даже при неверной обработке ошибки в коде. Для разработчика полезны статус сетевого запроса и серверный журнал; владельцу достаточно передать время теста и последовательность действий.
Поле From лучше задавать адресом подтверждённого домена, например website@example.com. Email посетителя используй как Reply-To, если плагин это поддерживает и проверяет значение. Подстановка чужого ящика в From может нарушить проверку отправителя. Адрес получателя при этом остаётся твоим рабочим ящиком.
Проверь способ отправки WordPress
Многие плагины используют функцию wp_mail(). Успешный результат её вызова означает, что на этом этапе не выявлена ошибка передачи, но не подтверждает получение письма человеком. Если используется отдельный API почтового сервиса, его ответ и события доставки тоже нужно смотреть отдельно.
На сайте без настроенного внешнего сервиса отправка зависит от конфигурации хостинга. Установка SMTP-плагина помогает явно задать транспорт, но сама по себе ничего не гарантирует: нужны рабочие доступы, подходящий отправитель и разрешённое сетевое подключение.
Как настроить SMTP без случайного подбора параметров
Выбери один способ отправки и один отвечающий за него плагин. Несколько активных плагинов почты могут переопределять настройки друг друга. Перед изменением сохрани текущую конфигурацию так, чтобы можно было вернуть её, не публикуя секреты.
- Возьми адрес SMTP-сервера, порт и режим шифрования из документации почтового провайдера.
- Используй поддерживаемый способ авторизации: это может быть пароль приложения, OAuth или отдельные учётные данные сервиса.
- Подтверди адрес или домен отправителя, если этого требует провайдер.
- Отправь тестовое письмо на свои ящики и посмотри результат в журнале сервиса.
- После успешного теста отправь именно реальную форму сайта и проверь письмо с её данными.
Порт 465 или 587 выбирают вместе с соответствующим режимом подключения, а не по принципу «какой заработает». При тайм-ауте уточни у хостинга, разрешён ли исходящий трафик. При ошибке авторизации проверь учётные данные и разрешения аккаунта. Отключать TLS-проверку ради исчезновения ошибки не стоит.
Зачем проверять SPF, DKIM и DMARC
SPF описывает разрешённые источники отправки для домена, используемого в проверке. DKIM добавляет подпись, которую получатель может проверить через DNS. DMARC связывает проверки с видимым доменом From и задаёт политику обработки. Все три механизма относятся к подлинности отправителя, а не к работе кнопки формы.
Записи бери у своего почтового сервиса. Не добавляй вторую независимую SPF-запись рядом с существующей: сначала нужно учесть все разрешённые источники в одной политике. Для DKIM важно правильное имя записи с селектором. Строгую DMARC-политику не включай наугад, пока не проверены все легитимные отправители домена.
В полученном тестовом письме открой служебные заголовки или функцию просмотра оригинала. По результатам аутентификации можно понять, прошли ли проверки. Даже успешные SPF, DKIM и DMARC не гарантируют попадание во входящие: остаются репутация, содержание и правила получателя.
Какие сведения дают журналы
Различай статусы: ошибка соединения, отказ в авторизации, принятие сервисом, временная задержка и окончательный отказ получателя. Если сервис принял письмо, а адресат отказался, нужен текст отказа или событие bounce. Повторная установка плагина на сайте эту причину не устранит.
Для разработчика у WordPress есть хук wp_mail_failed, который помогает перехватить ошибку на этапе отправки. Но отсутствие события не доказывает доставку, а плагины с собственным транспортом могут вести отдельный журнал. Не оставляй полное содержимое заявок и секреты в общедоступном debug.log.
Как убедиться, что заявки доходят
Отправь тестовую заявку через сайт и сопоставь её время с журналом сервиса и письмом в ящике. Проверь тему, адрес для ответа и все поля. Повтори тест после переезда, смены домена или существенного обновления формы. Если форма сохраняет обращения в админке, проверь и этот резервный способ получения заявок.
Для обращения в поддержку подготовь время теста, домен отправителя, текст ошибки и идентификатор письма из журнала. Пароль SMTP и содержимое реальной заявки не нужны в публичной переписке. Когда письмо доставляется, удали тестовые данные и отключи лишнее подробное логирование.
Если письма перестали уходить после смены хостинга, начни с проверки по инструкцией по переносу WordPress.
Документация
Функция wp_mail · Хук wp_mail_failed · Требования Gmail к отправителям.