На Hostland сайт отправляет заявки через PHP mail, и вы решили подключить SMTP. Это разумный вариант для управляемой отправки, но результат нужно проверить на реальном уведомлении. Сам факт установки плагина не показывает, что все сообщения сайта перешли на новый маршрут и стали попадать во Входящие.
Задача проверки — сохранить исходное состояние, выполнить контролируемое переключение и сопоставить новые копии. Если одновременно заменить шаблон, адрес отправителя и транспорт, будет сложно понять, с чем связано изменение папки. Начните с одной формы или одного типа уведомления.
Установите исходный способ отправки
В руководстве Hostland по проблемам доставки предлагается сначала выяснить, использует сайт PHP mail или SMTP. Это полезный первый вопрос разработчику. Ответ должен относиться к конкретному обработчику: общий модуль CMS не обязательно обслуживает каждое расширение.
Проверьте конфигурацию и журнал, затем исходные заголовки полученной копии. Не делайте вывод по одному домену From. Локальный скрипт и SMTP-ящик способны использовать одинаковый видимый адрес, но разные технические адреса возвратов, подписи и серверы.
Сохраните исходную контрольную копию
Создайте безопасную заявку без персональных данных и отправьте её через действующую форму. Запишите время, Message-ID и версию шаблона. Если копия обнаружена в Спаме, сохраните именно этот результат. Если есть отказ или отсутствуют данные, обозначьте другое состояние, не подменяя его папкой.
Короткое письмо из отдельного тестового файла не заменяет уведомление формы. Оно может не содержать HTML, ссылок, вложения и рабочего отправителя. Для сравнения требуется тот же путь формирования сообщения, иначе опыт покажет только способность сервера отправить какой-то текст.
Подключите SMTP для выбранной услуги
Возьмите параметры у фактического почтового сервиса и настройте защищённое подключение. Если используется почта Hostland, применяйте инструкцию соответствующей услуги. Если почта внешняя, реквизиты, правила From и ключи нужно брать у внешнего провайдера. Размещение сайта не определяет автоматически исходящий сервис.
Убедитесь, что разрешённый From соответствует выбранной схеме, а адрес посетителя находится в Reply-To. Секреты подключения храните в предусмотренном конфигурацией месте, не в тексте формы и не в публичном репозитории. Для диагностических снимков пароль не нужен.
Проверьте, что переключился рабочий обработчик
Успешная кнопка «Тест SMTP» подтверждает только свой сценарий. Создайте новую заявку через форму и сравните заголовки. Если ожидаемого изменения маршрута нет, найдите модуль, который обходит общую настройку. Иногда автоответ клиенту и письмо менеджеру формируются разными компонентами.
Отдельно проверьте фоновые задания. После изменения конфигурации worker может продолжать работать со старым набором параметров. Это гипотеза для проверки по процессу и журналу, а не универсальный диагноз. Перезапуск и обновление выполняйте в рамках принятой процедуры проекта, сохраняя возможность отката.
Не обещайте аутентификацию по названию протокола
SMTP-авторизация и аутентификация домена — связанные, но разные проверки. В новой копии посмотрите SPF, DKIM и DMARC с конкретными доменами. Успешное подключение не доказывает наличие нужной подписи, а опубликованный DNS-ключ не подтверждает, что сообщение подписано им.
Локальная отправка также не обязана всегда быть неподписанной: это зависит от конфигурации сервера. Поэтому переход на SMTP оценивайте по фактам вашего маршрута, без универсального утверждения «PHP всегда спам». Исправление должно проявиться в полученной копии, а не только в настройках приложения.
Сравните размещение до и после
Используйте Check для проверки папки на доступных контрольных адресах. Содержимое и тестовые данные оставьте сопоставимыми. Запишите изменённый транспорт и технические различия. Переход может менять несколько свойств одновременно, поэтому не приписывайте результат исключительно одному IP или одному DKIM.
Если получатели показывают разные папки, рассматривайте их отдельно. Различие результатов не следует скрывать средним показателем. Отсутствующий в тесте провайдер не проверен, а недоступное чтение не доказывает Спам.
Методология Check описывает ограничения наблюдений и источники технических данных. Завершайте переход списком проверенных событий сайта: форма, автоответ, заказ, фоновое уведомление. Для каждого сохраняйте подтверждённый маршрут и контрольный результат, не обещая всей аудитории одинаковые Входящие.
Если новая схема ухудшила передачу или нарушила ответы клиентам, сохранённая конфигурация позволит вернуть прежний рабочий вариант и отдельно разобрать ошибку. Обратимость изменения полезнее серии несвязанных настроек, после которых команда уже не знает, какой транспорт использует сайт.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Переход на SMTP нужно подтвердить рабочим уведомлением.
- PHP mail и SMTP могут менять несколько свойств маршрута.
- Сравнивайте одинаковый шаблон и отдельно каждую папку.