Вы нажимаете «Отправить», и сервер отвечает 250 OK. Через две недели выясняется, что письмо не попало во входящие: оно оказалось в спаме или, в зависимости от политики шлюза, могло быть удалено до входа получателя в систему. Тема и содержимое тоже могут повлиять на результат, но ещё одна возможная причина связана с репутацией почтового домена, которая могла ухудшаться уже несколько недель.
После ужесточения требований Google и Yahoo в феврале 2024 года отправители и потоки, подпадающие под их определения, должны соблюдать конкретные стандарты. Нарушение порогов может ухудшить доставку или привести к отклонениям, но не означает всеобщую блокировку. В этом руководстве рассмотрены причины снижения репутации, диагностические коды и план восстановления. Если сначала нужна базовая настройка DNS, начните с настройки почты на своём домене.
Что на самом деле представляет собой репутация почтового домена
Репутация почтового домена объединяет сигналы доверия, которые Google, Microsoft, Yahoo и другие почтовые провайдеры связывают с поведением отправляемой почты. Высокая доля жалоб, сбои аутентификации и плохое состояние списка могут ей повредить. Единой оценки и фиксированного срока восстановления не существует: каждый провайдер использует собственные сигналы и учитывает недавнее поведение.
Репутация не возвращается к исходному значению автоматически. Домен с многолетней положительной историей может пережить отдельные ошибки, а домен с большим числом жалоб или сбоев аутентификации может восстанавливаться недели или месяцы. Результат зависит от причины, провайдера и качества последующих отправок.
Некоторые сигналы агрегируются на уровне корневого домена, но правила для поддоменов различаются. Если marketing.example.com попал в список блокировки, письма с ceo@example.com не обязательно автоматически окажутся в спаме, хотя связанные сигналы могут повлиять на них. Разделение снижает риск, но не создаёт абсолютной защиты.
Достигнутый максимум и сохраняющаяся классификация
Если Google классифицирует домен как массового отправителя, то есть отправляющего примерно 5,000 писем в день на личные аккаунты Gmail, эта классификация может сохраниться и после снижения объёма. Это не вечный статус у всех провайдеров. Для подпадающих под правила потоков продолжают действовать требования, включая отказ от проморассылки одним нажатием и опубликованную политику DMARC. Общие правила сами по себе не требуют p=quarantine или p=reject. Проверяйте актуальную политику.
При объёме ниже ~100 писем/день на Gmail Postmaster Tools может показать "No Data" из-за нехватки данных. Проверки на контрольных адресах и анализ возвратов дают ограниченные сигналы, но не заменяют реальные данные и не гарантируют точного вывода.
4 распространённые причины ухудшения репутации
При снижении репутации домена стоит проверить четыре частые области: жалобы, выравнивание аутентификации, лимит DNS-запросов SPF и окончательные возвраты. Возможны и другие причины. Правильная диагностика помогает не применять неподходящее исправление.
1. Риск при уровне жалоб 0.3%
Жалобы на спам могут быстро повредить домену. Google и Yahoo публикуют собственные пороги и критерии. Уровень 0.3%, то есть 3 жалобы на 1,000 писем, повышает риск фильтрации и может повлиять на доступность отдельных мер смягчения, но не вызывает мгновенную универсальную блокировку. Google рекомендует оставаться ниже 0.1%. Показатель 0.3% является границей риска, а не целью. Проверяйте текущие правила для своего трафика.
Yahoo может рассчитывать или показывать этот показатель с другим знаменателем. Прежде чем утверждать, что учитываются только письма, попавшие во входящие, проверьте актуальное определение.
Условный сценарий: вы отправляете 1,000 писем. 900 автоматически попадают в спам. 100 оказываются во входящих. 1 человек жалуется.
Условный расчёт: 1 жалоба ÷ 100 писем во входящих = доля жалоб 1.0%.
Результат: значение было бы равно 3× указанного лимита в этом примере, но реальный расчёт зависит от определения провайдера.
Открываемость может снизиться, однако её измерение ненадёжно как отдельное доказательство. При достаточном объёме Google Postmaster Tools может показывать "Low" или "Bad", причём интерфейс и названия способны меняться. Сопоставляйте эти данные с возвратами, жалобами и ответами SMTP.
2. Несогласованная аутентификация и сигнал подмены
SPF и DKIM могут быть настроены, но DMARC не пройдёт, если ни один результат не выровнен с видимым доменом отправителя. Для DMARC достаточно выровненного SPF или DKIM, оба одновременно не обязательны. Повторяющиеся сбои могут вредить репутации и выглядеть как подмена, но вывод следует делать по полным заголовкам.
Например, вы используете Mailchimp или SendGrid. Отправитель конверта для SPF указывает на mail.sendgrid.net, а заголовок From содержит yourcompany.com. SPF проходит, поскольку IP разрешён, но выравнивание DMARC не выполняется, если нет и выровненной подписи DKIM. Пользовательский домен ESP может выровнять SPF, DKIM или оба механизма в зависимости от настройки.
Microsoft может возвращать 550 5.7.515 в отдельных сценариях аутентификации или политик, особенно для больших объёмов. Это не всегда блокировка содержимого, и проблема не обязательно решается одной заменой Return-Path. Изучите полный ответ и настройте пользовательскую аутентификацию домена по документации ESP.
3. Лимит 10 запросов SPF (RFC 7208)
SPF не является бесконечным списком. RFC 7208, раздел 4.6.4, ограничивает 10 количество терминов, вызывающих DNS-запросы при одной проверке SPF. Добавив Google, Outlook, Zendesk, Mailchimp и CRM, можно приблизиться к пределу. Вложенные директивы include: тоже расходуют запросы при вычислении.
При 11 учитываемых запросах проверка может вернуть PermError. Не рассчитывайте, что отдельные провайдеры всегда примут некорректный SPF из-за менее строгого анализатора. Симптомы зависят от получателя и политики, поэтому проверяйте результат SPF и дерево запросов.
4. Окончательные возвраты и перебор адресов
Microsoft учитывает окончательные возвраты. Уровень 2-3% можно использовать как иллюстративный сигнал для аудита списка, но это не официальный порог неизбежной мгновенной блокировки за автоматический перебор. Отличайте несуществующие адреса от постоянных ошибок политики или аутентификации. Возможны ответы 550 5.7.1 и временные ошибки вроде 421 RP-001.
Даже при 0% жалоб блокировка возможна по другим причинам. Эти показатели независимы, но нулевой уровень жалоб не гарантирует доставку. Проверяйте список и расширенные коды до отправки на адреса Microsoft.
Данные отдельных провайдеров
Чтобы улучшить репутацию домена, выясните, какой провайдер фильтрует или отклоняет почту. Провайдеры по-разному взвешивают сигналы и предоставляют разные инструменты. Доступность данных, требования к объёму и функции меняются, поэтому сверяйтесь с текущей документацией.
| Провайдер | Основное внимание | Средство диагностики | Важный нюанс |
|---|---|---|---|
| Google (Gmail / Workspace) | Жалобы и взаимодействие наряду с другими сигналами | Google Postmaster Tools | При малом объёме (<100/день на Gmail) может отображаться "No Data"; контрольные адреса дают лишь выборку |
| Microsoft (Outlook / 365) | Техническое соответствие и репутация IP наряду с другими сигналами | SNDS (Smart Network Data Services), если доступны регистрация и данные | Для новых IP часто требуется плавный рост; ограничения зависят от трафика и политики |
| Yahoo / AOL | Содержимое и жалобы наряду с другими сигналами | Yahoo Sender Hub и CFL для соответствующих требованиям отправителей | Complaint Feedback Loop требует регистрации, а отчёты ARF зависят от охвата и условий |
Диагностический процесс: изоляция сбоя
Не действуйте наугад. Выполняйте следующие запросы только для чтения и только к системам, которые вам разрешено проверять, затем изучите заголовки. Результаты укажут на возможный слой проблемы, но не определят точную причину автоматически.
Проверка инфраструктуры в терминале
Проверьте аутентификацию до изменения политик. Эти три запроса только для чтения охватывают частые точки отказа; замените примеры своими разрешёнными ресурсами.
# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short
# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short
# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.
# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4
Если FCrDNS не проходит и IP не совпадает с именем хоста, риск отклонения в Gmail, Yahoo и у других получателей может вырасти, но универсальной автоматической блокировки нет. Исправьте разрешённую конфигурацию, дождитесь обновления DNS и проверьте снова.
Анализ заголовков
Отправьте одно ожидаемое тестовое письмо на контролируемый аккаунт Gmail. Откройте его, нажмите три точки и выберите "Показать оригинал". Найдите заголовок Authentication-Results, добавленный доверенным сервером получателя, а не копию от отправителя.
Проблемный сигнал, сбой выравнивания:
spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com
SPF и DKIM прошли, но DMARC не прошёл, поскольку ни один домен не выровнен с yourcompany.com. Пример показывает конфигурацию, способную ухудшать репутацию, но одно письмо не характеризует весь поток.
Положительный сигнал, выровненная аутентификация:
spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass
План восстановления
Если Google Postmaster Tools показывает "Bad", восстановление может занять 2-4 недели или больше качественной структурированной отправки. Этот срок не гарантирован, а единого протокола нет. Работайте поэтапно и учитывайте ответы провайдера до увеличения объёма.
Этап 1: аудит списка
Не удаляйте автоматически всех, кто не открыл письмо или не перешёл по ссылке за 90 дней: измерение открытий неполно. Проверьте согласие, реальную активность, возвраты и требования хранения; подавляйте подтверждённо недействительные адреса и тех, кто не ожидает писем. Если адрес дважды вернул User Unknown, изучите расширенные коды и работу системы подавления до следующей партии.
Этап 2: техническое исправление
Не меняйте DMARC с p=none на p=quarantine без разрешения, анализа отчётов и учёта всех легитимных отправителей. Вводите политику постепенно: карантин снижает отдельные злоупотребления, но не останавливает всю подмену. При ключах DKIM длиной 1024 бита проверьте алгоритм, совместимость и текущую политику провайдера перед переходом на 2048 бит и обновлением DNS. Формат для доменов TrekMail описан в руководстве по обязательным DNS-записям.
Этап 3: постепенный рост
Начните с получателей, ожидающих сообщение, чья недавняя активность подтверждается надёжными сигналами, а не только открытием за последние 30 дней. Этот график иллюстративный; адаптируйте его к провайдеру, возможностям и ответам:
- День 1: 50 писем
- День 2: 100 писем
- День 3: 200 писем
- День 4: 400 писем
Ежедневно проверяйте доступные данные. Если репутация снижается, пауза на 48 часов и возврат к предыдущему объёму могут быть одним из вариантов, а не универсальным правилом. Учитывайте текущие коды и политики.
Гигиена инфраструктуры: скрытые проблемы
Два аспекта инфраструктуры могут влиять на репутацию без очевидных сигналов. Даже при правильной аутентификации проверяйте шифрование транспорта и пул IP вместе с другими факторами.
Политика TLS
Многие провайдеры ожидают TLS, когда он доступен, а для отдельных потоков и политик шифрование обязательно. Это не означает, что каждый MTA должен требовать TLS 1.2 для любого назначения: SMTP может использовать оппортунистический TLS или специальные обязательные политики. Проверяйте текущую конфигурацию и требования TrekMail либо своего провайдера.
Другие отправители на общем IP
На недорогом общем хостинге или бесплатном уровне ESP один IP могут использовать тысячи отправителей. Если сосед рассылает спам, IP может попасть в Spamhaus SBL и повлиять на вашу почту, даже если злоупотребление исходило не от домена. Последствия и исправление зависят от списка и провайдера.
При объёме выше 100k/месяц выделенный IP может дать больше контроля, но не всегда лучше и требует достаточного трафика и управления. При меньшем объёме подойдёт провайдер с качественным контролем пула или внешний SMTP. Функция BYO SMTP в TrekMail позволяет подключить Amazon SES, SendGrid или Mailgun, если это поддерживает тариф. Такая схема не обязательно означает, что IP принадлежит вам, находится под исключительным контролем или имеет хорошую репутацию.
Роль TrekMail
Репутация почтового домена является эксплуатационным ограничением, а не маркетинговой переменной. Для неё нужны точная настройка DNS, ответственное управление получателями и подходящая исходящая инфраструктура.
Если вы управляете несколькими доменами, руководство по многодоменному почтовому хостингу поможет выстроить их и снизить общие риски. Подробнее об аутентификации рассказано в базовом руководстве по безопасности почты.
В зависимости от текущего тарифа и конфигурации TrekMail может предоставлять функции входящей почты: хранилище с фиксированной оплатой, IMAP-ящики, маршрутизацию catch-all и серверную миграцию без оплаты за пользователя в описанных предложениях. Для исходящей почты подключается совместимый SMTP-провайдер. Мастер помогает настроить SPF/DKIM/DMARC при подключении, но DNS и каждый поток нужно проверить: автоматическая аутентификация всех писем не гарантируется.
В описанном предложении тарифы начинаются с $3.50/месяц. Также указан бесплатный 14-дневный пробный период с обязательной картой и тариф Nano без карты, описанный как бесплатный, с 10 доменами и 5 GB. Цены, лимиты, функции и условия могут меняться; перед оформлением проверьте trekmail.net/pricing.
Итоги
Среди частых причин ухудшения репутации: жалобы выше 0.3%, нарушение выравнивания DMARC у ESP, превышение лимита в 10 запросов SPF и окончательные возвраты. Это не исчерпывающий список, и каждая причина требует отдельной диагностики.
Если репутация уже пострадала, проверьте список по надёжным критериям, постепенно исправьте технический слой и увеличивайте объём с учётом ответов. Две-четыре недели являются лишь возможным ориентиром, а не фиксированным сроком или единственным протоколом.
Проверьте DNS сегодня с помощью разрешённых запросов. Если найдёте ошибку, спланируйте исправление и подтвердите результат до следующей кампании.
