Как проверить и исправить доставку системных писем в WordPress

Если на сайте перестали приходить письма о регистрации, сбросе пароля, уведомлениях администратора или письма из форм, проблема часто не в самом WordPress, а в том, как сервер отправляет почту. На shared-хостинге это обычно mail() без нормальной аутентификации, на VPS — неверный SMTP, DNS или блокировка порта. Ниже разберём, как быстро понять, где ломается цепочка, и что именно исправлять.

Как выглядит проблема на практике

Системные письма WordPress — это не маркетинговая рассылка. Они должны уходить стабильно: подтверждение регистрации, сброс пароля, уведомления о новых комментариях, письма от плагинов, сообщения из формы обратной связи. Если они не доходят, пользователь не может войти в аккаунт, а администратор теряет контроль над сайтом.

Типичные симптомы:

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

Диагностика: где именно рвётся отправка

Сначала нужно понять, WordPress не формирует письмо, сервер не отправляет его или получатель его отклоняет. Это три разные проблемы, и лечатся они по-разному.

Проверьте, создаётся ли письмо в WordPress

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

<?php
add_filter('wp_mail', function ($args) {
    error_log('wp_mail to: ' . print_r($args['to'], true));
    error_log('wp_mail subject: ' . $args['subject']);
    return $args;
});

Если в debug.log нет записи, значит код до отправки не доходит. Тогда смотрите форму, плагин уведомлений или кастомный код темы.

Проверьте серверную отправку

Если WordPress письмо формирует, но оно не уходит, проблема обычно в почтовом транспорте. На многих серверах функция mail() либо ограничена, либо работает без нормальной аутентификации, из-за чего письма режутся фильтрами получателя.

Для проверки полезно включить лог SMTP-плагина или отправить тестовое письмо на внешний ящик: Gmail, Outlook, Яндекс Почта. Если тест не проходит, смотрите:

• верный ли SMTP-хост;
• правильный ли порт: обычно 587 для STARTTLS или 465 для SSL;
• не блокирует ли хостинг исходящие соединения;
• совпадает ли From с доменом, для которого настроены DNS-записи.

Проверьте DNS: SPF, DKIM, DMARC

Если письмо уходит, но попадает в спам или отклоняется, без DNS уже не обойтись. Для домена отправителя должны быть корректно настроены SPF и DKIM, а DMARC — хотя бы в режиме мониторинга. Иначе получатель видит несогласованность между адресом отправителя и реальным сервером, с которого ушло письмо.

Минимум, что стоит проверить в DNS:

• есть ли SPF-запись и не содержит ли она лишних include;
• подписываются ли письма DKIM-ключом;
• не конфликтуют ли несколько SPF-записей в одной зоне;
• совпадает ли домен в From с доменом SMTP-сервиса.

Что делать: рабочая схема исправления

Самый надёжный путь для WordPress — не полагаться на mail(), а отправлять системные письма через SMTP-сервис с нормальной аутентификацией и логами. Это особенно важно, если сайт живёт на обычном хостинге и вы не контролируете MTA на сервере.

Шаг 1. Выберите SMTP-сервис под системные письма

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

• SMTP-доступ;
• подпись DKIM;
• понятные логи отправки;
• возможность использовать отдельный домен или поддомен для почты.

Если нужен практичный вариант без лишней настройки, смотрите в сторону сервисов, которые нормально работают именно как транзакционные. Для сайта это важнее, чем «большой ящик» у обычной почты.

Шаг 2. Настройте отправку через SMTP-плагин

На большинстве сайтов проще и безопаснее использовать плагин, чем писать собственный транспорт. Принцип один: WordPress продолжает вызывать wp_mail(), а плагин подменяет способ доставки.

Если нужен минимальный набор действий, логика такая:

1. создать ящик или SMTP-учётку у провайдера;
2. включить SSL/TLS и выбрать правильный порт;
3. указать адрес отправителя, который совпадает с доменом;
4. отправить тестовое письмо;
5. проверить заголовки и статус доставки.

Ниже пример, как можно принудительно задать отправителя через код, если плагин это допускает или если вы настраиваете кастомную отправку:

<?php
add_filter('wp_mail_from', function ($from_email) {
    return 'no-reply@example.com';
});

add_filter('wp_mail_from_name', function ($from_name) {
    return 'Example Site';
});

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

