Диагностика почтового сервера: инструменты и методы тестирования | AdminWiki
Logo

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

27 августа 2026 8 мин. чтения
Содержание статьи

Быстрый старт: проверка SMTP-сервера через telnet

Проверка почтового сервера начинается с базового теста SMTP-сессии. Если сервер принимает команды и отвечает кодами 250, ядро работает. Если соединение сбрасывается или возвращает 550, проблема локализована. Ниже разберем два способа: классический telnet и утилиту swaks для расширенной диагностики.

Пошаговая отправка тестового письма через telnet

Подключитесь к порту 25 или 587. Для теста без шифрования используйте порт 25, для проверки с TLS потребуется openssl. Базовая сессия выглядит так:

telnet mail.example.com 25
HELO test.example.org
MAIL FROM: <sender@example.org>
RCPT TO: <recipient@example.com>
DATA
Subject: Test message

This is a test body.
.
QUIT

Сервер отвечает кодами. Код 250 означает успешное выполнение команды. Код 550 указывает на отказ, например, при попытке отправить письмо на несуществующий ящик. Код 530 сигнализирует о требовании аутентификации. Если после MAIL FROM вы получаете 550 relay not permitted, сервер настроен как закрытый релей, и отправка без авторизации невозможна.

Для проверки TLS-соединения используйте openssl:

openssl s_client -starttls smtp -connect mail.example.com:587

После установки защищенного канала выполните те же команды SMTP. Если сертификат невалиден или протокол не поддерживается, openssl выведет ошибку до начала SMTP-диалога.

Использование swaks для расширенной диагностики

Swaks автоматизирует тестовые сценарии и поддерживает аутентификацию, TLS и нестандартные порты. Установка на Debian/Ubuntu: apt install swaks. На CentOS/RHEL: yum install swaks или через CPAN.

Базовая проверка с аутентификацией:

swaks --to recipient@example.com --from sender@example.org --server mail.example.com --port 587 --auth LOGIN --auth-user user@example.org --auth-password 'password' --tls

Swaks выводит весь SMTP-диалог с кодами ответов. Флаг --tls включает обязательный TLS, --tls-optional разрешает fallback. Для проверки конкретного получателя без реальной отправки используйте --quit-after RCPT. Это проверит, принимает ли сервер адрес, не отправляя письмо.

Проверка скорости ответа сервера:

swaks --to test@example.com --server mail.example.com --timeout 10

Если сервер не отвечает за 10 секунд, проблема в сети или перегрузке. Подробнее о типичных ошибках подключения читайте в руководстве по диагностике ошибок почтового сервера.

Проверка DNS-записей: SPF, DKIM, DMARC

Корректные DNS-записи определяют, попадет ли письмо во входящие или в спам. Проверка выполняется командами dig или nslookup. Начните с базовой записи MX, затем переходите к аутентификационным.

SPF: проверка и типичные ошибки

SPF-запись публикуется в TXT-записи домена. Проверка:

dig TXT example.com +short

Ищите строку, начинающуюся с v=spf1. Типичная корректная запись:

v=spf1 mx a ip4:203.0.113.10 include:_spf.google.com ~all

Механизмы: mx разрешает отправку с серверов из MX-записи, a с A-записи домена, ip4 с конкретного IP, include подключает сторонние домены. Квалификаторы: -all жесткий запрет, ~all мягкий запрет, ?all нейтральный.

Типичная ошибка: превышение лимита DNS-запросов. SPF допускает максимум 10 DNS-запросов на проверку. Каждый include, a, mx и ptr генерирует запрос. Если лимит превышен, проверка возвращает permerror, и письмо может быть отклонено. Проверяйте количество запросов через MXToolbox или dig +trace.

DKIM: проверка подписи и селектора

DKIM-запись публикуется в поддомене selector._domainkey.example.com. Селектор указывается в заголовке DKIM-Signature подписанного письма. Если вы не знаете селектор, проверьте заголовок любого отправленного письма или документацию почтового сервера.

Проверка записи:

dig TXT default._domainkey.example.com +short

Запись содержит публичный ключ в формате v=DKIM1; k=rsa; p=MIGfMA0G.... Если запись отсутствует, подпись не пройдет проверку. Если ключ слишком короткий (менее 1024 бит), некоторые провайдеры отклоняют подпись.

Проверка подписи на реальном письме выполняется через онлайн-сервисы или локально через opendkim-testmsg. Для быстрой проверки отправьте письмо на адрес Mail-Tester, он покажет статус DKIM.

DMARC: политика и отчеты

DMARC-запись публикуется в _dmarc.example.com:

dig TXT _dmarc.example.com +short

Типичная запись:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100

