Gravity Forms SMTP - Плагин WordPress

Руководство по настройке Gravity Forms SMTP для надежной отправки писем WordPress

Gravity Forms SMTP - это название, под которым многие пользователи ищут отдельный продукт Gravity SMTP от команды Gravity Forms. В этом руководстве разберем не рекламное описание, а практическую работу с плагином: как подготовить сайт, выбрать почтовое подключение, включить логирование, отправить тестовое письмо, проверить результат и понять, почему письмо могло не уйти.

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

Материал рассчитан на администратора WordPress, владельца сайта, специалиста поддержки или разработчика, который отвечает за письма регистрации, сброса пароля, уведомления форм, письма WooCommerce и другие системные сообщения. Если вы используете Gravity Forms, плагин особенно логичен, но по официальной документации он работает не только с письмами Gravity Forms, а со всеми письмами сайта, которые проходят через штатную функцию wp_mail().

Какую проблему решает плагин и где он действительно полезен

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

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

Самая частая ошибка при настройке SMTP-плагина - считать тестовое письмо единственной проверкой. Тест полезен, но он не заменяет реальную проверку сценария. Письмо формы, письмо WordPress и письмо магазина могут отличаться отправителем, заголовками, вложениями, источником вызова и моментом отправки. Поэтому в руководстве ниже мы будем проверять не только кнопку Send Test, но и журнал, источник письма, статус, тело письма, возможное повторное отправление и отладочный журнал.

Плагин полезен в нескольких типовых ситуациях:

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

При этом Gravity SMTP не является почтовым сервисом в смысле собственной инфраструктуры доставки. Он маршрутизирует письма к выбранному провайдеру. Если домен не подтвержден у провайдера, ключ API неверный, SMTP-порт заблокирован или сам почтовый сервис отклоняет сообщение, плагин не может магически доставить письмо. Его ценность в другом: он делает маршрут отправки понятным, настраиваемым и проверяемым.

Кому подойдет Gravity Forms SMTP, а кому лучше выбрать другой путь

Плагин хорошо подходит сайтам, где уже есть активная квалифицирующая лицензия Gravity Forms и важна единая экосистема. Официальная страница продукта указывает, что Gravity SMTP доступен владельцам определенных лицензий Gravity Forms, а документация уточняет, что сам плагин не требует установленного Gravity Forms на сайте. Это важный нюанс: доступ к загрузке и активации связан с лицензией, но функционально плагин работает как отдельный SMTP-инструмент для WordPress.

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

Есть и случаи, где продукт может быть не лучшим первым выбором. Если у вас нет подходящей лицензии Gravity Forms и вы не планируете ее получать, логичнее посмотреть на SMTP-плагины из каталога WordPress.org. Если вам нужна сложная маршрутизация разных типов писем по разным провайдерам, отдельные альтернативы могут оказаться гибче. Если ваш сайт отправляет письма через плагин, который не использует wp_mail(), Gravity SMTP не будет видеть и обрабатывать эти письма, что прямо отмечено в FAQ продукта.

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

Что проверить перед установкой и первым включением

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

Техническая среда WordPress

Официальные требования Gravity SMTP ориентируются на актуальную производственную версию WordPress, поддерживаемую версию PHP и достаточный лимит памяти. В статье не имеет смысла фиксировать конкретные номера версий, потому что они быстро устаревают. Практически важно другое: сайт должен быть обновлен, хостинг должен поддерживать современный PHP, а администратор должен иметь доступ к разделам плагинов, настройкам и системному отчету.

Перед установкой проверьте:

• Есть ли административный доступ к WordPress и возможность устанавливать плагины.
• Есть ли доступ к аккаунту Gravity Forms, через который доступна загрузка Gravity SMTP.
• Есть ли доступ к почтовому сервису, где будет создан ключ API, OAuth-подключение или SMTP-учетные данные.
• Готов ли домен отправителя: адрес from должен относиться к домену, который вы контролируете.
• Есть ли резервная копия или тестовая копия сайта, если плагин меняет критичные письма живого проекта.