Шаг 3. Проверьте, не ломает ли отправку тема или плагин

Иногда SMTP настроен правильно, но письмо всё равно не уходит из-за фильтров в теме или конфликтующего плагина. Особенно часто это случается, если кто-то переопределил wp_mail, добавил нестандартный MIME-тип или вмешался в заголовки.

Если есть доступ к коду, ищите:

• фильтры wp_mail, wp_mail_from, wp_mail_from_name;
• переопределение phpmailer_init;
• кастомные плагины форм и уведомлений;
• код в functions.php, который меняет заголовки письма.

Сравнение подходов: плагин, код, серверная настройка

Пример кастомной SMTP-настройки через код

Если вы не хотите держать отдельный плагин ради одной задачи, можно настроить PHPMailer через хук phpmailer_init. Такой вариант уместен для небольших проектов, где конфигурация хранится в wp-config.php или в mu-plugin.

<?php
add_action('phpmailer_init', function ($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host = 'smtp.example.com';
    $phpmailer->SMTPAuth = true;
    $phpmailer->Port = 587;
    $phpmailer->Username = 'no-reply@example.com';
    $phpmailer->Password = 'strong-password-here';
    $phpmailer->SMTPSecure = 'tls';
    $phpmailer->From = 'no-reply@example.com';
    $phpmailer->FromName = 'Example Site';
});

Такой код лучше не класть в тему, если тема может обновляться или меняться. Практичнее вынести его в mu-plugin, чтобы не потерять настройки при деплое.

Как проверить, что исправление сработало

После настройки не ограничивайтесь одним тестом из админки. Проверьте цепочку целиком.

• Отправьте письмо на внешний ящик, а не на тот же домен.
• Откройте заголовки письма и проверьте, что оно прошло через нужный SMTP-сервер.
• Посмотрите, нет ли пометки via или подозрительного несоответствия доменов.
• Проверьте папку «Спам» и вкладки «Промоакции»/«Соцсети».
• Сделайте тест сброса пароля и регистрацию нового пользователя, если это доступно на сайте.

Если используете плагин с логами, убедитесь, что в журнале есть статус успешной отправки, а не только факт вызова функции. Успешный вызов wp_mail() ещё не означает, что письмо реально дошло.

Частые ошибки и как их исправить

Неверный адрес отправителя

Ошибка выглядит просто: письма уходят с wordpress@site.local, admin@server123 или другого адреса, который не связан с доменом. Получатели и антиспам-фильтры это не любят. Решение — использовать адрес на своём домене и настроить SPF/DKIM под него.

Используется порт, который блокирует хостинг

Некоторые хостинги режут исходящий 465 или 587, либо разрешают только часть SMTP-серверов. Если тест не проходит, проверьте ограничения у провайдера и попробуйте другой порт или другой SMTP-сервис.

Несколько SPF-записей в DNS

SPF должен быть один. Если в зоне несколько TXT-записей с SPF, часть получателей будет считать домен некорректно настроенным. Объединяйте правила в одну запись и не дублируйте include без необходимости.

Письма отправляются, но не доходят из-за репутации

Даже при правильной настройке домен или IP могут иметь плохую репутацию. Это уже не проблема WordPress. В таком случае помогает отдельный транзакционный SMTP-сервис, корректный From, согласованные DNS-записи и отказ от массовой отправки с того же канала.

Практические советы по безопасности и производительности

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

Ещё несколько полезных правил:

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

Если на сайте уже используется набор инструментов для технической чистки и SEO, вроде Clearfy Pro, его имеет смысл рассматривать не как замену SMTP, а как дополнение: убрать лишние дубли и шум в системе полезно, но доставку писем это не исправит.

Когда проблема не в WordPress

Бывает, что WordPress настроен нормально, а письмо всё равно не доходит. Тогда причина обычно вне CMS: у провайдера плохая репутация IP, на домене нет DKIM, получатель режет письма по политике безопасности, либо сам SMTP-сервис ограничивает отправку. В этом случае нужно смотреть заголовки письма, логи сервиса и DNS, а не искать ошибку в шаблоне темы.

Если нужен стабильный канал именно для системных писем, выбирайте сервис, который рассчитан на транзакционную отправку, а не на обычную ручную почту. Для WordPress это обычно заметно надёжнее, чем попытка заставить mail() работать «как-нибудь ещё».