Один честный тест говорит о доставляемости больше, чем неделя споров. Сервис mail-tester устроен как чистый эксперимент: страница выдаёт одноразовый адрес, на него отправляется письмо, и через несколько секунд появляется оценка от нуля до десяти с подробным разбором каждого замечания. Десятка не медаль, а рабочий сигнал: письмо с такой оценкой проходит фильтры крупных провайдеров без технических возражений. Ниже разбор всех групп проверок и путь от типичных шести баллов свежего сервера к стабильной десятке.
Как устроена проверка одного письма в сервисе
Механика проста до неприличия. Открыта страница, получен уникальный адрес, на него уходит ровно одно письмо, и отчёт собирается автоматически. Адрес живёт ограниченное время, поэтому каждый новый тест начинается с чистого листа, а повторная проверка после правок сравнивается с предыдущей по одинаковой шкале.
Отчёт сгруппирован по темам: аутентификация отправителя, состояние инфраструктуры домена и адреса, наличие сервера в публичных списках блокировок, разбор содержимого письма правилами антиспам-движка. Каждая группа разворачивается в список конкретных проверок с пояснениями, поэтому отчёт читается как маршрут: что уже зелёное, что жёлтое и за что сняты баллы.
Единая шкала удобна и в команде. Администратор показывает руководству одну цифру вместо лекции про DNS, разработчик шаблонов писем видит влияние вёрстки на оценку, а разница между вчерашними семью и сегодняшними девятью баллами говорит больше, чем любые обещания. По сути, сервис заменяет спор измерением.
У эксперимента есть границы, и честный обзор их называет: оценивается одно письмо, а не история домена. Поведение получателей, жалобы и накопленная репутация остаются за кадром. Десятка снимает технические причины попадания в спам, но не заменяет аккуратную работу с аудиторией, и именно поэтому разумные команды прогоняют тест регулярно, а не один раз навсегда.
Встраивается проверка куда угодно, потому что не требует ничего, кроме письма. Разработчик шаблона отправляет черновик до финальной вёрстки, администратор гоняет тест после каждого изменения DNS, а перед большой рассылкой оба результата сверяются. Единственное, что требует дисциплины, отправлять на одноразовый адрес именно то письмо, которое пойдёт людям: с теми же заголовками, тем же весом и той же вёрсткой.
Для команд, отправляющих транзакционные письма из продукта, у теста есть отдельная роль: письмо из веб-формы и письмо из почтового клиента проходят фильтры по-разному, и проверять стоит оба варианта. Продуктовая отправка часто едет со своей парой заголовков и со своего адреса, и её замечания отличаются от замечаний писем, написанных человеком.
Обратная зона PTR и MX записи, которые проверяются первыми
Первое, что видит приёмный сервер, не письмо, а адрес и имя. Обратная зона PTR превращает адрес в имя узла, и крупные провайдеры сверяют его с тем, как сервер представляется в команде HELO. Несоответствие здесь первый минус и частая причина, по которой свежий VPS стартует с обидной оценки: у многих хостеров обратная зона по умолчанию не прописана вовсе.
Проверяется всё тремя командами:
dig +short -x 203.0.113.10
dig +short MX example.com
dig +short A mail.example.comПервая показывает, какое имя отвечает адресу сервера, вторая и третья смотрят, куда указывает домен. Идеальная картина: PTR и HELO называют один и тот же узел, MX домена указывает на него же, и у имени есть прямая запись A. Лечится несоответствие у хостера: запрос в поддержку с просьбой прописать обратную зону закрывает вопрос за минуты или часы, в зависимости от расторопности смены.
Свою лепту вносит и сам сервер. Postfix по умолчанию иногда представляется именем localhost, и это правится одной строкой в main.cf:
myhostname = mail.example.comСтрока отправных записей закрывает большинство претензий группы инфраструктуры, и дальше в неё заглядывают только при переезде на новый адрес.
Если сервер умеет IPv6, картина удваивается: у адреса шестой версии своя обратная зона, и приёмная сторона проверяет обе параллельно. Работающий канал без обратной записи иногда приносит минус, который не виден в мире четвёртой версии, и в отчёте он находится быстрее, чем в журналах сервера. Дешёвое решение на время настройки закрыть шестую версию вовсе, честное дособрать записи до полной симметрии.
Аутентификация отправителя SPF, DKIM и DMARC в оценке сервиса
Три записи домена отвечают на вопрос, имеет ли письмо право называться письмом домена. SPF перечисляет адреса, которым разрешена отправка. DKIM подписывает письмо приватным ключом, публичная часть лежит в DNS. DMARC связывает обе проверки правилом и адресом для отчётов. Сервис честно показывает отсутствие любой из трёх частей отдельным замечанием, и три минуса в сумме легко утаскивают оценку на два-три балла вниз.
Проверяются записи всё тем же dig:
dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.comОтвет первой команды обязан содержать ровно одну строку v=spf1, второй отдаёт ключ целиком без разрывов, третьей отвечает правилом с адресом отчётов. Сервис повторяет то же человеческим языком, но привычка сверять записи руками экономит прыжки между панелями.
Подпись DKIM включается на самом сервере: утилиты генерации есть и в Rspamd, и в классическом OpenDKIM, ключ публикуется под выбранным селектором, и дальше подпись ставится на каждое исходящее письмо автоматически. Проверить её наличие глазами просто: в служебных заголовках письма ищется строка dkim-signature, а фильтры приёмной стороны отвечают строкой dkim=pass.
Про селектор ключа уместно сказать отдельно: слово перед _domainkey выбирается при генерации, и в DNS запись публикуется именно под ним. Расхождение селектора в подписи и в DNS выглядит как отсутствие подписи, хотя ключ цел, и разбор сервиса находит причину мгновенно.
Частые провалы выглядят одинаково у всех: две записи SPF у домена, когда панель регистратора хранит старую и новую строки; ключ DKIM, разорванный переносами при вставке; DMARC, опубликованный у основного домена, когда письма уходят с поддомена. Каждая ошибка чинится за минуты, а без проверки висит месяцами.
Правило DMARC разумно стартует в режиме наблюдения: p=none собирает отчёты, ничего не блокируя, и пара недель чтения показывает всех легитимных отправителей домена, включая забытые сервисы рассылок. Ужесточение до quarantine и reject делается по чистым отчётам, и к моменту перехода сюрпризов не остаётся. Сервис проверки фиксирует результат каждого шага своей цифрой, и движение видно даже сквозь жаргон DNS.
Черные списки адресов и репутация сервера отправки
Публичные списки блокировок ведут сообщества и сервисы, и попадание в них арифметически бьёт по оценке сильнее остального. Свежий VPS нередко получает в наследство адрес с прошлой биографией, и первое письмо огребает блокировку, о которой владелец даже не подозревал: до теста повода посмотреть списки просто не было.
Отчёт перечисляет списки, в которых найден адрес, и это готовый план. Процедура вывода у каждого списка своя: где-то форма с объяснением, где-то автоматическое удаление по таймеру, где-то переписка с модераторами. Общая логика одна: сначала устраняется причина, из-за которой адрес попал в список, потом подаётся заявка, иначе адрес вернётся туда же.
Списки различаются строгостью и сегментом: одни собирают адреса прямых спамерских сетей, другие тех, кто ведёт себя подозрительно, и попадание в жёсткий из них закрывает дорогу сразу нескольким крупным провайдерам. Поэтому мониторинг по основным спискам входит в регулярный осмотр сервера наравне с диском и памятью.
Профилактика скучнее лечения и результативнее. Новый адрес греется скромными объёмами, рассылки не стартуют с полной мощности, а любое резкое изменение трафика воспринимается фильтрами как подозрение. Чистая история адреса это актив, и обходиться с ним стоит бережно.
Читая отчёт по спискам, полезно понимать их специализацию: одни каталогизируют сети, замеченные в прямых рассылках, другие реагируют на жалобы, третьи собирают узлы с подозрительными настройками. Адрес в узком списке может почти не влиять на крупных провайдеров и наоборот, поэтому срочность вывода оценивается по тому, кто именно из приёмной стороны на список смотрит.
Содержимое письма, заголовки и баланс текста с разметкой
Техническая начинка письма даёт мелкие, но решающие минусы. Заголовок Message-ID обязан быть уникальным, Date свежим и совпадающим с реальностью, у рассылок нужен работающий механизм отписки:
List-Unsubscribe: <mailto:Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. >Отсутствие любого из них помечается как замечание, и на финише, когда инфраструктура зелёная, именно эти мелочи стоят между восемью и десятью баллами.
Вёрстка оценивается балансом. Письмо одной картинкой без текста это классический минус: фильтры не видят содержания, а разбор показывает пустой текстовый дубликат. Alt-описания у изображений, честная текстовая копия, скромный вес и отсутствие вложений-сюрпризов делают содержимое читаемым и для людей, и для машин.
Ссылки читаются на достоверность: полные адреса своего домена, никаких сокращателей и цепочек пересылок, видимый текст ссылки совпадает с адресом под ним. Тема без капса и восклицательных знаков завершает картину. По сути, всё содержимое сводится к простому правилу: письмо, которое не пытается никого обмануть, проходит проверку на содержимое без волнений.
Вес письма и кодировка добирают остаток придирок. Мегабайтные вложения, самоподписанные сертификаты в ссылках и экзотические кодировки в теме дают мелкие минусы, собирающиеся в заметную сумму. Деловое письмо спокойно живёт в пределах пары сотен килобайтов, и если оно весит заметно больше, стоит спросить себя, что именно в нём лишнее.
Отдельная строка разбора касается баланса текста и разметки: процент текстовой версии, соотношение ссылок и слов, наличие обоих представлений. Правило практичное: если текстовую копию нечего читать, письмо ещё не готово, потому что часть получателей читает именно её, а фильтры недоверчивы к разметке без текста.
Пошаговый путь от шести баллов к десяти на своём сервере
Типичный старт честного, но не настроенного VPS: пять-шесть баллов. Обратной зоны нет, DMARC не опубликован, заголовки неполные. Порядок действий по убыванию веса замечаний выглядит так:
- запрашивается обратная зона PTR у хостера и сверяется с HELO сервера;
- публикуются записи SPF DKIM и DMARC, ошибки устраняются по разбору сервиса;
- адрес проверяется по блокировочным спискам, при попадании выводится по правилам списка;
- чистятся заголовки и вёрстка письма до зелёных отметок во всех группах отчёта.
Первая десятка не финиш, а точка отсчёта. Дальше любое изменение: переезд на новый адрес, смена шаблона писем, подключение сервиса рассылки - повод прогнать тест заново, потому что каждый элемент по отдельности зелёный не гарантирует десятку в сборе. Проверка перед важной отправкой занимает пять минут и снимает лотерею.
Пара слов про сравнение результатов. Оценка между запусками имеет смысл только при прочих равных: то же письмо, тот же адрес, тот же домен. Изменённый шаблон с падением на два балла говорит о вёрстке, а не о репутации, и поиск причины по свежему отчёту занимает минуты. Ошибкой была бы погоня за десяткой правкой сразу всего: разбор теряет причинность, и непонятно, что именно помогло.
Десятка на сервисе проверки писем это дисциплина, переведённая в цифру. Обратная зона, три записи аутентификации, чистый адрес и аккуратная вёрстка складываются в предсказуемую доставляемость, а разбор замечаний делает дорогу короткой и понятной. Команда, которая привыкла проверять себя перед каждой рассылкой, не надеется на удачу, потому что в удачу при таком подходе просто не нуждается. А начать стоит прямо сегодня: одноразовый адрес, одно письмо и пятнадцать минут чтения разбора дают больше, чем месяц теоретических споров о том, куда деваются письма.