Почтовый сервис и домен отправителя

Gravity SMTP поддерживает набор готовых интеграций и вариант Custom SMTP. Готовая интеграция обычно удобнее, потому что она использует API или официальный способ подключения конкретного провайдера. Custom SMTP нужен, когда вы подключаете сервер хостинга, корпоративный SMTP или сервис, для которого нет отдельной карточки интеграции.

Не начинайте с произвольного адреса gmail.com или yahoo.com в поле отправителя, если сайт работает на домене компании. Для транзакционных писем лучше использовать адрес на своем домене, например Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра., а у провайдера подтвердить домен и нужные DNS-записи. Это не настройка самого WordPress-плагина, но без нее даже корректная интеграция может давать слабый результат.

Старые SMTP-плагины и конфликт маршрутизации

Если на сайте уже установлен WP Mail SMTP, FluentSMTP, Post SMTP, Easy WP SMTP или другой похожий инструмент, не включайте одновременно два активных маршрутизатора почты. Мастер Gravity SMTP умеет предлагать миграцию с поддерживаемых решений и может подтянуть часть настроек, но документация отдельно предупреждает: после миграции прежний плагин все равно нужно отключить, когда вы убедились, что новая настройка работает.

Практическое правило: сначала настраивайте Gravity SMTP на тестовой копии или в период низкой активности, затем отправьте тестовое письмо, проверьте реальное письмо формы или регистрации, изучите журнал, и только после этого отключайте старый SMTP-плагин на живом сайте.

Установка и мастер настройки без лишнего риска

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

Типовой порядок действий

1. Скачайте ZIP-архив Gravity SMTP из аккаунта Gravity Forms, если он доступен вашей лицензии.
2. В WordPress откройте Plugins, затем Add New и загрузите ZIP через Upload Plugin.
3. Активируйте плагин и запустите мастер настройки, если он открылся автоматически.
4. Добавьте лицензионный ключ, чтобы плагин мог получать обновления.
5. Если мастер нашел старый SMTP-плагин и предлагает импорт, используйте миграцию только для поддерживаемого провайдера и затем проверьте вручную недостающие поля.
6. Выберите основную интеграцию или Custom SMTP.
7. Сохраните настройки, дождитесь статуса настроенной интеграции и отправьте тестовое письмо.

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

Когда мастер лучше пропустить

Пропуск мастера оправдан, если вы точно знаете, какой провайдер будет использоваться, и хотите настроить все вручную в SMTP -> Settings -> Integrations. Еще один вариант - сайт уже подготовлен через constants в сетевой установке WordPress, а отдельным сайтам не нужно проходить OAuth-подключение. Но для обычного сайта мастер быстрее и снижает риск пропустить базовые поля.

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

Выбор интеграции: API-сервис, Custom SMTP или резервное подключение

В разделе интеграций Gravity SMTP показывает карточки доступных почтовых сервисов. Список расширяется, но на официальной странице и в документации перечислены популярные варианты: SendGrid, Mailgun, Postmark, Brevo, Google / Gmail, Microsoft 365 / Outlook, Amazon SES, Mailtrap, Cloudflare Email Service, SMTP.com, MailerSend, Mailjet, SMTP2GO, SparkPost, Zoho Mail, Resend и другие. Также есть Custom SMTP для собственного сервера или провайдера без отдельной карточки.

Выбор нужно делать не по знакомому названию, а по сценарию сайта. Маленький корпоративный сайт с несколькими формами может использовать сервис, который уже есть у компании. Интернет-магазину важнее стабильность транзакционных писем и понятные лимиты. Сайту с большим количеством регистраций нужны журналы, фильтры, контроль отказов и понятная диагностика. Для тестирования форм и разработческих стендов может быть удобен Mailtrap или другой сервис, где письма не уходят реальным пользователям.

Параметры Custom SMTP, которые чаще всего ломают отправку

