Gmail „550-5.7.1 Message Blocked” — Декодирайте bounce-а и го поправете (2026)

Публикувано 2026-07-08

Данни към 2026-06-29 · методология v7. Агрегирани census данни от 261 милиона оценени домейна. Вижте как оценяваме.

Gmail връща 550-5.7.1 когато блокира съобщение по причини, свързани с политика, а не с липсващ запис: политика на изпращащ или получаващ домейн, IPv6 връзка без обратен DNS или подозрителен спам. От 12,145,313 домейна, оторизиращи собствените сървъри на Google в SPF, само 18.5% прилагат DMARC, според census-а на Defaults.Exposed от 261 милиона домейна.

550-5.7.1 е най-старото универсално отхвърляне на Gmail, а поправката зависи от изречението след кода в bounce-а. По-долу: таблица за декодиране на точната формулировка, след това пътят за поправяне за всеки вариант — блокирания по политика, IPv6 сървъри без обратен DNS, блокирания заради спам или съдържание — плюс look-alike кодовете, с които хората го бъркат, включително семейството 5.7.26, сега използвано от Google за отхвърляне по DMARC политика, по-старите референции включвали под 5.7.1.

Какво всъщност означава Gmail 550-5.7.1?

В схемата SMTP с разширени статусни кодове (RFC 3463), всеки 5.7.x код означава „постоянен неуспех, причини, свързани с политика”. Gmail използва 550-5.7.1 като старото семейство за политика: блокирания по политиката на изпращача или получателя, блокирания по репутация за спам, и — вариантът, изненадващ повечето администратори — поща, пристигаща по IPv6 от сървър без PTR запис в обратен DNS.

Google е прекодирал варианти с времето. Отхвърлянето по DMARC политика („не е прието поради DMARC политиката на домейна”) сега е под 550-5.7.26 в текущата референция на Google, въпреки по-стари bounce-ове в обращение, може все още да показват 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 коригира тези низове между годините — съпоставяйте смисъла, не пунктуацията.

Bounce-ът ви чете нещо като…	Какво означава	Вашият път за поправяне
„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 + почистване на списъка + one-click unsubscribe (по-долу)
„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.” — кодиран 550-5.7.26 в текущата референция на Google; по-стари bounce-ове може все още да показват 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.”	Временно отлагане — скорост или репутация, не постоянно блокиране	Забавете, поправете автентикацията и spam rate; обикновено се изчиства

Как да поправите bounce 550-5.7.1?

Стартирайте безплатното сканиране на defaults.exposed — оценява SPF, DKIM и DMARC така, както ги вижда светът, преди да докосвате DNS, и показва дали вариантът с DMARC е изобщо възможен за домейна ви.
Прочетете пълния текст на NDR спрямо таблицата за декодиране — изречението, не кодът, идентифицира причината.
Вариант с DMARC: намерете кой изпращащ источник не е преминал автентикацията и поправете него (следващ раздел).
Вариант с IPv6/PTR: добавете съответстващ обратен DNS за IPv6 адреса на сървъра или ретранслирайте чрез smarthost на доставчика.
Вариант с спам/политика: Postmaster Tools, spam rate под 0.10% (твърдото изискване на Google е таван от 0.30%), почистване на списъка, RFC 8058 one-click unsubscribe.
Изпратете тест до пощенска кутия в Gmail и направете ново сканиране — потвърдете, че bounce-ът е изчезнал и оценката го отразява.

Bounce-ът споменава DMARC политиката ви — защо вашата политика работи

Текущата референция на Google кодира този низ като 550-5.7.26, но по-стари bounce-ове и документация на трети страни все още го показват под 5.7.1 — при двата случая механиката е идентична. Изглежда наопаки, докато не го видите: Gmail е проверил съобщение, твърдящо, че е от вашия домейн, установил, че нито SPF, нито DKIM са минали с alignment, потърсил DMARC записа ви и е направил точно каквото сте поискали — reject. Оградата ви е задържала. Въпросът е какво е заловено в нея: забравен легитимен изпращач (CRM, инструмент за фактуриране, платформа за бюлетини) или истинска измама.

Затова не разхлабвайте политиката като стъпка едно. Намерете неавтентикирания источник. Две клопки обясняват повечето случаи:

SPF минава, но при грешния домейн. Получателите оценяват SPF спрямо домейна Return-Path (RFC5321.MailFrom), а не хедъра From. SaaS инструмент, изпращащ „от” вас, обикновено минава SPF при собствения си bounce домейн, несъвпадащ с вашия From домейн — така DMARC все пак не минава. Ръководство: DMARC не минава, но SPF и DKIM минават.
DKIM минава, но с подразбиращия се подпис. Стандартните настройки gappssmtp.com на Google Workspace и onmicrosoft.com на Microsoft се верифицират добре и са aligned с нищо. Вижте DKIM минава, но DMARC все пак не минава.