Тег p задает политику: none только мониторинг, quarantine помещение в спам, reject отклонение. Тег rua указывает адрес для агрегированных отчетов. Начинайте с p=none, анализируйте отчеты 2-4 недели, затем ужесточайте политику. Подробная стратегия внедрения описана в руководстве по настройке DNS-записей почтового сервера.

Анализ репутации IP и домена

Репутация IP определяет, примут ли письмо крупные провайдеры. Даже корректные SPF и DKIM не спасут, если IP находится в черных списках.

Проверка черных списков (DNSBL)

Основные черные списки: Spamhaus Zen, Barracuda, SORBS, SpamCop. Проверка через MXToolbox Blacklist Check автоматически опрашивает более 100 DNSBL. Локальная проверка через dig:

dig +short 10.113.0.203.zen.spamhaus.org

IP записывается в обратном порядке. Если команда возвращает 127.0.0.x, IP в списке. Код ответа указывает категорию: 127.0.0.2 SBL, 127.0.0.3 CSS, 127.0.0.4 XBL. Если ответ пустой, IP чист.

При попадании в список запросите удаление на сайте оператора. Spamhaus предоставляет форму для делистинга после устранения причины. Barracuda требует регистрацию и подтверждение исправления. Удаление обычно занимает от нескольких часов до суток.

Оценка репутации отправителя с помощью Google Postmaster Tools

Google Postmaster Tools показывает метрики доставляемости на ящики Gmail. Регистрация требует подтверждения владения доменом через DNS TXT-запись. После верификации доступны метрики:

  • Spam rate - процент писем, помеченных как спам получателями. Допустимый уровень ниже 0.1%.
  • IP reputation - оценка репутации отправляющих IP: Bad, Low, Medium, High.
  • Feedback loop - жалобы получателей на спам.
  • Delivery errors - ошибки доставки с разбивкой по причинам.

Если spam rate превышает 0.3%, проверьте качество рассылок и сегментацию. Если IP reputation держится на Bad более недели, замените IP или пересмотрите контент. Для писем, застревающих в очереди Gmail, изучите материал о причинах задержки писем в Gmail.

Тестирование доставляемости писем

Доставляемость проверяется отправкой реальных писем на тестовые ящики. Это выявляет проблемы, которые не видны при локальной проверке DNS.

Mail-Tester: быстрая оценка письма

Mail-Tester выдает случайный адрес вида test-abc123@srv1.mail-tester.com. Отправьте на него письмо с вашего сервера, затем откройте страницу с результатом. Сервис оценивает:

  • SPF, DKIM, DMARC - проходят ли проверки
  • Контент - нет ли спам-слов и битых ссылок
  • Репутация IP - не в черных ли списках
  • Формат письма - корректность заголовков и MIME

Оценка 10/10 означает, что письмо пройдет большинство фильтров. Оценка ниже 7 требует исправления проблем. Сервис показывает детальный разбор каждого пункта с указанием, что именно не так.

Seed-аккаунты для постоянного мониторинга

Создайте тестовые ящики на Gmail, Yandex, Mail.ru и Outlook. Настройте автоматическую отправку тестового письма на все адреса раз в сутки. Проверяйте папку «Спам» вручную или через IMAP-скрипт.

Автоматизация на Python:

import imaplib
import email

mail = imaplib.IMAP4_SSL('imap.gmail.com')
mail.login('seed@example.com', 'password')
mail.select('INBOX')
result, data = mail.search(None, 'FROM', 'sender@example.org')
if data[0]:
    print('Письмо во входящих')
else:
    mail.select('Spam')
    result, data = mail.search(None, 'FROM', 'sender@example.org')
    if data[0]:
        print('Письмо в спаме')
    else:
        print('Письмо не доставлено')

Запускайте скрипт после каждой тестовой отправки. Накопленная статистика за месяц покажет тренд доставляемости по каждому провайдеру.

Чтение заголовков письма для диагностики

Заголовки письма содержат полный путь прохождения и результаты аутентификации. Умение их читать сокращает время поиска проблемы с часов до минут.

Ключевые заголовки и их значение

Основные заголовки для диагностики:

  • Received - каждая строка показывает один hop. Читайте снизу вверх: первая строка снизу - отправитель, верхняя - получатель. Время и IP каждого сервера видны в квадратных скобках.
  • Authentication-Results - итоги проверок SPF, DKIM, DMARC. Записывается принимающим сервером. spf=pass, dkim=pass, dmarc=pass означают успешную аутентификацию.
  • DKIM-Signature - параметры подписи: селектор (s=), домен (d=), алгоритм (a=).
  • Return-Path - адрес для bounce-сообщений. Должен совпадать с доменом отправителя или быть поддоменом.
  • Message-ID - уникальный идентификатор. По нему можно найти письмо в логах сервера.

Просмотр заголовков: в Gmail «Показать оригинал», в Outlook «Свойства» → «Заголовки Интернета», в Thunderbird Ctrl+U.