В Custom SMTP ключевые поля выглядят знакомо: SMTP Host, SMTP Port, Authentication, Encryption, Authentication Username, Authentication Password, Default From Email, Default From Name, Force From Email и Force From Name. Но знакомый интерфейс не означает, что можно подставить значения наугад.

Если провайдер требует TLS, не ставьте SSL только потому, что "так всегда было в старом плагине". Если порт не соответствует выбранному шифрованию, отправка может зависнуть на долгий тайм-аут. Если включить Force From Email, плагин будет заменять адрес отправителя у всех исходящих писем, а это может быть правильно для брендированной отправки, но неудобно для отдельных плагинов, которые осознанно указывают свой From. Включайте принудительную замену только когда точно хотите привести все письма к одному доменному отправителю.

Резервное подключение как защита от временного сбоя

Резервное подключение в Gravity SMTP используется как запасной канал, если основная интеграция не смогла отправить письмо. В интерфейсе нужно открыть SMTP -> Settings -> Integrations, найти настроенную карточку и выбрать Set As Backup в меню карточки. После этого у интеграции появляется отметка резервного канала.

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

Настройки после установки, которые стоит пройти вручную

После мастера настройки откройте SMTP -> Settings. В этом разделе собраны параметры, которые влияют на поведение всего плагина: лицензия, общий режим, интеграции, управление письмами WordPress, логирование, отладка, экспериментальные функции и удаление данных при деинсталляции. Не все нужно менять сразу, но пройтись по вкладкам стоит обязательно.

Вкладка Settings: лицензия, тестовый режим и аналитика

На базовой вкладке проверьте статус лицензии. Это не про покупку, а про обновления и доступ к продукту. Затем обратите внимание на Test Mode. Этот режим нужен, когда вы хотите тестировать сайт без реальной передачи писем провайдеру. На живом сайте его легко забыть включенным, а потом долго искать, почему пользователи не получают письма. Поэтому после любой настройки задайте себе простой вопрос: "Сейчас сайт должен реально отправлять письма или только имитировать отправку?"

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

Вкладка Integrations: статус, primary и backup

Здесь важно смотреть не только на то, что карточка заполнена. У интеграции должен быть понятный статус, она должна быть включена, и при необходимости назначена как основная. В интерфейсе карточек доступны действия: открыть настройки API, отправить тест, назначить основным каналом или резервным каналом. Если карточка не настроена, часть этих действий будет отключена.

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

Вкладка Emails: управление стандартными письмами WordPress

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

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

Вкладка Logging: журнал, тело письма, вложения и срок хранения

Логирование включено по умолчанию для журнала писем, а отладочный журнал по документации выключен по умолчанию. Вкладка Logging позволяет управлять тем, какие данные хранить и как долго. Здесь нужно балансировать между удобством диагностики и нагрузкой на базу данных.

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

В документации указано, что вложения сохраняются в папке вида uploads/gravitysmtp/attachments/[EMAIL LOG ID]/. Это удобно для повторной отправки, но добавляет ответственность: следите за сроком хранения, доступом к файлам и размером резервных копий. Для небольшого сайта достаточно короткого периода хранения логов. Для активного магазина или портала лучше заранее обсудить политику хранения с владельцем данных.

Когда включать отладочный журнал

Отладочный журнал нужен не постоянно, а при диагностике. Он фиксирует ошибки интеграции и процесса отправки, а также помогает подготовить системный отчет для поддержки. Включайте его перед воспроизведением проблемы: включили Debug Logging, отправили тест или повторили действие на сайте, открыли SMTP -> Tools -> Debug Log, изучили запись, затем выключили отладку, если она больше не нужна.

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

Как пользоваться журналом писем и отчетами без лишней тревоги

Журнал писем - один из самых полезных разделов Gravity SMTP. Он показывает письма в обратном хронологическом порядке, позволяет смотреть статус, получателя, источник, сервис, дату и действия. Для администратора это превращает вопрос "Письмо вообще ушло?" из гадания в проверяемый факт.

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

Поиск и фильтры

