Доставляемость и DNS

Письма попадают в спам: проверка возможных причин

Автор: Alexey Bulygin
Проверка заголовков и DNS для писем, попавших в спам

Письма, попадающие в спам, не всегда являются только проблемой текста. Часто влияют инфраструктура, содержание и поведение получателей. Если счета, сбросы пароля, предложения или onboarding внезапно оказываются в нежелательной почте, проверяйте не только темы, но и аутентификацию, DNS, репутацию и путь отправки. При выборе платформы материал про корпоративную почту для малого бизнеса разбирает стоимость, а эта статья разбирает причины сбоев и порядок проверки.

Когда письма начинают попадать в спам, число обращений быстро растёт. Ошибка SPF может затронуть домен, невыравненная подпись DKIM может повлиять на кампанию, а неделя с жалобами может затронуть последующие отправки. Многие случаи можно диагностировать, если отказаться от догадок и проверять свидетельства по порядку.

Почему легитимные на вид письма попадают в спам?

Часто принимающий сервер недостаточно доверяет отправителю, но текст, ссылки и сигналы получателей тоже могут влиять. Gmail, Yahoo и Outlook учитывают аутентификацию, выравнивание, состояние DNS, жалобы, поведение отправки и содержание.

Старая модель из создания ящика и изменения текста при сбоях уже недостаточна. В 2025 и 2026 году для подпадающих под правила отправителей применяются требования к SPF, DKIM, DMARC, TLS, PTR и отписке. Они описаны в рекомендациях Google, а Postmaster предоставляет частичные данные о репутации и соответствии.

При одном домене это неудобство, при пятидесяти клиентских доменах постоянная работа. В зависимости от плана и конфигурации TrekMail предлагает собственные домены, IMAP-ящики, catch-all, пересылку, BYO SMTP либо управляемый SMTP и миграцию IMAP. По указанным в статье текущим условиям платные планы начинаются с $3.50 в месяц, Nano может быть бесплатным, а для платных планов может действовать пробный период 14 дней. Проверьте актуальные цены и функции. Миграция IMAP не переносит DNS и приложения и не гарантирует отсутствие простоя.

Куда смотреть в первую очередь

Наиболее быстрые подсказки часто находятся в заголовках затронутого письма. Откройте исходник, найдите Authentication-Results и проверьте SPF, DKIM, DMARC, а также выравнивание видимого From с аутентифицированными доменами. Рассматривайте прежде всего заголовки, добавленные проверяемой принимающей системой, поскольку переданный отправителем заголовок сам по себе не является доказательством.

SPF может пройти, но не быть выровнен для DMARC. То же верно для DKIM. Для DMARC достаточно выровненного SPF или действительной выровненной DKIM-подписи; оба механизма не обязаны проходить одновременно. Инструмент может показать аутентификацию, а получатель увидеть расхождение между RFC5322 From и доменом реальной подписи либо MAIL FROM. Даже успешная аутентификация не гарантирует входящие.

Начните с короткого списка:

  1. Откройте исходные заголовки в Gmail, Outlook или Apple Mail.
  2. Найдите Authentication-Results.
  3. Проверьте spf=pass, dkim=pass и dmarc=pass.
  4. Убедитесь, что From соответствует выровненному домену SPF или действительной подписи DKIM.
  5. При сбое DMARC сначала исследуйте выравнивание, затем переходите к содержанию.

В качестве платформенного списка можно использовать FAQ TrekMail по спаму, чтобы начать разделять ошибки DNS и репутации.

Три технических сбоя, часто связанные со спамом

Многие случаи связаны с тремя техническими проблемами: превышением запросов SPF, слабым или невыравненным DKIM и ошибками выравнивания DMARC. Они не объясняют каждую фильтрацию; содержание и решение получателя тоже важны.

1. SPF ломается чаще, чем предполагают. У SPF есть жёсткий предел. RFC 7208 ограничивает DNS-запрашивающие механизмы и модификаторы, включая вложенные, значением 10 на одну оценку. Несколько провайдеров и include могут превысить его, после чего SPF считается ошибочным.

example.com. IN TXT "v=spf1 include:spf.trekmail.net include:sendgrid.net include:_spf.google.com -all"

Запись может выглядеть безобидно, но изменение вложенных include одним провайдером способно позже превысить лимит.

