Письма с сайта попадают в спам: как проверить SPF, DKIM и DMARC без поломки почты

Коротко: что сделать сразу

1. Отправьте тестовую заявку на внешний почтовый ящик и откройте технические заголовки полученного письма.
2. Посмотрите результаты SPF, DKIM и DMARC: PASS, FAIL, SOFTFAIL, NONE или другие статусы.
3. Определите, через какой сервер сайт реально отправляет почту: PHP mail(), SMTP хостинга или внешний сервис.
4. Перед правкой DNS сохраните все текущие записи домена.
5. Не создавайте второй SPF вида v=spf1, если такой TXT уже существует: существующую политику нужно корректно объединять.

Сначала поймите, проблема в доставке или в самой форме

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

Проверьте также адрес отправителя. Типичный проблемный вариант — сайт с домена example.ru пытается отправить письмо с заголовком From: случайный адрес посетителя, например [user@gmail.com](mailto:user@gmail.com). Ваш сервер не имеет права подписывать и авторизовать gmail.com от имени Google. Правильнее использовать адрес собственного домена в From, например [site@example.ru](mailto:site@example.ru), а адрес клиента передавать в Reply-To.

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

Шаг 1. Посмотрите технические заголовки письма

В Gmail откройте письмо, меню с дополнительными действиями и пункт вроде «Показать оригинал». В других сервисах он может называться «Исходный текст», «Служебные заголовки», «Message source» или «View headers». Нас интересуют строки Authentication-Results, Received, Return-Path, DKIM-Signature и адрес From.

В Authentication-Results обычно видно, прошли ли проверки SPF, DKIM и DMARC. Если SPF=pass, DKIM=pass и DMARC=pass, причина спама может быть уже не в базовой аутентификации, а в репутации IP или домена, жалобах пользователей, содержимом письма, объёме отправки или поведении сайта.

Если стоит SPF=none или DKIM=none, не добавляйте записи наугад. Сначала выясните фактический сервер отправки: именно его нужно разрешить или настроить.

Шаг 2. Определите, кто реально отправляет письма сайта

На shared-хостинге названия разделов отличаются. В cPanel ищите Email, Email Accounts, Email Deliverability или настройки SMTP; в ISPmanager — Почта, Почтовые домены и Ящики; в собственной панели хостера пункты могут называться иначе. Если сайт использует CMS, проверьте её настройки почты или SMTP-плагина.

Возможны четыре типичных схемы. Первая — PHP mail() отправляет через локальный сервер хостинга. Вторая — сайт авторизуется по SMTP в ящике вашего домена. Третья — используется внешний почтовый или транзакционный сервис. Четвёртая — приложение отправляет через собственный сервер компании. Для каждой схемы DNS-настройки отличаются.

Если не знаете, какой вариант используется, не правьте config.php вслепую. Перед изменением config.php сделайте копию. Если доступ к SMTP хранится в конфигурации, не публикуйте этот файл и не пересылайте пароль в открытом виде.

Шаг 3. Проверьте SPF и не создавайте две независимые политики

SPF публикуется в DNS как TXT-запись и определяет, какие серверы имеют право отправлять почту для домена. Ключевая ловушка — у домена должна быть одна итоговая SPF-политика, начинающаяся с v=spf1. Если уже есть запись для корпоративной почты, а вы добавили вторую отдельную для сайта, проверка может завершаться ошибкой PermError.

Поэтому новый источник отправки не создаёт «ещё один SPF», а корректно добавляется в существующую политику по инструкции вашего почтового или транзакционного сервиса. Не копируйте include другого провайдера только потому, что нашли пример в интернете.

Следите и за количеством DNS-проверок внутри SPF. Сложные цепочки include и redirect могут превысить допустимый лимит. Если политика уже большая, лучше попросить почтового провайдера или администратора проверить её структуру.

После изменения DNS результат виден не всем мгновенно. Из-за TTL и кэшей обновление может распространяться от нескольких минут до 24–48 часов. В этот период разные проверяющие серверы могут видеть старую и новую запись.

Шаг 4. Настройте DKIM через тот сервис, который отправляет почту

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

Откройте настройки почтового сервиса или панели хостинга и найдите DKIM, Email Authentication, Domain Authentication или похожий раздел. Сервис обычно показывает точное имя TXT или CNAME и значение, которое нужно добавить.

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

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

Шаг 5. Добавьте DMARC осторожно и сначала наблюдайте

DMARC связывает проверки SPF/DKIM с доменом в поле From и задаёт политику обработки писем, которые не проходят проверку. Запись публикуется для имени _dmarc вашего домена.