Когда писем мало, достаточно открыть последние строки журнала. На активном сайте быстро появляются десятки и сотни записей, поэтому поиск и фильтры становятся важнее. Документация описывает поиск по отправителю, получателю, теме и содержимому письма, а также фильтры по статусу, сервису, источнику и датам. Это помогает отвечать на конкретные вопросы: "Уходило ли письмо этому клиенту?", "Какая форма создала уведомление?", "Все ли ошибки связаны с одним сервисом?", "Проблема началась после изменения настроек или была раньше?".

Не удаляйте журнал сразу после первой удачной проверки. Сначала настройте срок хранения так, чтобы у поддержки была история для диагностики. Затем через несколько дней оцените, не растет ли база слишком быстро. Отдельная документация предупреждает, что большие журналы могут замедлять интерфейс, увеличивать размер базы и влиять на резервное копирование.

Просмотр письма, повторная отправка и ограничения

В журнале можно открыть письмо и посмотреть его содержимое в модальном окне, в том числе с переключением между представлением для настольного и мобильного экрана. Это полезно для проверки HTML-писем: сломанная верстка, пустой текст, неверная ссылка или неправильный адрес часто видны сразу.

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

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

Практический пример: проверяем уведомление формы и письмо сброса пароля

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

Цель примера

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

Подготовка

• Основная интеграция Gravity SMTP настроена и включена.
• Старый SMTP-плагин отключен или не перехватывает отправку.
• Test Mode выключен, если вы ожидаете реальную доставку.
• Email Logging включен, чтобы запись появилась в журнале.
• Для проверки тела письма включено Save Email Body, если политика сайта это допускает.
• У вас есть почтовый ящик получателя, который можно проверить.

Шаги проверки

1. Откройте SMTP -> Tools и отправьте тестовое письмо на свой адрес через выбранную интеграцию.
2. Перейдите в SMTP -> Email Log и найдите последнюю запись. Проверьте статус, сервис и получателя.
3. Откройте форму на сайте или страницу сброса пароля и создайте реальное событие отправки.
4. Вернитесь в журнал и найдите новое письмо по теме, получателю или источнику.
5. Откройте детали записи через значок просмотра. Посмотрите, какой сервис использовался и нет ли технических ошибок.
6. Проверьте почтовый ящик получателя, папку спама и служебные метки почтового сервиса.
7. Если письмо не дошло, не повторяйте отправку сразу. Сначала сравните статус журнала и ответ провайдера.

Ожидаемый результат

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

Нюанс, который часто путает

Если письмо формы не появилось в журнале, а тестовое письмо есть, это не обязательно проблема Gravity SMTP. Возможно, форма не отправляет уведомление, уведомление выключено, получатель задан условной логикой, другой плагин отправляет письмо не через wp_mail(), или событие формы не было завершено. В таком случае сначала проверьте настройки самой формы, затем журнал Gravity SMTP.

Режимы контроля: Test Mode, Debug Log, System Report и Activity Digest

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

Test Mode для безопасной проверки

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

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

Debug Log для воспроизводимых ошибок

Отладочный журнал фиксирует ошибки интеграции и процесса отправки. Он не предназначен для постоянного чтения вместо обычного журнала. Включайте его перед повторением проблемы, сохраняйте короткий интервал, отправляйте тест, а затем открывайте SMTP -> Tools -> Debug Log. Если нужно обращаться в поддержку, системный отчет может включать ссылку на отладочный файл, защищенную случайным ключом.

System Report для общения с поддержкой

Системный отчет показывает конфигурацию сайта, которая может влиять на отправку. Он нужен, когда проблема не очевидна: конфликт с плагином, странная среда хостинга, недоступная таблица базы данных, устаревший PHP, нестандартная структура WordPress. Перед отправкой отчета проверьте, не содержит ли он чувствительные данные, и передавайте его только через официальный канал поддержки.

Activity Digest и отчеты

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

Управление стандартными письмами WordPress без потери важных уведомлений

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

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

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

