Почему Gmail не принимает письма с вашего сервера

MAATRIX

Вы подняли собственный почтовый сервер, всё вроде настроено, а письма на gmail.com либо отбиваются с ошибкой, либо тихо оседают в папке «Спам» у получателя. Это одна из самых частых проблем при самостоятельном хостинге почты — и у неё почти всегда есть конкретная, диагностируемая причина. Gmail держит настолько большую долю почтовых ящиков в мире, что его требования к чужим серверам стоит воспринимать не как рекомендацию, а как жёсткий техрегламент. Разберём, что именно чаще всего идёт не так и как это проверить по шагам, а не гадать наугад.

Почему именно Gmail — отдельная головная боль

С почтовым сервером, который отправляет письма условному «Иванову на mail.ru», часто всё проходит гладко даже при не идеальной настройке. С Gmail так не работает — и дело не в капризности Google, а в масштабе: через Gmail проходит огромная часть всей мировой почты, и любой спамер тоже пытается писать через свежий VPS. Поэтому фильтры Gmail агрессивнее, требования к аутентификации строже, а порог доверия к новому неизвестному IP — на старте почти нулевой.

Практическое следствие: то, что письмо доходит до Yandex или Mail.ru, ничего не говорит о том, дойдёт ли оно до Gmail. Тестировать и диагностировать нужно отдельно, именно на gmail-адресах, и делать это на каждом этапе настройки — после смены IP, после первой массовой рассылки, после любого изменения в DNS.

Четыре причины ниже покрывают подавляющее большинство реальных случаев отказа. Они не равнозначны: первая (PTR) чаще всего даёт жёсткий отказ на этапе SMTP-диалога, вторая (SPF/DKIM/DMARC) — либо отказ, либо автоматическое попадание в спam, третья и четвёртая (репутация IP) — плавающее поведение, которое то работает, то нет.

Причина 1: отсутствующая или неправильная PTR-запись

PTR-запись — это обратное DNS-разрешение: сопоставление вашего IP-адреса доменному имени (в отличие от обычной A-записи, которая делает домен → IP). Для входящей проверки Gmail и другие крупные провайдеры при получении письма делают reverse DNS lookup по IP отправителя и ожидают увидеть осмысленное имя, желательно совпадающее по домену с тем, что сервер представляет в SMTP-приветствии (HELO/EHLO).

Проверить свою PTR-запись:

dig -x 185.203.XX.XX +short

Если команда возвращает пусто или отдаёт что-то вроде générique vps-12345.hostingprovider.net, а ваш сервер представляется как mail.vashdomen.ru — это несовпадение, и для Gmail это красный флаг. В худшем случае PTR вообще отсутствует — тогда часть строгих серверов отклонит соединение ещё до приёма письма, с ошибкой уровня 550 прямо в SMTP-сессии.

Что делать:

1. PTR-запись прописывается не в вашей DNS-зоне, а на стороне провайдера, которому принадлежит IP (это его блок адресов, обратная зона в его ведении).
2. В панели VPS-хостинга обычно есть поле «Reverse DNS» / «PTR record» — именно там указывается, во что резолвится IP.
3. Значение PTR должно указывать на то же имя, что сервер называет в HELO, а ещё лучше — совпадать с A-записью этого имени (прямое и обратное разрешение должны быть согласованы в обе стороны).

Если у арендованного VPS нет панели для PTR — это стоит уточнить у провайдера до того, как разворачивать на нём почтовый сервер: без возможности задать PTR доставка на Gmail в лучшем случае будет нестабильной.

Причина 2: SPF, DKIM и DMARC настроены неправильно или отсутствуют

Это самая частая техническая причина отказов и попаданий в спам, и одновременно самая проверяемая. Три механизма решают разные задачи:

• SPF (Sender Policy Framework) — TXT-запись в DNS домена, перечисляющая, каким IP разрешено отправлять почту от имени этого домена.
• DKIM (DomainKeys Identified Mail) — криптографическая подпись письма приватным ключом, публичный ключ лежит в DNS; подтверждает, что письмо не подменено по пути.
• DMARC — политика, которая говорит принимающей стороне, что делать с письмом, если SPF и/или DKIM не прошли (отклонить, в спам, или ничего не делать), плюс отчёты о нарушениях.

Gmail с 2024 года требует минимум SPF или DKIM (лучше оба) и хотя бы базовый DMARC для любого отправителя с заметным объёмом писем — без этого письма систематически будут либо отклоняться, либо помечаться подозрительными.

