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

Если Gmail принял письмо, но положил его в спам, проверьте заголовки, аутентификацию, DNS и репутацию отправителя. Один статус SPF или DKIM сам по себе не объясняет решение фильтра. Я покажу, как собрать признаки и выбрать следующий шаг, а требования Google разделю по объёму отправки.

Сначала отделите отказ от папки «Спам»

Если письмо не принято Gmail, ищите ответ SMTP и журнал исходящего сервера. Если оно принято, но оказалось в «Спаме», изучайте копию у получателя и её заголовки. Это разные ветки диагностики: запись DNS не объяснит временный отказ сервера, а SMTP-успех не означает, что письмо попадёт во «Входящие». Я сначала фиксирую адрес отправителя, время, получателя и текст ответа, а потом меняю настройки. Для компаний, которым нужна помощь с корпоративной почтой, мы начинаем с такой проверки, а не с переписывания темы письма.

У Google требования разделены по объёму. Для отправки на личные адреса Gmail нужен как минимум SPF или DKIM, корректные прямые и обратные DNS-записи и низкий уровень пользовательских жалоб. При отправке свыше 5 000 писем в сутки на Gmail нужны SPF, DKIM и DMARC; политика DMARC может быть p=none. Google рекомендует держать показатель жалоб в Postmaster Tools ниже 0,1 % и не допускать достижения 0,3 %. 0,1 % — рекомендуемый ориентир, а 0,3 % — уровень, которого нельзя достигать. Ни одна из этих цифр не обещает попадания во «Входящие». Эти правила действуют с 1 февраля 2024 года; перед массовой рассылкой я сверяю актуальную страницу Google, потому что требования и интерфейсы меняются.

Снимите заголовки доставленного письма

Попросите адресата открыть именно письмо из «Спама» в веб-версии Gmail, нажать меню рядом с ответом и выбрать «Показать оригинал». Google документирует этот способ для просмотра полного заголовка; путь в мобильном приложении может отличаться, поэтому я не предлагаю искать там несуществующую универсальную кнопку. Сохраните полный оригинал: важны не только строки Authentication-Results, но и Received, дата и фактический адрес отправителя. На основании одного обрезанного скриншота легко обвинить DNS, хотя письмо могло пройти через пересылку или сторонний сервис.

В сводке проверки ищите результаты SPF, DKIM и DMARC, но читайте их вместе. Например, spf=fail не доказывает автоматически, что именно он отправил сообщение в спам: DMARC может пройти по корректной DKIM-подписи. none тоже не равно «причина найдена» — надо понять, к какой проверке относится результат и как соотносятся домены. Если в заголовке несколько одноимённых результатов, не считайте их все равнозначными: сверяйте идентификатор authserv-id и опирайтесь на проверку Gmail, а не на текст, который мог добавить отправитель.

В условной лаборатории «Норма качества» с 23 рабочими местами я бы начал именно с письма получателя и списка всех приложений, которые отправляют почту от имени домена.

Я сохраняю этот оригинал до правок: после обновления DNS нужно сравнить письмо до и после, иначе легко спутать новую ошибку со старой копией в ящике. Для массовой отправки отдельно смотрю число сообщений именно на Gmail и жалобы в Postmaster Tools; единичная переписка не даёт данных для вывода о репутации. Если Google показывает мало статистики, это не обязательно означает нулевые жалобы: панель не всегда отображает данные при малом объёме.

В заголовках полезно сопоставить видимый From, Return-Path и домен d= в DKIM-Signature: это разные идентификаторы, и они не обязаны выглядеть одинаково. Authentication-Results помогает увидеть результат, а Received — понять, через какие узлы прошло сообщение. Я фиксирую их до изменений и не публикую чужие заголовки целиком: в них бывают адреса и служебные сведения о маршруте.