Мини-сценарий для сайта с формами и регистрацией

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

После изменения вкладки Emails проверьте результат не общим тестовым письмом, а конкретным событием. Отключили уведомления о комментариях - создайте тестовый комментарий на копии. Оставили сброс пароля - запросите сброс для тестового пользователя. Так вы проверяете не только SMTP-маршрут, но и сам факт создания письма WordPress.

Безопасность, данные и производительность журналов

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

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

Практичная политика хранения

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

Если вы включили Save Attachments, проверьте, что резервное копирование не разрастается из-за папки вложений. Если включили Save Email Body, помните, что повторная отправка становится удобнее, но объем и чувствительность данных растут. Если включили отладочный журнал, выключайте его после решения проблемы, чтобы не хранить лишний технический след.

Безопасное улучшение без кода

Для Gravity SMTP лучше не придумывать PHP-хуки и самодельные отправители без подтвержденной документации. Более безопасное улучшение - настроить процесс проверки:

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

Кодовые сниппеты в этом руководстве не добавлены намеренно. В открытых источниках подтверждены настройки, constants для отдельных сетевых сценариев и новый developer action в журнале изменений, но без точного имени hook и контракта параметров безопасный рабочий snippet был бы догадкой. Для публикационной инструкции лучше оставить доработки через настройки продукта и официальную документацию разработчика.

Переезд со старого SMTP-плагина без двойной отправки

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

Сначала зафиксируйте, что именно использует старый плагин. Нужны не секреты, а структура: провайдер, тип подключения, адрес отправителя, имя отправителя, включена ли принудительная замена From, есть ли резервный канал, используются ли журналы, сохраняется ли тело писем, есть ли отдельные настройки для магазина, форм или мультисайта. Если просто нажать "импортировать" и закрыть старый плагин, можно пропустить пароль Custom SMTP, неподтвержденный адрес, отдельное поле имени отправителя или настройку, которую мастер не переносит.

Что импортировать, а что проверять руками

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

После импорта откройте карточку интеграции в Gravity SMTP и проверьте ее как новую настройку. Не доверяйте зеленому статусу без теста. Убедитесь, что адрес Default From Email относится к вашему домену, Default From Name не обрезан и понятен получателю, Force From Email включен только при реальной необходимости, а старый SMTP-плагин еще не отключен до момента проверки. Затем отправьте тестовое письмо, создайте реальное письмо формы или сброса пароля и посмотрите обе записи в Email Log.

Когда отключать старый плагин

Отключайте прежний SMTP-плагин только после того, как Gravity SMTP показал успешную отправку в журнале и получатель увидел письмо. Если старый плагин остается активным, он может продолжать менять wp_mail(), заголовки или отправителя. В результате вы будете смотреть журнал Gravity SMTP, но не понимать, кто именно обработал письмо первым. Для чистой диагностики на сайте должен работать один маршрутизатор исходящей почты.

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

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

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

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

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

Мини-чек после первой реальной активности

• Откройте Dashboard и посмотрите, есть ли неожиданный рост failed-событий.
• В Email Log отфильтруйте письма по статусу ошибки и проверьте, связаны ли они с одним источником.
• Проверьте несколько писем с разными источниками: форма, сброс пароля, стандартное уведомление WordPress, письмо магазина, если он есть.
• Сравните адрес отправителя и имя отправителя в реальном письме с тем, что ожидает владелец сайта.
• Проверьте, что Debug Logging не остался включенным после диагностики.
• Убедитесь, что срок хранения журнала подходит реальному объему писем.

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

Как отличить проблему доставки от проблемы создания письма

Если запись появилась в журнале и имеет успешный статус, Gravity SMTP выполнил свою часть маршрута. Дальше нужно смотреть почтовый сервис, домен отправителя, DNS-записи и почтовый ящик получателя. Если записи нет, ищите причину в источнике события: форма, плагин регистрации, магазин, отключенный тип уведомления, конфликт или отправка вне wp_mail(). Если запись есть, но статус failed, разбирайте интеграцию, ключ, порт, шифрование, адреса и отладочный журнал.