Если вы впервые внедряете DMARC на домене, где письма отправляют сайт, сотрудники, CRM и рассылочный сервис, не начинайте с жёсткой политики отклонения без инвентаризации всех источников. Сначала добейтесь, чтобы законные потоки корректно проходили SPF или DKIM и соответствовали домену From.

Google в актуальных требованиях к отправителям Gmail указывает, что всем отправителям нужна как минимум SPF или DKIM-аутентификация, а для отправителей более 5000 сообщений в сутки на Gmail требуются SPF, DKIM и DMARC. Даже небольшой сайт выигрывает от корректной аутентификации. Официальная инструкция Google: support.google.com.

Почему PASS ещё недостаточно: проверьте согласование доменов

Для DMARC важно не просто наличие успешного SPF или DKIM, а согласование с доменом, который пользователь видит в From. Например, сайт показывает From: [shop@example.ru](mailto:shop@example.ru), но фактический Return-Path относится к совершенно другому техническому домену. Это может быть нормально, если DKIM подписан согласованным доменом, но схему нужно понимать.

Поэтому не оценивайте письмо только по одной строке SPF=pass. Смотрите полный результат DMARC. Хороший SMTP-сервис обычно предоставляет инструкцию по верификации домена и показывает статус каждого шага.

Если вы используете форму обратной связи, адрес посетителя лучше помещать в Reply-To. Тогда менеджер может нажать «Ответить», но сервер не будет притворяться отправителем чужого домена.

Если SPF, DKIM и DMARC проходят, почему письмо всё равно в спаме

Аутентификация доказывает, что письмо действительно связано с разрешённым отправителем, но не гарантирует папку «Входящие». Почтовые системы учитывают репутацию IP и домена, историю жалоб, объём и резкие скачки отправки, качество списка адресатов и содержание сообщений.

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

Не пытайтесь «обмануть спам-фильтр» заменой слов и картинок. Сначала устраните техническую причину.

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

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

Не позволяйте посетителю произвольно задавать полный From и заголовки письма. Адрес получателя также не должен приниматься из открытого параметра без проверки — иначе форма может превратиться в почтовый релей.

Если меняете код формы, сначала сохраните рабочие файлы и config.php. Перед изменением базы данных сделайте SQL-копию. Не отключайте SSL и не ставьте права 777 ради того, чтобы «SMTP заработал»: ни то ни другое не является правильным решением проблемы доставки.

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

Перед любым изменением сделайте снимок или экспорт всей DNS-зоны. Особенно важны MX, существующий SPF, DKIM-селекторы, DMARC, A, AAAA и записи подтверждения сервисов. Если домен использует сайт и почту у разных провайдеров, удаление «ненужной» записи может повлиять на другой сервис.

В cPanel, ISPmanager и панелях регистраторов редактор DNS называется по-разному: Zone Editor, DNS-записи, Управление зоной, Ресурсные записи. Ищите раздел по смыслу и обязательно проверяйте, редактируете ли вы авторитетную DNS-зону. Если NS домена направлены на другой сервис, изменения в панели хостинга могут вообще не использоваться.

После изменений ждите распространения DNS и повторяйте тесты позже. В норме изменения могут быть видны неодинаково до 24–48 часов. Не добавляйте вторую копию записи каждые десять минут только потому, что один внешний сервис ещё видит старое значение.

Как понять, что проблема решена

• Новые тестовые письма показывают ожидаемые SPF=pass и DKIM=pass либо корректную схему, рекомендованную вашим сервисом.
• DMARC проходит и согласован с доменом в From.
• Письма с формы стабильно доставляются в несколько разных почтовых систем.
• Reply-To содержит адрес посетителя, а From принадлежит вашему домену или разрешённому сервису.
• В DNS осталась одна корректная SPF-политика.
• Корпоративная почта продолжает принимать и отправлять сообщения после изменений.

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

Когда лучше остановиться и не экспериментировать

Остановитесь перед редактированием DNS, если не знаете, где находятся авторитетные NS или какие сервисы используют существующие записи. Сначала сохраните зону и составьте список отправителей.

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

Если сайт хранит пароль SMTP в config.php и вы не уверены в правах доступа, не публикуйте файл и не отправляйте его целиком постороннему. Не используйте права 777 и не отключайте SSL. Настройку SMTP, SPF, DKIM, DMARC и диагностику заголовков можно поручить специалисту, если сайт приносит заявки и потеря писем критична.

Вывод

Когда письма сайта оказываются в спаме, начинайте с заголовков, а не с догадок. Определите реальный сервер отправки, затем проверьте SPF, DKIM и DMARC и только после этого меняйте DNS. Не создавайте второй SPF, не выдавайте чужой адрес за From и не ломайте рабочую почтовую зону ради одной формы. Если базовая аутентификация уже проходит, переходите к репутации IP, качеству отправки и защите самой формы от злоупотреблений.