Для разбора кейса я бы попросил два письма: одно из «Спама» и одно, которое дошло нормально, если отправитель посылал оба. Разница в Return-Path, подписи или промежуточном сервисе часто показывает, какой именно поток надо проверять. Если письма пересылались, SPF на последнем узле может не пройти из-за смены IP; DKIM при этом иногда сохраняется. Это ещё одна причина не превращать результат одной проверки в приговор всему домену.

Проверьте SPF, DKIM и выравнивание DMARC

SPF перечисляет, какие узлы вправе использовать домен в SMTP-идентификаторах отправителя; это не просто список IP в одной строке. Для одного имени публикуют одну SPF-запись TXT. Несколько записей v=spf1 для того же имени недопустимы и могут дать permerror; их нельзя «починить» добавлением третьей. Сведите разрешённые механизмы в одну запись, проверьте лимиты DNS-запросов и включите каждый реальный источник отправки: почтовый сервер, CRM, сайт и сервис рассылки. Отдельно проверяйте домены поддоменов: запись на корне не всегда описывает отправку от другого имени.

Например, домен в видимом From может быть example.com, а подписывающий домен d= — mailer.example.com. При стандартном relaxed alignment это может считаться выравниванием; при strict alignment требуются более точные имена. Сначала посмотрите параметры aspf и adkim в DMARC-записи, а не заменяйте поддомен на корневой наугад. Именно это различие часто теряется в советах «домен должен совпадать».

DKIM позволяет получателю проверить криптографическую подпись выбранных частей письма по открытому ключу из DNS. Это не магическая гарантия неизменности всего сообщения: подпись проверяется по тем данным, которые в неё включены, и может сломаться после изменения подписанных частей. DMARC связывает проверенный SPF или DKIM с доменом в видимом поле From. По обычному, relaxed-режиму домены могут быть организационно выровнены, то есть буквальное совпадение адресов или имён не обязательно. Для DMARC достаточно, чтобы прошла хотя бы одна проверка — SPF либо DKIM — и её домен был выровнен с From.

p=none просит получателя не применять к провалившим DMARC письмам политику карантина или отказа; это режим наблюдения, а не исправление доставляемости. Сначала соберите список отправителей, настройте отчёты и убедитесь, что легитимные сервисы проходят выравнивание. Только после этого обсуждайте p=quarantine или p=reject. В этом месте я не тороплюсь: ошибочная строгая политика способна затронуть собственные письма компании. Более подробную проверку записей мы разбираем в материале о доставке через SPF, DKIM и DMARC.

Проверьте PTR и репутацию отправителя

Для исходящего почтового сервера Google требует корректные прямую и обратную DNS-записи. PTR публичного IP должен возвращать имя узла, а A или AAAA этого имени — тот же IP, с которого уходит SMTP-соединение. Управляет PTR обычно владелец адресного диапазона или хостинг-провайдер, поэтому одной правки в зоне вашего домена может быть недостаточно. Сверьте фактический исходящий IP в журнале, PTR и обратное разрешение имени; затем проверьте результат средствами провайдера и Google Admin Toolbox. Обобщение «PTR должен совпадать с прямой записью» верно лишь как краткая формулировка этой двусторонней проверки.

Если исходящая почта идёт через общий IP, его репутация зависит и от других отправителей. Для собственной инфраструктуры это аргумент проверить IP до переноса почты; для общей платформы — выяснить, какой именно исходящий адрес использует провайдер. Но общий адрес сам по себе не означает, что сосед отправляет спам или что Gmail уже применил санкцию: нужны наблюдаемые данные.

Для Gmail полезнее начать с Postmaster Tools: там доступны сведения о репутации домена и IP, пользовательских жалобах, аутентификации и ошибках доставки. У панели есть ограничения: она показывает жалобы пользователей, а автоматическое помещение писем в спам не обязано повышать этот показатель. Поэтому низкая цифра сама по себе не оправдывает массовую рассылку. Публичный чёрный список — отдельный сигнал, а не доказательство, что именно он вызвал фильтрацию Gmail; сначала сопоставьте запись в списке с логами и данными Google. Если нужен отдельный разбор списка, есть материал о чёрных списках и доставляемости.

