Перейти к содержанию

Инструменты проверки почты

На сайте Mailexam® доступен набор бесплатных инструментов для диагностики DNS-записей и репутации домена. Регистрация не требуется: введите домен или IP и получите результат с пояснениями и рекомендациями.

Инструменты открываются из раздела Экспресс-тест на главной странице и из подвала сайта. На каждой странице есть ссылки на остальные проверки.

Когда использовать

  • Перед продакшен-рассылкой — убедиться, что SPF, DKIM и DMARC настроены корректно.
  • При проблемах с доставляемостью — проверить RBL, PTR и политику MTA-STS.
  • При брендинге писем — проверить BIMI-запись и отображение логотипа.

Доступные проверки

Инструмент Что проверяет Ссылка
SPF TXT-запись Sender Policy Framework: разрешённые серверы отправки, синтаксис, политика -all Проверить SPF
DKIM Публичный ключ в DNS по селектору; при отсутствии записи — генератор пары ключей и готовый TXT для публикации Проверить DKIM
DMARC Политика _dmarc, режим p=, адрес отчётов Проверить DMARC
RBL IP-адрес или домен в 50–100 основных спам-листах (Spamhaus, Barracuda, SURBL и др.); результаты приходят потоком Проверить RBL
Reverse DNS (PTR) PTR-запись IP отправки и совпадение обратного и прямого DNS Проверить PTR
MTA-STS и TLS-RPT Политика принудительного шифрования SMTP и запись для отчётов о TLS Проверить MTA-STS
BIMI Brand Indicators for Message Identification — BIMI-запись и готовность к отображению логотипа бренда Проверить BIMI

SPF, DKIM и DMARC

Три инструмента работают на одной странице-шаблоне: вводите домен, для DKIM дополнительно селектор (по умолчанию default). После проверки отображаются:

  • статус: корректно, требует внимания или не найдено;
  • найденная DNS-запись и разбор синтаксиса;
  • пошаговые рекомендации по настройке, если запись отсутствует или настроена небезопасно.

Для DKIM при статусе «не найдено» доступна генерация ключевой пары (1024, 2048 или 4096 бит) с готовым значением TXT-записи для DNS.

Теория по терминам — в глоссарии: SPF, DKIM, DMARC.

Инструменты и sandbox

Проверки DNS не связаны с тестовым SMTP Mailexam®: для sandbox меняются только учётные данные SMTP, записи домена не требуются. Инструменты пригодятся на этапе боевой рассылки, когда домен уже отправляет почту реальным получателям.

RBL (чёрные списки)

RBL (Realtime Blackhole List) и DNSBL (DNS-based Blackhole List) — это публичные списки IP-адресов и доменов, с которых зафиксирована рассылка спама, фишинга, вредоносного ПО или иная подозрительная активность. Крупные почтовые провайдеры и антиспам-фильтры сверяют адрес отправителя с такими списками ещё до проверки SPF, DKIM и содержимого письма.

Как попадание в список влияет на доставку

Ситуация Типичное последствие
IP в одном «мягком» списке Письма чаще попадают в спам или проходят с пониженным приоритетом
IP в нескольких авторитетных списках (Spamhaus, Barracuda) Отклонение на этапе SMTP (550), массовые отказы
Домен отправителя в SURBL и аналогах Фильтрация по ссылкам и репутации домена, даже если IP «чистый»

Попадание в RBL не всегда означает, что вы сами рассылаете спам: адрес мог унаследовать «грязную» репутацию от предыдущего арендатора VPS, попасть в список из-за скомпрометированного веб-форума на том же IP или из-за массовой жалобы на транзакционные письма без корректного unsubscribe.

Что проверяет инструмент

Введите IP-адрес (например, 203.0.113.10) или домен (mail.example.com). Сервис последовательно опрашивает 50–100 основных DNSBL (Spamhaus, Barracuda, SURBL и др.) и показывает прогресс в реальном времени:

  • в каких списках адрес числится или отсутствует;
  • код ответа DNSBL и ссылку на описание конкретного списка;
  • сводку: есть ли критичные попадания, требующие немедленного внимания.