Быстрая проверка своих записей:

dig txt vashdomen.ru +short
dig txt default._domainkey.vashdomen.ru +short
dig txt _dmarc.vashdomen.ru +short

Типичные ошибки, которые встречаются на практике:

• В SPF указан не тот IP (забыли добавить после переезда на новый сервер) — запись осталась от старого хостинга.
• Два SPF TXT-записи на одном домене — невалидно, RFC разрешает только одну, и почтовые системы её игнорируют или трактуют как softfail.
• DKIM-селектор в заголовках письма не совпадает с тем, что опубликован в DNS (письмо подписывается селектором mail, а в DNS ключ лежит под default).
• DMARC-политика стоит p=none — это значит «присылайте отчёты», реальной защиты это не добавляет; для устойчивой доставки на Gmail нужно постепенно переходить к p=quarantine, затем к p=reject.

Как проверить, что всё реально работает, а не просто прописано в DNS — отправить тестовое письмо на свой Gmail-адрес и открыть его заголовки (см. следующий раздел): там прямым текстом видно spf=pass, dkim=pass, dmarc=pass или fail с указанием, что именно не сошлось. Пошаговая настройка всех трёх механизмов разобрана в статье «Как установить и настроить SPF, DKIM и DMARC на VPS», а частые проблемы именно с этой связкой — в статье «SPF, DKIM и DMARC на сервере: частые ошибки и решения».

Причина 3: отправка большого объёма без прогрева IP

У свежего IP-адреса нет истории — ни хорошей, ни плохой. Крупные провайдеры вроде Gmail оценивают репутацию отправителя не только по DNS-записям, но и по поведению: с какого объёма писем сервер начал, насколько ровный темп отправки, какой процент писем получатели реально открывают и не пишут ли на них жалобу «спам».

Частый сценарий отказа: сервер настроен идеально (PTR, SPF, DKIM, DMARC — всё зелёное), но в первый же день с него уходит несколько тысяч писем разом. Gmail воспринимает это как классическое поведение спам-рассылки и начинает массово отклонять или мягко ограничивать входящий поток («throttling» — часть писем просто не долетает или сильно задерживается).

Практический подход к прогреву нового IP:

• Первую неделю — минимальный объём (десятки писем в день), преимущественно реальным адресатам, которые точно откроют письмо.
• Постепенно наращивать объём (условно удваивая раз в несколько дней), не выходя сразу на плановую нагрузку.
• Следить за bounce rate и жалобами на спам — рост этих метрик сигнал притормозить, а не продолжать по плану.
• Не смешивать транзакционные письма и массовые рассылки с одного IP на этапе прогрева — у них разная переносимость репутационных рисков.

Точных цифр «сколько писем в день можно с нового IP» никто гарантированно не даст — это ориентир, зависящий от истории домена и поведения получателей, у вас цифры могут отличаться. Ориентируйтесь на постепенность, а не на конкретное число.

Причина 4: IP с "грязной" историей от предыдущего владельца

Специфика аренды VPS в том, что IP-адреса переиспользуются: сервер, который вам выдали, до этого мог принадлежать другому клиенту хостинга — в том числе тому, кто рассылал спам, и IP уже мог попасть в чёрные списки (RBL/DNSBL) или получить пониженный репутационный скор у крупных провайдеров ещё до того, как вы его получили.

Это стоит проверять до начала активного использования IP под почту, а не после первых отказов:

# Проверка по основным чёрным спискам вручную
dig X.X.X.X.zen.spamhaus.org +short
dig X.X.X.X.bl.spamcop.net +short

(IP указывается в обратном порядке октетов; непустой ответ — IP в списке.) Удобнее пользоваться агрегаторами вроде MXToolbox или аналогичных сервисов проверки по десяткам списков одним запросом — вручную проверять каждый список долго.

Если IP оказался в списках:

• Часть списков снимает блокировку автоматически через некоторое время простоя без спам-активности — от нескольких дней до пары недель.
• Часть требует ручного delisting-запроса через форму на сайте списка (Spamhaus, SpamCop и т.д.) — бесплатно, но занимает время на рассмотрение.
• Если IP «в списке» именно у Gmail (это не публичный DNSBL, а внутренняя репутационная система Google) — универсального «снятия» нет, репутация восстанавливается только временем и чистым поведением.

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

Как читать реальное сообщение об отказе от Gmail

