Как отключить отправку писем из WordPress через wp_mail() и настроить SMTP для стабильной доставки

Если письма из WordPress попадают в спам, не доходят до ящика или сайт начинает слать уведомления с неправильного адреса, проблема обычно не в теме и не в WooCommerce, а в том, как именно работает wp_mail(). На хостинге без нормальной почтовой настройки стандартная отправка через PHP mail часто даёт нестабильный результат. В таких случаях практичнее не пытаться «починить» каждое письмо отдельно, а перевести сайт на SMTP и, при необходимости, отключить часть встроенных уведомлений.

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

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

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

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

• письма «отправлены», но не приходят в Inbox;
• уведомления приходят с адреса вида wordpress@server.local или похожего технического домена;
• после обновления плагина или ядра перестают приходить письма о заказах, сбросе пароля, новых комментариях;
• на одном хостинге всё работает, на другом — нет;
• в логах нет явной ошибки, но письмо не доходит.

Что проверить до изменений

Не начинайте с кода. Сначала проверьте базовые вещи:

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

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

Что лучше: плагин, код или настройка сервера

Есть три реальных пути. Выбор зависит от того, кто обслуживает сайт и насколько глубоко вы готовы лезть в инфраструктуру.

На практике чаще всего делают так: SMTP-плагин для доставки, а кодом — только точечные исключения.

Пошаговое решение: переводим WordPress на SMTP

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

Шаг 1. Выберите источник отправки

Подойдёт почтовый ящик на вашем домене или внешний SMTP-сервис. Важно, чтобы у вас были реальные данные для подключения: сервер, порт, логин, пароль, тип шифрования.

Шаг 2. Настройте SMTP-плагин

В интерфейсе плагина обычно нужно указать:

• SMTP host;
• порт: чаще 587 для TLS или 465 для SSL;
• шифрование;
• имя пользователя и пароль;
• адрес отправителя, который совпадает с доменом или разрешён политикой сервиса.

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

Шаг 3. Зафиксируйте отправителя через код

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

<?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';
} );

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

Шаг 4. Если нужно, отключите лишние уведомления

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

<?php
// Отключить уведомления о смене email администратора.
add_filter( 'send_email_change_email', '__return_false' );

// Отключить уведомления о смене пароля пользователя.
add_filter( 'send_password_change_email', '__return_false' );

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

Как отключить стандартную отправку через PHP mail, если это действительно нужно

Полностью «выключать» wp_mail() на живом сайте обычно не стоит: вы рискуете потерять системные уведомления. Но если задача — принудительно перевести сайт на SMTP и запретить использование дефолтного транспорта, это делают на уровне плагина SMTP, а не через удаление функций WordPress.

Если же вам нужно временно заблокировать отправку на тестовом стенде, можно перехватить письмо и не дать ему уйти:

<?php
add_filter( 'pre_wp_mail', function( $pre, $atts ) {
    if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'staging' ) {
        return true; // имитируем успешную отправку без реального письма
    }

    return $pre;
}, 10, 2 );

Это не отключает почту в продакшене, а лишь позволяет безопасно тестировать формы и уведомления на staging-среде.

Проверка результата после внедрения

После настройки важно не ограничиваться тестовым письмом из плагина. Проверьте несколько сценариев, которые реально используются на сайте.

Чек-лист проверки

• отправка тестового письма из SMTP-плагина;
• сброс пароля пользователя;
• регистрация нового пользователя, если она включена;
• уведомление администратора о новом комментарии;
• если есть WooCommerce — письмо о новом заказе и смене статуса;
• проверка заголовков письма в почтовом клиенте: From, Reply-To, Return-Path.

Если письмо приходит, но всё равно попадает в спам, смотрите не только на WordPress, но и на доменную аутентификацию. Без SPF/DKIM/DMARC даже корректно настроенный SMTP не гарантирует хорошую доставляемость.

Что считать нормальным результатом

Нормально, когда письмо:

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

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

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

Если в From указан адрес с чужим доменом, часть почтовых серверов отклонит письмо или отправит его в спам. Исправление простое: используйте адрес на своём домене или тот, который разрешён SMTP-сервисом.

Конфликт нескольких SMTP-плагинов

Иногда на сайте одновременно стоят два плагина, которые перехватывают wp_mail(). В итоге один плагин подменяет настройки другого, и письма начинают уходить нестабильно. Оставьте один способ отправки и удалите лишний.

Порт и шифрование не совпадают

Классическая ошибка — указать 465 без SSL или 587 без TLS, либо наоборот. Если соединение не устанавливается, сначала проверьте именно эту пару параметров.

Пароль от ящика не подходит для SMTP

Некоторые почтовые сервисы требуют отдельный пароль приложения или включённый доступ по SMTP. Обычный пароль от веб-почты может не работать.

Отключили почту слишком агрессивно

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

Безопасность и производительность

Почта в WordPress — это не только про доставку, но и про безопасность. Не храните SMTP-пароль в открытом виде в репозитории. Если вы добавляете настройки в код, лучше вынести секреты в wp-config.php или использовать настройки плагина, где они хранятся отдельно от темы.

Для производительности важно не превращать отправку писем в тяжёлую синхронную операцию на каждом запросе. Если сайт шлёт много уведомлений, имеет смысл:

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

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

Когда стоит идти не в код, а в почтовый сервис

Если сайт критичен для бизнеса, не пытайтесь держаться на случайной отправке через хостинг. Для заказов, регистраций и сброса пароля важна предсказуемость. В таком случае SMTP-сервис с нормальной репутацией домена и понятными логами обычно надёжнее, чем попытки «докрутить» PHP mail.

Код нужен там, где требуется точечная настройка поведения WordPress. Доставка же должна опираться на инфраструктуру, которую можно проверить и повторить на другом сервере без сюрпризов.