Что делать при обнаружении в списке

  1. Убедитесь, что проверяете правильный IP — тот, с которого реально уходит SMTP (не внутренний NAT и не IP веб-сервера, если почта идёт через отдельный relay).
  2. Устраните причину — закройте открытый relay, обновите CMS, проверьте учётные записи SMTP, настройте rate limiting и корректный bounce handling.
  3. Подайте заявку на делистинг по инструкции конкретного списка (у Spamhaus, Barracuda и других свои формы и сроки).
  4. Повторите проверку через 24–72 часа: обновление DNSBL не мгновенное.

Для менеджера

Если «письма не доходят» и техподдержка провайдера просит «проверить репутацию IP» — начните с RBL-проверки. Это быстрее, чем разбирать SPF/DKIM вслепую, и сразу показывает, блокирует ли кто-то ваш адрес на входе.

PTR (обратный DNS)

PTR (pointer record) — DNS-запись, которая связывает IP-адрес с именем хоста. Для почты это называют обратным DNS (reverse DNS): по IP 203.0.113.10 должно резолвиться осмысленное имя вроде mail.example.com, а не автоматическое ip-10-0-0-1.provider.net.

Зачем это нужно получателям

Почтовые серверы крупных провайдеров используют PTR как один из сигналов легитимности отправителя:

Проверка Смысл
PTR существует У IP есть «владелец» с осмысленным DNS-именем
PTR указывает на домен отправителя Сервер, с которого идёт SMTP, связан с доменом в From:
FCrdNS (forward-confirmed reverse DNS) Имя из PTR при прямом запросе (A/AAAA) снова возвращает тот же IP

FCrdNS — ключевой момент: недостаточно просто «любой» PTR. Имя random123.hosting.com формально есть, но если оно не совпадает с доменом в заголовках письма и не подтверждается прямым DNS — фильтр может понизить репутацию или отклонить соединение.

Типичные проблемы

  • Общий PTR хостинга — vps12345.provider.ru вместо mail.yourcompany.com. Часто встречается на дешёвых VPS и shared-хостинге.
  • Несовпадение HELO/EHLO и PTR — SMTP-сервер представляется одним именем, а PTR указывает на другое.
  • PTR есть, A-записи нет — обратный DNS не подтверждается прямым; FCrdNS не выполняется.
  • Почта через сторонний ESP — PTR настраивает провайдер рассылки (SendGrid, Amazon SES и т.д.), а не ваш DNS. В этом случае проверяйте IP их исходящих серверов, а не IP вашего сайта.

Что проверяет инструмент

Укажите IP сервера отправки. Инструмент:

  • находит PTR-запись и показывает связанное имя хоста;
  • проверяет прямой DNS (A/AAAA) для этого имени;
  • оценивает согласованность FCrdNS и даёт рекомендации при расхождениях.

PTR настраивается у владельца IP (хостинг, облако, провайдер) — не в панели DNS домена. Если запись неверная, обращайтесь в поддержку хостинга с просьбой установить mail.example.com для вашего исходящего IP.

MTA-STS и TLS-RPT

Два связанных механизма, которые повышают безопасность SMTP-соединений между почтовыми серверами: первый требует шифрование, второй сообщает о сбоях шифрования.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS — политика домена, которая говорит принимающим серверам: «для моего домена доставляйте почту только по зашифрованному TLS». Без MTA-STS SMTP традиционно допускает опportunistic TLS — сервер пытается включить шифрование, но при ошибке сертификата или downgrade-атаке может продолжить в открытом виде.

Политика публикуется в двух местах:

Компонент Где находится Что содержит
DNS-запись _mta-sts TXT в DNS домена Версия, режим (none / testing / enforce), адрес HTTPS-файла политики
Файл политики https://mta-sts.example.com/.well-known/mta-sts.txt Список MX-хостов, срок действия (max_age), режим enforce

Режим enforce — строгий: если TLS не удалось установить корректно, письмо не должно доставляться в открытом виде. Режим testing — мониторинг без блокировки; none — политика отключена.

TLS-RPT (TLS Reporting)

TLS-RPT — DNS TXT-запись _smtp._tls, которая указывает адрес (обычно mailto:), куда принимающие серверы присылают агрегированные отчёты о проблемах с TLS при доставке на ваш домен: неверный сертификат, несовместимые шифры, попытки доставки без шифрования при включённом MTA-STS.

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

Зачем настраивать

  • Защита от перехвата писем на транзите между MTA.
  • Соответствие корпоративным требованиям к шифрованию каналов связи.
  • Раннее обнаружение misconfiguration после миграции MX или обновления сертификатов.

MTA-STS и TLS-RPT не заменяют SPF, DKIM и DMARC — они решают другую задачу: безопасность транспорта, а не подлинность отправителя.

Что проверяет инструмент

Для указанного домена инструмент проверяет:

  • наличие и синтаксис DNS TXT-записи _mta-sts;
  • доступность HTTPS-файла политики и соответствие его содержимого;
  • наличие записи _smtp._tls (TLS-RPT) и корректность адреса отчётов;
  • типичные ошибки: просроченный max_age, несовпадение MX в политике с реальными MX, недоступный HTTPS.

BIMI

BIMI (Brand Indicators for Message Identification) — стандарт отображения логотипа бренда рядом с письмом в почтовых клиентах, которые его поддерживают (Yahoo, Apple Mail и др.). Получатель видит знакомую иконку вместо безликой буквы-аватара — это повышает узнаваемость и доверие к письму.

Что нужно для работы BIMI

BIMI строится поверх уже настроенной аутентификации домена. Минимальные требования:

Требование Зачем
DMARC с политикой p=quarantine или p=reject Доказать, что домен защищён от подделки — без этого клиенты не покажут логотип
BIMI TXT-запись в DNS (default._bimi) Указать URL логотипа в формате SVG Tiny P/S
VMC (Verified Mark Certificate) Обязателен в ряде клиентов (включая Yahoo); подтверждает право на торговую марку

Логотип — SVG Tiny P/S (строго ограниченный профиль SVG), обычно квадратный, с прозрачным или однотонным фоном. Растровые PNG/JPEG в BIMI не используются.

Что BIMI не делает

  • Не заменяет DMARC — наоборот, требует его.
  • Не гарантирует инбокс — влияет на отображение, а не на спам-скоринг напрямую.
  • Не работает везде — поддержка зависит от почтового клиента; в неподдерживающих BIMI просто игнорируется.

Что проверяет инструмент

Инструмент анализирует готовность домена к BIMI:

  • наличие и синтаксис BIMI TXT-записи (default._bimi);
  • доступность SVG-логотипа по указанному URL;
  • состояние DMARC (политика не ниже quarantine);
  • наличие VMC в записи, если требуется для целевых клиентов;
  • типичные ошибки: неверный формат SVG, недоступный HTTPS, DMARC в режиме p=none.

Для менеджера

BIMI — «вишенка на торте» после SPF, DKIM и DMARC. Если аутентификация ещё не настроена, начните с инструментов SPF/DKIM/DMARC; BIMI имеет смысл, когда транзакционная и маркетинговая почта уже стабильно проходит проверки.

Связь с Mailexam®

Задача Инструмент Основной продукт
Тестировать шаблоны и логику отправки в разработке — Sandbox + примеры интеграции
Проверить HTML/CSS в разных почтовых клиентах — Проверка совместимости
Настроить DNS перед продакшен-рассылкой Инструменты (эта страница) —
Автоматизировать проверку писем в CI/CD — REST API · CLI

Дальше по теме