2. DKIM проходит, но домен подписи не выровнен. Отправитель может подписывать с d=vendor.com, тогда как видимый From использует yourdomain.com. Само значение не обязательно ошибочно: выравнивание зависит от организационного домена, strict или relaxed режима и наличия другого успешного выровненного механизма. Без него спам-фильтрация остаётся возможной.

3. DMARC отсутствует или не анализируется. Текущие правила Google требуют DMARC для применимых массовых отправителей и отдельно называют ошибки выравнивания. Без записи либо проверки доступных отчётов теряются важные, хотя и неполные сведения.

; baseline records
@      IN TXT "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey IN TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

Это иллюстративные записи, а строка с p=quarantine не является универсальным начальным шаблоном. Фактические значения и этап политики должны следовать инвентарю и тестам. Документация TrekMail помогает единообразно проверять записи при повторяющихся задачах мультидоменного хостинга.

Как состояние DNS и сети влияет на спам

Получатели смотрят не только на аутентификацию, но и на PTR и forward-confirmed reverse DNS фактического отправляющего IP. MX и остатки старых провайдеров важны прежде всего для входящей маршрутизации и диагностики. Несогласованная инфраструктура может способствовать строгой фильтрации, но сама по себе не доказывает причину.

В FAQ Google для подпадающих под требования прямых отправителей требуется PTR, имя которого разрешается обратно в фактический IP отправки. При собственном SMTP или внешнем провайдере проверяйте именно применимый путь. Отсутствие rDNS может способствовать блокировке до оценки содержания.

Проверьте домен и IP в терминале:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
dig +short PTR 203.0.113.10
host mail.example.com

Неаккуратные ответы служат поводом для проверки. Частые ошибки:

СбойЧто видноВозможное влияниеИсправление
Слишком много запросов SPFНепостоянные сбои SPFОценка SPF возвращает PermErrorСократить include; flattening применять осторожно и постоянно проверять, поскольку IP меняются
Старые MX-записиСмешанная входящая маршрутизация и странные отклоненияВходящая почта может идти не тому провайдеру; это не универсальная причина исходящего спамаУдалять только подтверждённо устаревшие MX
Нет PTR/rDNSБлоки или жёсткая фильтрацияУ фактического IP отправки отсутствует ожидаемый сигналТам, где требуется для пути, добавить PTR и проверить прямое разрешение
DKIM на домене провайдераDKIM pass, DMARC failНет необходимого выравниванияЕсли поддерживается, подписывать своим доменом и проверить письмо

При смене хостинга нужна аккуратная миграция. Согласно текущей документации, TrekMail может копировать письма по IMAP из Gmail, Microsoft 365 и обычных IMAP-сервисов. Это не переносит DNS, MX или настройки приложений. Для домена начните с обязательных DNS-записей, спланировав тесты и откат.

Почему репутация отстаёт от исправлений DNS

После исправления аутентификации и DNS письма могут продолжать попадать в спам, потому что репутация является запаздывающим сигналом. Провайдеры учитывают жалобы, взаимодействие, отклонения, прогрев и стабильность объёмов. Чистый SPF не восстанавливает недавнюю историю мгновенно.

Администраторы иногда чинят DNS в понедельник, отправляют 20,000 сообщений во вторник и заключают, что исправление не сработало. Репутация меняется не сразу.

Текущий FAQ Google определяет конкретное условие для применимых массовых отправителей: при пользовательской спам-доле выше 0.3% недоступны определённые меры смягчения, пока показатель не остаётся ниже порога семь дней подряд. Это не универсальная граница доставляемости. В пользовательской спам-доле Google Postmaster Tools отмеченные сообщения соотносятся с письмами, доставленными во входящие; учитывайте доступность и задержку данных.

Вы отправили 1,000 сообщений. Из-за слабой репутации только 150 попали во входящие. Два пользователя отметили спам. В иллюстративном расчёте по попавшим во входящие доля равна 1.33%. Это иллюстративный расчёт по описанной методике, а не универсальный прогноз дальнейшей доставки.

Если проблема длится давно, после технической очистки сделайте три шага:

  1. Временно сократите объём и отправляйте активным недавним получателям с подтверждённым согласием; универсального срока прогрева нет.
  2. Прекратите работу с купленными списками, приостановите холодные и старые неподтверждённые сегменты.
  3. Регулярно смотрите Google Postmaster Tools, учитывая доступность, задержки и неполноту данных.