Такая развилка экономит много времени. Вместо общей фразы "не работает SMTP" вы получаете конкретный вопрос: письмо не создано, не попало в Gravity SMTP, не прошло интеграцию или не дошло после успешной отправки. Под каждый вопрос есть свой инструмент: настройки источника, Email Log, Debug Log, системный отчет, панель провайдера и проверка входящего ящика.

Почему письма не отправляются и как диагностировать проблему

Диагностику лучше строить от простого к сложному. Не начинайте с переустановки плагина и смены провайдера. Сначала выясните, создается ли письмо в WordPress, перехватывает ли его Gravity SMTP, какая интеграция использовалась, что записано в журнале и что отвечает почтовый сервис.

Письмо не появляется в Email Log

Симптом: пользователь выполняет действие на сайте, но в Email Log нет новой записи. Тестовое письмо может при этом отправляться нормально.

Возможные причины: событие не создает письмо, уведомление формы отключено, тип письма отключен во вкладке Emails, другой плагин отправляет не через wp_mail(), старый SMTP-плагин или кастомный код перехватывает отправку раньше.

Что проверить: настройки источника письма, включение уведомления, реальное завершение действия, включен ли Email Logging, нет ли второго SMTP-плагина. Для плагинов, которые отправляют письма своим транспортом, Gravity SMTP может не видеть сообщение.

Как исправить: включить уведомление в источнике, вернуть нужный тип письма во вкладке Emails, отключить конфликтующий SMTP-плагин, проверить отправку через стандартный сценарий WordPress. Если письмо создается внешним сервисом отдельно от WordPress, настройка должна выполняться в этом сервисе.

В журнале статус Failed

Симптом: запись есть, но отправка завершилась ошибкой. Получатель письмо не видит.

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

Что проверить: детали записи, сервис отправки, отладочный журнал, карточку интеграции, настройки Default From Email, Force From Email, порт и шифрование для Custom SMTP. Для повторяющейся ошибки включите Debug Logging, отправьте тест и посмотрите техническую запись.

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

Тестовое письмо ушло, а письмо формы нет

Симптом: Send Test показывает успех, но уведомление формы или магазина не приходит.

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

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

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

Письмо отправлено, но попадает в спам

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

Возможные причины: домен отправителя не подтвержден, DNS-записи настроены неполно, адрес From не соответствует домену, содержание письма выглядит подозрительно, у провайдера плохая репутация отправителя, получательский сервер применил свои правила.

Что проверить: настройки домена у почтового сервиса, адрес отправителя, содержимое письма, заголовки, папку спама, журналы провайдера. Gravity SMTP помогает увидеть отправку, но окончательная доставляемость зависит от внешней почтовой инфраструктуры.

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

Журнал растет слишком быстро

Симптом: интерфейс журнала открывается медленнее, база данных растет, резервные копии стали тяжелее.

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

Что проверить: вкладку Logging, срок хранения, Save Email Body, Save Attachments, активность источников на панели отчетов.

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

Когда Gravity Forms SMTP будет удачным выбором

Gravity Forms SMTP стоит использовать, если вам нужен управляемый SMTP-слой внутри WordPress, вы имеете доступ к Gravity SMTP по лицензии и хотите проверять отправку через журнал, отчеты, тестовые письма и отладочные инструменты. Особенно сильный сценарий - сайт с Gravity Forms, регистрациями, системными уведомлениями, письмами администратора и регулярной потребностью отвечать на вопрос "что случилось с письмом?".

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

Если после настройки вам нужно продолжить работу с продуктом на своем сайте, ближе всего к практическому следующему шагу будет получить файл Gravity Forms SMTP, установить его на тестовую копию и пройти проверку по шагам из этого руководства. Не переносите настройку на рабочий сайт, пока не понимаете, какой сервис основной, какой адрес отправителя используется и что показывает журнал при ошибке.