В Postmaster Tools привяжите и подтвердите свой домен, а затем сравнивайте динамику по дням и данные о домене или IP, если объёма достаточно. Этот инструмент не показывает содержимое писем и не заменяет журнал SMTP. Он помогает увидеть тенденцию, а не назвать единственную причину конкретного сообщения. Подробно проверить репутацию IP можно в отдельном разборе диагностики спама.

Учитывайте жалобы и тип письма

Аутентификация отвечает на вопрос, кто отправил письмо и можно ли связать проверенные домены с From; она не доказывает, что адресат ждал это сообщение. Для рассылок отправляйте письма тем, кто согласился их получать, прекращайте отправку на недействительные адреса и делайте отказ от подписки понятным. Для маркетинговых и подписных писем Google требует рабочую отписку в один клик при массовой отправке. Деловое письмо одному контрагенту и маркетинговая кампания — разные сценарии, их не стоит смешивать в одном списке получателей. В Postmaster Tools смотрите динамику после изменения конкретного источника или типа рассылки.

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

Если всё прошло по SPF, DKIM, DMARC и PTR, не объявляйте фильтр сломанным. Google учитывает и поведение отправителя, и жалобы, и другие признаки; корректная аутентификация не гарантирует нужную папку. Проверьте, соответствует ли тема содержанию, не маскируется ли отправитель под другой домен, куда ведут ссылки и кто действительно получает письма. Меняйте один фактор за раз и сравнивайте несколько одинаковых контрольных отправок. Резкая смена темы, IP и DNS одновременно даёт шум вместо ответа. Для похожей диагностики другого почтового сервиса можно посмотреть разбор спама в Яндексе.

Исправляйте причину по одному шагу

Я веду проверку в таком порядке: сохраняю полный оригинал письма и SMTP-ответ; выписываю домены и IP из заголовков; сверяю SPF и DKIM у каждого отправителя; проверяю DMARC и выравнивание с From; подтверждаю PTR и прямое разрешение IP; затем смотрю репутацию и жалобы в Postmaster Tools. Если один сервис отправляет без подписи или через неучтённый домен, сначала исправляю именно этот источник. После обновления DNS учитываю его TTL и повторно снимаю заголовок нового письма. Не нужно менять все записи сразу: иначе вы не узнаете, что помогло, а что сломали.

До изменения DNS сохраните текущие значения зоны и зафиксируйте, кто управляет каждой записью: домен, отправляющая платформа, почтовый хост или провайдер IP. Если одновременно отправляют сервер, сайт, CRM и сканер, проверяйте каждый источник отдельным тестом; одна успешная отправка с сервера не подтверждает настройки сайта. После публикации записи дождитесь обновления DNS у используемых резолверов и снова снимите заголовки с нового тестового письма. Не отправляйте контрольное письмо клиентской базе.

Для условной лаборатории с 23 рабочими местами итог плана будет не «поднять репутацию за две недели», а список проверенных источников и воспроизводимый результат: какие проверки прошли, где нет выравнивания, какой узел владеет PTR и какие отправки показывают проблему. Если причина в пользовательских жалобах или общей репутации, восстановление может занять неопределённое время; ни администратор, ни подрядчик не управляют классификацией Gmail напрямую. В похожих случаях сначала устраняют подтверждённое нарушение, прекращают нежелательные отправки и наблюдают за изменениями, не обещая конкретную дату возврата во «Входящие». Чёрный список тоже проверяют по факту, а не снимают вслепую.

В журнале диагностики оставьте дату, тип письма, ответ SMTP, результат каждого механизма и внесённое изменение. Так можно связать улучшение или ухудшение с конкретным действием и вернуть запись, если она нарушила рабочую отправку. Контрольную отправку просите у адресата, который ждёт письмо; «тест на свой ящик» не моделирует поведение всех получателей и не создаёт гарантию доставки.

Частые вопросы