Для применимых рекламных или массовых сообщений важна простая отписка. Обычный mailto: не выполняет требований Google к one-click. RFC 8058 описывает нужные заголовки и POST-поток.

List-Unsubscribe: <https://example.com/unsub/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Сигнал отписки задаётся как List-Unsubscribe=One-Click, а соответствующие заголовки следует включать в DKIM-подпись. При отсутствии механизма пользователи могут чаще выбирать кнопку спама.

Что делать с транзакционными письмами в спаме

Спам-фильтрация транзакционных писем может нарушить доступ, оплату, чеки и доверие. Частые технические факторы: общая репутация, неверное выравнивание, пересылка или один поток с рекламой. Содержание и поведение получателя тоже могут влиять.

Разделяйте транзакционную и рекламную почту, если это оправдано объёмом и риском: при необходимости используйте разные домены или поддомены, прогрев и мониторинг. Не направляйте сбросы пароля по массовому рекламному пути, когда технически доступно подходящее разделение.

Здесь становится практичным выбор между разрозненными и интегрированными инструментами.

Традиционный подход: пакет на каждого пользователя, отдельные пересылка и провайдер отправки, ручное исправление SPF, DKIM и DMARC для каждого домена.

Интегрированный подход: управлять ящиками, пересылкой, доменами и выбором SMTP в одном месте. По текущим условиям Nano может использовать BYO SMTP, а платные планы могут включать управляемый SMTP. Это не переносит и не гарантирует репутацию. TrekMail ориентирован на IMAP и несколько доменов, а возможности зависят от тарифа.

При настройке полезны управляемый SMTP TrekMail, процесс создания в как создать почту на домене и актуальное замечание, что сервис использует IMAP, а не POP3.

Быстрый рабочий процесс против спам-фильтрации

Полезный порядок триажа: сначала заголовки, затем DNS, репутация и содержание. Это не означает, что текст неважен; такая последовательность лишь сокращает риск пропустить SPF, DKIM, DMARC или rDNS.

Используйте этот процесс:

  1. Откройте одно затронутое письмо и изучите исходные заголовки.
  2. Проверьте результаты SPF, DKIM, DMARC и выравнивание.
  3. Проверьте DNS для SPF, MX, DMARC, DKIM и PTR.
  4. Посмотрите доступные данные репутации и жалоб в Google Postmaster Tools.
  5. Разделите транзакционный и рекламный трафик, если общая инфраструктура создаёт риск и разделение оправдано.
  6. Добавьте one-click заголовки для применимых маркетинговых потоков.
  7. Сократите объём, пока наблюдаете жалобы и реакцию получателей.

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

По приведённым в статье текущим ценам Nano начинается с $0 и поддерживает до 10 доменов с BYO SMTP. Starter от $3.50 в месяц, Pro от $10 в месяц, Agency от $23.25 в месяц; для годовой оплаты указан дисконт 20%. Enterprise рассчитывается отдельно. Сверьте актуальную страницу и собственный сценарий: https://trekmail.net/pricing.

Главный вывод о спам-фильтрации

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

Читайте доверенные заголовки, исправляйте подтверждённые ошибки домена, проверяйте PTR фактического IP, разделяйте потоки где это оправдано, внедряйте RFC 8058 для применимых кампаний и отслеживайте репутацию с учётом неполноты данных. TrekMail может централизовать домены и ящики и, в зависимости от плана, предоставить BYO или управляемый SMTP, но не гарантирует доставку или восстановление репутации.

По стандартам и актуальным требованиям начните с FAQ Google для отправителей и RFC 8058.

Поделиться статьёй

Мы используем необходимые технологии для работы и защиты TrekMail. Подтверждая это, вы также разрешаете ограниченную аналитику и измерение рекламы, описанные в Политике cookie.

Вход в TrekMail

Доступ к панели, ящикам и DNS.

или

12 символов пароли совпадают

или

Письмо отправлено

Если для этого адреса есть аккаунт, мы отправили инструкции по сбросу пароля.

Продолжая, вы принимаете Условия и Политику конфиденциальности TrekMail.