Сайт размещён на Beget, обработчик вызывает PHP mail(), а письмо о заявке попадает в Спам. В панели домена при этом могут быть видны почтовый ящик и DNS-записи. Эти настройки полезны, но они не доказывают, что конкретный PHP-процесс отправляет через ожидаемый почтовый маршрут и подписывает сообщение.
Начните с рабочего обработчика формы. Нужно узнать, какие заголовки он формирует, какой технический отправитель используется и что означает записанный им статус успеха. Не добавляйте DNS-записи до того, как установите, какой домен и какой сервер действительно участвуют в проверяемом письме.
Для формы с вложением дополнительно проверьте, что файл действительно добавлен к сообщению и не превысил ограничения используемого пути. Ошибка формирования MIME может возникнуть до получения письма, а корректная копия без вложения уже будет другим тестом. Зафиксируйте размер и тип безопасного тестового файла, чтобы разработчик мог повторить сценарий без клиентских документов.
Что можно узнать из результата функции
В официальной документации PHP true означает принятие письма для передачи. Это не подтверждение папки и не обещание доставки. Если функция вернула false или приложение завершилось с ошибкой, сначала исследуйте этот этап. Найденная копия в Спаме — другая, более поздняя стадия.
Сохраните время выполнения и безопасный идентификатор запроса. По возможности свяжите его с Message-ID. Отдельный тестовый файл с короткой строкой проверит доступность функции, но не воспроизведёт вложения, кодировку, адреса и логику настоящей заявки. Для диагностики нужен тот же обработчик.
Сравните From и адрес возвратов
Видимый From должен принадлежать контролируемому отправителю. Если в него подставляется почта посетителя, сервер сайта начинает представляться чужим доменом. Обычно адрес клиента нужен в Reply-To, чтобы менеджер мог ответить, а технический отправитель остаётся у вашей организации.
Адрес конверта и From могут отличаться. Проверяйте оба в полученной копии и настройках транспорта. Не подставляйте пользовательский ввод в дополнительные параметры почтовой команды. Поля формы должны проходить проверку, а разрешённые получатели и отправитель задаваться серверной логикой.
Установите наличие подписи
Найдите DKIM-Signature в исходных заголовках. Если подписи нет, не ищите сначала случайный ключ в DNS: его публикация не заставляет приложение подписывать письмо. Нужно выяснить возможности фактического маршрута и настроить подписывание либо поддерживаемую отправку через подходящий SMTP.
Если подпись есть, используйте d= и s= для поиска открытого ключа. Сравните публичную запись в действующей зоне с настройками отправителя. Закрытый ключ не загружается в DNS и не передаётся в тест. Сохраняйте различие между отсутствием подписи, ошибкой проверки и отсутствием данных для анализа.
Не опирайтесь на неподтверждённые параметры хостинга
Если нужная инструкция на официальном сайте Beget недоступна или перенаправляет на другую страницу, текущие условия локальной отправки сверяйте с панелью и поддержкой своей услуги. Старый поисковый фрагмент не подтверждает конфигурацию аккаунта. Получите сведения именно о том транспорте, который планируете использовать для рабочего обработчика, и сохраните источник параметров в документации проекта.
Это ограничение не мешает исследовать полученное письмо. Заголовки и журнал приложения позволяют установить используемый маршрут независимо от названия пункта меню. Не объявляйте технический сбой причиной Спама без связи с конкретной отправкой и её временем.
Сравните варианты честно
Если вы переходите с локальной функции на SMTP, сохраните шаблон и безопасные тестовые данные. Меняется маршрут, а вместе с ним могут измениться IP, подпись и адрес возвратов. Поэтому результат следует описывать как сравнение способов отправки, а не как доказанное влияние одного DKIM.
Для исходного и нового варианта используйте проверку размещения Check. Отправляйте из приложения на доступные контрольные адреса. Не пересылайте старое письмо вручную из веб-почты: пересылка создаёт другой сценарий и не проверяет обновлённый код формы.
Прочитайте папку отдельно от технического успеха
Сохраните аутентификацию и фактическое размещение каждой обнаруженной копии. Если DKIM стал проходить, но Спам остался, исправлена конкретная техническая часть, а причина папки остаётся неустановленной. Такой результат требует дальнейшей отдельной проверки, а не возврата к ошибочной конфигурации.
По методологии Check наблюдение относится к определённому ящику и времени. Недоступный контрольный результат не равен отказу, а успех одного провайдера не предсказывает всю аудиторию. Передайте разработчику подтверждённые различия и точный способ воспроизведения.
После исправления сохраните тестовый сценарий рядом с обработчиком. При обновлении PHP или переносе сайта он позволит проверить ту же форму, включая правильность ответа клиенту, без отправки реальных заявок и без повторного угадывания почтового маршрута.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Успех PHP mail() не подтверждает получение письма.
- Созданный ящик не доказывает подписывание локального скрипта.
- Проверяйте рабочий обработчик и реальную копию.