Вариантът е по-рядък, отколкото бихте мислили: 27,640,987 от 261,086,232 домейна — 10.59% — прилагат DMARC политика quarantine или reject, според census-а на Defaults.Exposed (2026-06-29). Другите 89.41% никога не виждат този bounce, защото нямат ограда за задържане. Поправянето на источника, а не политиката, е разгледано изцяло в ръководството за поправка на DMARC.

Bounce-ът споменава насоките за изпращане по IPv6 — поправката на обратен DNS

Съвременните сървъри часто се свързват с Gmail по IPv6 по подразбиране, а Google изисква свързващият IPv6 адрес да има PTR запис, разрешаващ до hostname, разрешаващ обратно до същия адрес (forward-confirmed reverse DNS). Пропуснете го и всяко съобщение получава 550-5.7.1, независимо колко чист е SPF-ът.

Три поправки, в ред на предпочитание:

Задайте PTR записа за IPv6 адреса на сървъра — прави се там, където живее IP-то (панелът на VPS хоста или доставчика на интернет, а не DNS зоната на домейна ви), с съответстващ AAAA запис, сочещ обратно.
Ретранслирайте чрез smarthost на доставчика. Ако не можете да контролирате rDNS, насочете изходящата поща чрез ретранслатора на имейл доставчика или ISP-а ви, вече имащ правилен rDNS.
Предпочитайте IPv4 транспорт като временна мярка. Обикновено скрива симптома, защото IPv4 адресът ви има PTR — заобиколен маршрут, а не поправка. Задайте IPv6 PTR когато можете.

Bounce-ът казва „вероятно нежелана поща” — пътят за репутацията

Тук автентикацията може да е наред, но филтрите на Gmail не се доверяват на пощата. Автентикацията е подът, не таванът — сред 12,145,313 домейна, оторизиращи _spf.google.com, само 8.0% заключват SPF с строг -all, така че минаваща проверка сама по себе си казва малко. (Пълно сравнение: кой имейл доставчик дава най-силните SPF настройки по подразбиране.)

Контролният списък за репутацията:

Регистрирайте се в Google Postmaster Tools и следете таблото за spam rate — пазете го под 0.10% и никога не позволявайте да достигне тавана от 0.30%, зададен в насоките на Google за масови изпращачи като твърдо изискване.
Почистете списъка. Премахнете неангажиращите и всичко закупено или набрано; изпращайте само до хора, поискали да получат.
Внедрете RFC 8058 one-click unsubscribe при масова поща — изисква се от правилата на Google, а всяко отписване, което не е кликване върху „spam”, защитава процента ви.
Запазете автентикацията aligned (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, блокирания за спам и репутация. Текстът на bounce-а, а не числото, ви казва коя поправка е приложима (към 2026-06-29 и текущите насоки на Google).

Трябва ли да върна DMARC политиката обратно на p=none, за да спра bounce-овете? Това ги спира като събаря оградата. Само 10.59% от 261,086,232 домейна в census-а на Defaults.Exposed (2026-06-29) прилагат DMARC изобщо; ако сте един от тях, запазете политиката и поправете неавтентикирания источник — разхлабването на политиката отново отваря точно-домейновото спуфиране.

Защо Gmail блокира пощата, когато SPF записът ми минава всеки проверяващ? Проверяващите тестват записа; Gmail тества съобщението. SPF се оценява спрямо домейна Return-Path, не видимия адрес From, така че pass при bounce домейна на доставчик не прави нищо за DMARC alignment-а ви — и блокиранията за репутация игнорират SPF напълно. Безплатното сканиране показва кой слой действително не минава.

Означава ли 550-5.7.1, че IP-то ми е в черен списък? Не непременно. Gmail управлява собствена система за репутация; може да сте блокирани от Google, докато не сте в никакъв публичен черен списък. Проверете Postmaster Tools за гледната точка на Google — и отбележете, че поправянето на автентикацията предотвратява бъдещи щети, но само по себе си не ресетира лоша репутация за изпращане.

Изпратете доклада на собственика

След поправянето на bounce-а, пуснете сканирането и препратете оценения доклад на собственика на бизнеса или клиента, чиято поща е отхвърляна. Показва, на разбираем език, какво е счупено, какво сте поправили и каква е позицията на домейна спрямо базата данни от 261 милиона домейна — точно това, от което се нуждаят за подновяването на застраховката или въпросника за сигурност на клиент, питащ „автентикирате ли имейла си?”. Мълчаливо поправен bounce е невидима работа; доклад „преди и след” е доказателство.

Проверете домейна → · Gmail 550-5.7.26 — поправката в ред на изисквания → · Поправете DMARC → · Как оценяваме → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.