Defaults.Exposed › Исправления › Guides
Gmail "550-5.7.1 Message Blocked" — расшифруйте отказ и исправьте его (2026)
Опубликовано 2026-07-08
Показатели по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 млн оценённых доменов. См. как мы ставим оценки.
Gmail возвращает 550-5.7.1, когда блокирует сообщение по причинам политики, а не из-за отсутствующей записи: политика отправляющего или принимающего домена, соединение по IPv6 без обратного DNS или подозрение в спаме. Из 12 145 313 доменов, авторизующих в SPF собственные серверы Google, лишь 18,5% принуждают DMARC, по данным переписи Defaults.Exposed из 261 млн доменов.
550-5.7.1 — старейший «универсальный» отказ Gmail, и способ исправления зависит от фразы, идущей после кода в вашем отказе. Ниже: таблица-расшифровка точных формулировок, затем путь исправления для каждого варианта — блокировки по политике, серверы IPv6 без обратного DNS, блокировки за спам или содержимое, — плюс похожие коды, с которыми его путают, включая семейство 5.7.26, под которым Google теперь выдаёт отказ по политике DMARC, в старых справочниках числившийся под 5.7.1.
Что на самом деле означает 550-5.7.1 от Gmail?
В схеме расширенных статусов SMTP (RFC 3463) любой код 5.7.x означает «постоянный отказ по причинам политики». Gmail использует 550-5.7.1 как своё старое семейство политик: блокировки по политике отправителя или получателя, блокировки за спам-репутацию и — вариант, который удивляет большинство администраторов, — почта, приходящая по IPv6 с сервера без записи обратного DNS (PTR).
Google со временем перекодирует варианты. Отказ по политике DMARC (“not accepted due to domain’s DMARC policy”) в текущем справочнике Google теперь числится под 550-5.7.26, хотя старые отказы в реальности могут по-прежнему показывать его как 5.7.1; блокировка по безопасности содержимого теперь кодируется как 552 5.7.0. Ещё два «родственника» путают с 5.7.1: 550-5.7.26, семейство требований аутентификации (его собственное руководство), и 550-5.7.25, код отсутствующего PTR для любой версии IP. Каким бы ни был код — расшифруйте текст по таблице ниже.
Какой у вас вариант 550-5.7.1?
Сопоставьте формулировку из вашего отчёта о недоставке (NDR). Google меняет эти строки от года к году — сопоставляйте суть, а не пунктуацию.
| Ваш отказ звучит примерно как… | Что это значит | Ваш путь исправления |
|---|---|---|
| ”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.” | Ваш сервер доставил по IPv6 без обратного DNS (или с несовпадающим) | PTR-запись для IPv6-адреса или ретрансляция через smarthost провайдера (ниже) |
| “The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.” | Блокировка по политике — получателя или вашего собственного домена | Свяжитесь с администратором принимающей стороны; если сработавшая политика — DMARC вашего домена, см. ниже |
| ”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.” | Блокировка за спам/репутацию — содержимое, IP или домен | Postmaster Tools + гигиена списка + отписка в один клик (ниже) |
| “This message is likely suspicious due to the very low reputation of the sending domain” (или “…sending IP address”) | Блокировка по репутации — домена или IP | Тот же репутационный путь (ниже) |
| “Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — в текущем справочнике Google кодируется 550-5.7.26; старые отказы могут по-прежнему показывать 5.7.1 | Ваша собственная политика DMARC велела Gmail отклонить неаутентифицированное сообщение | Найдите неаутентифицированный источник — не ослабляйте политику первым делом (ниже) |
| “…blocked because its content presents a potential security issue.” — теперь кодируется 552 5.7.0 | Блокировка по содержимому/политике (тип вложения, репутация ссылок) | Уберите помеченный класс содержимого; проверьте ссылки и вложения |
| Код 550-5.7.25, “the sending IP address doesn’t have a PTR record” | Отсутствует обратный DNS для любой версии IP | То же исправление rDNS, что и для варианта IPv6 |
| Код 550-5.7.26 | Семейство требований аутентификации, не 5.7.1 | См. руководство по 550-5.7.26 |
| Код 421-4.7.0, “Try again later, closing connection.” | Временная отсрочка — темп или репутация, не постоянная блокировка | Снизьте темп, исправьте аутентификацию и долю спама; обычно проходит само |
Как исправить отказ 550-5.7.1?
- Запустите бесплатную проверку на defaults.exposed — она оценивает ваши SPF, DKIM и DMARC так, как их видит мир, ещё до того, как вы тронете DNS, и показывает, возможен ли вообще для вашего домена вариант с DMARC.
- Прочитайте полный текст NDR по таблице-расшифровке — причину определяет фраза, а не код.
- Вариант с DMARC: найдите, какой отправляющий источник не прошёл аутентификацию, и почините именно его (следующий раздел).
- Вариант с IPv6/PTR: добавьте согласованный обратный DNS для IPv6-адреса сервера или ретранслируйте почту через smarthost вашего провайдера.
- Вариант со спамом/политикой: Postmaster Tools, доля спама ниже 0,10% (жёсткий потолок требований Google — 0,30%), гигиена списка, отписка в один клик по RFC 8058.
- Отправьте тест на ящик Gmail и перепроверьте — убедитесь, что отказ исчез и оценка это отражает.
Отказ упоминает вашу политику DMARC — почему это ваша политика в действии
В текущем справочнике Google эта строка кодируется как 550-5.7.26, но старые отказы и сторонняя документация всё ещё показывают её под 5.7.1 — механика в обоих случаях идентична. Это читается наоборот, пока не увидишь суть: Gmail проверил сообщение, выдающее себя за письмо с вашего домена, обнаружил, что ни SPF, ни DKIM не прошли с выравниванием, посмотрел вашу запись DMARC и сделал ровно то, о чём вы просили, — отклонил. Ваш забор сработал. Вопрос в том, что в нём застряло: забытый легитимный отправитель (CRM, инструмент выставления счетов, платформа рассылок) или настоящая подделка.
Поэтому не ослабляйте политику первым шагом. Найдите неаутентифицированный источник. На две ловушки приходится большинство случаев:
- SPF проходит, но не на том домене. Получатели проверяют SPF по домену Return-Path (RFC5321.MailFrom), а не по заголовку From. SaaS-инструмент, отправляющий «от вашего имени», обычно проходит SPF на своём собственном bounce-домене, который не выравнивается с вашим доменом в From — и DMARC всё равно не проходит. Разбор: DMARC не проходит, хотя SPF и DKIM проходят.
- DKIM проходит, но с подписью по умолчанию. Умолчания Google Workspace (
gappssmtp.com) и Microsoft (onmicrosoft.com) прекрасно проверяются и ни с чем не выравниваются. См. DKIM проходит, но DMARC всё равно не проходит.
Этот вариант встречается реже, чем можно подумать: 27 640 987 из 261 086 232 доменов — 10,59% — принуждают политику DMARC quarantine или reject, по данным переписи Defaults.Exposed (2026-06-29). Остальные 89,41% никогда не видят этот отказ, потому что у них нет забора, которому было бы что держать. Как чинить источник, а не политику, от начала до конца — в руководстве по исправлению DMARC.
Отказ упоминает правила отправки по IPv6 — исправление обратного DNS
Современные серверы часто по умолчанию соединяются с Gmail по IPv6, а Google требует, чтобы у подключающегося IPv6-адреса была PTR-запись, разрешающаяся в имя хоста, которое разрешается обратно в тот же адрес (прямо-подтверждённый обратный DNS, FCrDNS). Упустите это — и каждое сообщение получит 550-5.7.1, каким бы чистым ни был ваш SPF.
Три исправления, в порядке предпочтения:
- Установите PTR-запись для IPv6-адреса вашего сервера — это делается там, где живёт IP (панель управления вашего VPS-хостера или провайдера, а не DNS-зона вашего домена), с совпадающей AAAA-записью, указывающей обратно.
- Ретранслируйте через smarthost провайдера. Если вы не управляете rDNS, направьте исходящую почту через релей вашего почтового провайдера или интернет-провайдера — у него обратный DNS уже в порядке.
- Как временную меру предпочтите транспорт по IPv4. Обычно это прячет симптом, потому что у вашего IPv4-адреса PTR есть — обходной путь, а не исправление. Установите PTR для IPv6, как только сможете.
Отказ говорит “likely unsolicited email” — репутационный путь
Здесь аутентификация может быть в порядке, но фильтры Gmail этой почте не доверяют. Аутентификация — это пол, а не потолок: среди 12 145 313 доменов, авторизующих _spf.google.com, лишь 8,0% запирают SPF строгим -all, так что сам по себе проход проверки говорит немного. (Полное сравнение: какой почтовый провайдер даёт самые сильные умолчания SPF.)
Репутационный чек-лист:
- Зарегистрируйтесь в Google Postmaster Tools и следите за панелью доли спама — держите её ниже 0,10% и никогда не допускайте потолка 0,30%, который правила Google для массовых отправителей задают как жёсткое требование.
- Почистите список. Уберите невовлечённых и всё купленное или собранное скрейпингом; отправляйте только тем, кто сам попросил.
- Внедрите отписку в один клик по RFC 8058 для массовой почты — этого требуют правила Google, и каждая отписка, не ставшая кликом «спам», защищает вашу долю.
- Держите аутентификацию выровненной (SPF и DKIM на вашем собственном домене), чтобы репутация накапливалась на домене, которым управляете вы.
Часто задаваемые вопросы
550-5.7.1 — это то же самое, что 550-5.7.26? Нет. 550-5.7.26 — семейство требований аутентификации Gmail (SPF/DKIM отсутствуют или не проходят), и текущий справочник Google относит туда же отказ по политике DMARC. 550-5.7.1 — более старое семейство политик: блокировки по политике получателя и отправителя, IPv6 без PTR, блокировки за спам и репутацию. Какое исправление применимо, говорит текст отказа, а не номер (по состоянию на 2026-06-29 и текущие правила Google).
Стоит ли вернуть политику DMARC на p=none, чтобы отказы прекратились? Это прекратит их ценой сноса забора. Лишь 10,59% из 261 086 232 доменов переписи Defaults.Exposed (2026-06-29) вообще принуждают DMARC; если вы среди них — сохраните политику и почините неаутентифицированный источник: ослабление политики заново открывает подделку с точным именем домена.
Почему Gmail блокирует мою почту, если моя SPF-запись проходит все проверялки? Проверялки тестируют запись; Gmail тестирует сообщение. SPF оценивается по домену Return-Path, а не по видимому адресу From, так что проход на bounce-домене вендора ничего не даёт вашему выравниванию DMARC — а репутационные блокировки игнорируют SPF полностью. Бесплатная проверка показывает, какой слой на самом деле не проходит.
Означает ли 550-5.7.1, что мой IP в чёрном списке? Не обязательно. У Gmail собственная система репутации; вас может блокировать Google, пока вы не значитесь ни в одном публичном списке. Проверьте взгляд Google в Postmaster Tools — и учтите, что исправление аутентификации предотвращает будущий ущерб, но само по себе не обнуляет плохую репутацию отправителя.
Отправьте владельцу отчёт
Когда отказ исправлен, запустите проверку заново и перешлите оценённый отчёт владельцу бизнеса или клиенту, чья почта отскакивала. Он показывает, понятным языком, что было сломано, что вы исправили и где домен теперь стоит относительно базовой линии в 261 млн доменов — ровно то, что нужно для продления страховки или клиентской анкеты безопасности с вопросом «аутентифицируете ли вы свою почту?». Отказ, починенный молча, — невидимая работа; отчёт «до и после» — доказательство.
Проверьте свой домен → · Gmail 550-5.7.26 — исправление в порядке требований → · Исправить DMARC → · Как мы ставим оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.