Практический пример анализа заголовков

Письмо попало в спам Gmail. Разбор заголовков:

Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning sender@example.org does not designate 203.0.113.10 as permitted sender) smtp.mailfrom=sender@example.org;
       dkim=pass header.i=@example.org;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org

SPF вернул softfail: IP 203.0.113.10 не указан в SPF-записи домена example.org. DKIM и DMARC прошли. Gmail учитывает softfail как слабый сигнал и может поместить письмо в спам. Решение: добавить IP в SPF-запись или изменить ~all на -all после проверки всех легитимных источников.

Другой пример:

Received: from unknown (HELO localhost) (192.168.1.5)
  by mail.example.com with SMTP; 27 Aug 2026 10:00:00 +0000

HELO localhost и отсутствие PTR-записи для 192.168.1.5 вызывают недоверие принимающих серверов. Настройте HELO на полное доменное имя и создайте PTR-запись у провайдера.

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

Производительность почтового сервера проверяется нагрузочным тестированием и мониторингом очередей. Это выявляет узкие места до того, как они станут проблемой.

Нагрузочное тестирование SMTP

Утилита smtp-source входит в состав Postfix. Она генерирует параллельные SMTP-сессии и измеряет пропускную способность:

smtp-source -s 20 -l 5120 -m 1000 -c -f sender@example.org -t recipient@example.com mail.example.com:25

Параметры: -s 20 - 20 параллельных сессий, -l 5120 - размер письма 5 КБ, -m 1000 - 1000 писем, -c - отображать счетчик. Результат показывает количество писем в секунду. Для среднего сервера нормой считается 50-200 писем/сек в зависимости от железа.

Если пропускная способность падает при увеличении параллельных сессий, проверьте лимиты: ulimit -n для файловых дескрипторов, smtpd_client_connection_count_limit в Postfix, параметры ядра net.core.somaxconn.

Мониторинг очередей и логов

Просмотр очереди Postfix:

postqueue -p

Команда показывает все письма в очереди с ID, размером, временем и причиной задержки. Если очередь растет быстрее, чем обрабатывается, найдите причину в логах:

tail -f /var/log/mail.log | grep -E 'deferred|bounced|error'

Анализ распределения очереди:

qshape deferred

Qshape показывает, сколько писем ожидают доставки и на какие домены. Большое скопление на одном домене указывает на проблемы у получателя или блокировку с его стороны. Подробнее о работе с очередями читайте в статье о диагностике очереди писем.

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

Большинство проблем с доставляемостью вызвано пятью ошибками конфигурации. Проверьте каждый пункт перед глубокой диагностикой.

Ошибки конфигурации, приводящие к блокировкам

Отсутствие PTR-записи. Принимающие серверы проверяют обратную DNS-запись IP. Если PTR отсутствует или не совпадает с HELO, письмо отклоняется или помечается спамом. Проверка: dig -x 203.0.113.10 +short. Запись должна возвращать полное доменное имя сервера.

Неправильный HELO. Сервер должен представляться полным доменным именем, которое резолвится в тот же IP. HELO localhost или IP-адрес вызывает недоверие. Проверьте myhostname в main.cf Postfix или primary_hostname в Exim.

Открытый релей. Сервер, принимающий почту для чужих доменов без аутентификации, быстро попадает в черные списки. Проверка: telnet mail.example.com 25, затем RCPT TO: <test@gmail.com> без аутентификации. Если сервер отвечает 250, релей открыт. Настройте smtpd_recipient_restrictions на отклонение внешних получателей.

Отсутствие SPF/DKIM/DMARC. Письма без аутентификации получают штрафные баллы в спам-фильтрах. Настройте все три записи, начиная с SPF.

Проблемы с TLS и безопасностью

Проверка сертификата:

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com | openssl x509 -noout -dates -subject

Сертификат должен быть валидным, не истекшим и выпущенным для домена сервера. Самоподписанные сертификаты вызывают ошибки у принимающих серверов при проверке TLS.

Поддержка современных протоколов: TLS 1.2 и 1.3 обязательны. TLS 1.0 и 1.1 отключены большинством провайдеров с 2020 года. Проверьте конфигурацию Postfix: smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1.

MTA-STS публикует политику TLS через DNS и HTTPS. Запись _mta-sts.example.com TXT и файл политики на https://mta-sts.example.com/.well-known/mta-sts.txt сообщают принимающим серверам, что TLS обязателен. Это снижает риск downgrade-атак и повышает доверие к домену.

Для комплексной настройки почтовой инфраструктуры с нуля изучите руководство по протоколам SMTP, IMAP и POP3. Если вы разворачиваете сервер на облачной инфраструктуре, Timeweb Cloud предоставляет VDS с подходящими для почтовых серверов конфигурациями.

Поделиться:
Сохранить гайд? В закладки браузера