Когда Gmail отклоняет письмо на этапе SMTP-диалога, ваш почтовый сервер обычно логирует полный ответ — и в нём почти всегда указана конкретная причина, а не общее «отказано». Смотреть стоит в лог MTA (например, /var/log/mail.log для Postfix) сразу после неудачной попытки отправки:

tail -f /var/log/mail.log | grep -i gmail

Типичные формулировки и что они реально значат:

Если письмо не отклонено, а тихо ушло в спам получателю — самой ошибки в логе не будет, потому что SMTP-сессия прошла успешно. В этом случае диагностика другая: попросите получателя (или проверьте на собственном тестовом Gmail-ящике) открыть письмо и посмотреть его заголовки — в Gmail это делается через «Показать оригинал» (Show original) в меню письма. Там в блоке Authentication-Results прямым текстом видно, что именно не прошло:

Authentication-Results: mx.google.com;
       dkim=fail (signature did not verify) header.d=vashdomen.ru;
       spf=pass smtp.mailfrom=vashdomen.ru;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=vashdomen.ru

В этом примере видно: SPF в порядке, а вот DKIM не прошёл проверку (подпись не совпала) — значит, искать проблему нужно именно в настройке DKIM (например, письмо было изменено промежуточным сервером после подписи, или ключ в DNS не совпадает с тем, что реально используется). Это гораздо продуктивнее, чем перенастраивать всё подряд наугад.

Google Postmaster Tools: прямая обратная связь от Gmail

Кроме анализа отдельных отказов, у Gmail есть отдельный бесплатный инструмент именно для владельцев почтовых доменов — Google Postmaster Tools (postmaster.google.com). Это не общая рекомендация «для провайдеров вообще», а конкретный сервис от самого Gmail, который показывает данные по вашему домену напрямую из внутренней статистики Google — то есть не догадки, а факт.

Что он показывает и почему это ценнее любых предположений:

• Domain reputation — репутация вашего домена глазами Gmail (высокая/средняя/низкая/плохая), на уровне домена, а не только IP.
• IP reputation — репутация конкретного отправляющего IP отдельно от домена.
• Spam rate — процент писем с вашего домена, которые получатели отмечают как спам; стабильно высокий spam rate — прямой путь к массовым отказам.
• Authentication — доля писем, прошедших SPF/DKIM/DMARC, в динамике.

Подключение требует подтверждения владения доменом (TXT-запись верификации, аналогично Google Search Console) и объёма отправки — Postmaster Tools показывает данные не по единичным письмам, а начиная с определённого ежедневного трафика на Gmail-адреса; для совсем маленького домена с несколькими письмами в день панель может первое время оставаться пустой, это нормально.

Практический смысл: вместо того чтобы гадать «наверное, у нас плохая репутация», можно открыть панель и увидеть точный статус по шкале Gmail — и реагировать на конкретный красный индикатор, а не на общие подозрения.

Честные ожидания: это не разовая настройка

Важно понимать пределы: правильная настройка PTR, SPF/DKIM/DMARC и чистый IP снимают подавляющее большинство технических отказов, но не дают гарантии на 100% и на всё время вперёд. Критерии Gmail не статичны — компания регулярно ужесточает требования (например, обязательный DMARC для массовых отправителей стал жёстким требованием далеко не сразу), и то, что проходило полгода назад, может начать отклоняться после очередного обновления фильтров, без каких-либо изменений с вашей стороны.

Из этого следуют практические выводы:

• Настройка почтового сервера под Gmail — это не задача «сделал один раз и забыл», а процесс с периодической проверкой: раз в несколько месяцев стоит заново прогонять диагностику (заголовки тестового письма, Postmaster Tools, актуальные официальные требования Gmail для отправителей).
• Официальные требования Google к отправителям публикуются и обновляются на их страницах поддержки — при системных проблемах с доставкой стоит свериться именно с текущей версией этих требований, а не полагаться на статью годичной давности (в том числе эту). Общий разбор перехода с готового провайдера на свой сервер — в статье «Переход с Gmail на свой почтовый сервер».

Если после проверки всех четырёх причин и заголовков письма ситуация не проясняется — иногда узкое место банальное: сам VPS, IP или сеть хостинга изначально плохо приспособлены под исходящую почту (заблокированный порт 25, невозможность задать PTR, IP из «грязного» диапазона провайдера). Тогда разумнее не бороться с инфраструктурой хостинга, а перенести почту на сервер и в локацию, где эти вопросы уже решены на уровне провайдера.

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