Почему здоровье домена — это важно

Когда команды говорят «домен здоров», они обычно имеют в виду «сайт вернул 200 в последний раз, когда кто-то проверял». Это один сигнал из как минимум пяти — а другие четыре вызывают больше простоев, больше потерь выручки и больше ущерба доверию клиентов, чем тот единственный, за которым все следят.

Домен здоров, когда он доступен, защищён, аутентифицирован, репутабелен и наблюдаем. SEO зависит от этого (Google штрафует mixed content, истёкшие сертификаты и медленный TTFB). Доставляемость зависит от этого (Gmail и Yahoo теперь отбрасывают почту от рассинхронизированных доменов у массовых отправителей). Безопасность зависит от этого (висящий CNAME — это ждущая своего часа атака на поддомен). И доверие клиентов зависит от этого (предупреждение браузера в момент ввода кредитки — это убитая конверсия и инициированный возврат).

Этот гайд — 5-минутный аудит. К концу вы будете точно знать, какой из пяти столпов прямо сейчас тихо проседает на вашем домене, какой командой это подтвердить и каким бесплатным инструментом Nova Uptime это починить. Без воды и маркетинга — только тот аудит, который провёл бы senior SRE, если бы вы дали ему домен и спросили: «эта штука в порядке?»

5 столпов здоровья домена#

Прежде чем идти столп за столпом — ментальная модель. Здоровый домен проходит все пять проверок. Большинство production-доменов проваливают хотя бы одну — и команда обычно об этом не знает, пока сбой не превратится в клиентский тикет.

Столп 1: Конфигурация DNS — A, AAAA, MX, CNAME, TXT, DNSSEC. Все ли записи на месте, корректны и указывают куда надо?
Столп 2: SSL/TLS-сертификаты — окно валидности, целостность цепочки, покрытие SAN, сила шифров, HSTS. Доверится ли каждый браузер сертификату сегодня и через 60 дней?
Столп 3: Email-аутентификация — SPF, DKIM, DMARC, alignment. Могут ли атакующие подделывать ваш домен? Доходят ли легитимные письма до inbox или падают в спам?
Столп 4: Репутация — листинги в DNSBL: Spamhaus, Barracuda, SORBS, SpamCop. Не находится ли ваш отправляющий IP или домен в блок-листе, который тихо губит доставляемость?
Столп 5: Uptime и производительность — HTTP-статусы, перцентили времени ответа, мульти-региональная доступность, истечение домена, возраст регистрации. Сайт реально работает, быстр и не истекает в следующий вторник?

У каждого столпа есть 30-секундная проверка из терминала, более глубокая инспекция через бесплатный инструмент Nova Uptime и постоянный монитор, который можно настроить, чтобы получать алерт до следующего сбоя.

Столп 1: Конфигурация DNS#

DNS — фундамент. Если DNS неправильный, остальные четыре столпа не имеют значения — запрос не дойдёт до сервера.

Записи, которые имеют значение

A-записи мапят hostname в IPv4. У каждого домена должна быть как минимум одна для apex и одна для www.
AAAA-записи мапят hostname в IPv6. Большинство команд их пропускают. И зря. IPv6-трафик уже регулярно даёт 30–40% мобильного трафика на крупных рынках, и отсутствующая AAAA-запись заставляет откатываться на IPv4 — добавляя задержку и, в плохо настроенных сетях операторов, эпизодические сбои.
MX-записи определяют маршрутизацию почты. Несколько MX-записей используют значения priority (меньше = предпочтительнее). Самый частый MX-баг, который мы видим — MX-запись с приоритетом 0, указывающая на сам apex-домен, когда у apex нет SMTP-слушателя — почта тихо отбивается.
CNAME-записи — это алиасы. Опасность — висящие CNAME: CNAME, указывающий на сервис, которым вы больше не пользуетесь (заброшенный S3-bucket, старое Heroku-приложение, отключённый Zendesk). Атакующий, заявивший права на этот ресурс у upstream-провайдера, забирает ваш поддомен.
TXT-записи несут верификации, SPF, DMARC, токены подтверждения владения. Их нужно периодически аудитить — старые верификации от сервисов, которыми вы больше не пользуетесь, мусорят зону и увеличивают счётчик SPF-lookup.
DNSSEC добавляет криптографическую цепочку доверия к DNS-ответам. Защищает от cache poisoning и DNS-hijacking. Не строго обязателен, но для любого домена, обрабатывающего деньги, учётные данные или медицинские данные — рекомендуется.

Быстрые проверки

dig +short A yourdomain.com
dig +short AAAA yourdomain.com
dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig DNSKEY yourdomain.com +short

Для MX-валидации запустите email health-чекер Nova Uptime — он подтверждает MX-записи, приоритеты и резолвит каждый MX-hostname в IP.

Столп 2: SSL/TLS-сертификаты#

Работающий сертификат — недостаточно. У SSL-сертификата шесть независимых вещей, которые могут пойти не так, и большинство мониторингов проверяет ровно одну — дату истечения.

Что проверять

notBefore и notAfter определяют окно валидности. С 90-дневным циклом Let's Encrypt и индустриальным курсом на 47-дневные сертификаты к 2028 году истечение происходит быстро и тихо. Знать нужно за 30 дней.
Целостность цепочки issuer. Сертификат, отдаваемый сервером, должен включать промежуточные сертификаты, связывающие его с доверенным корнем. Сертификат валидируется в Chrome (он кэширует промежуточные), но ломается в старом Safari, на iOS или в headless-инструментах, не докачивающих недостающие промежуточные. Это самый частый SSL-баг класса «но в моём браузере же работает».
Покрытие SAN (Subject Alternative Name). Сертификат должен перечислять каждый hostname, который он обслуживает: apex, www и поддомены, использующие тот же сертификат. Сертификат, валидный для www.yourdomain.com, но не для голого apex — частая ошибка конфигурации.
Cipher suites и версии протокола. TLS 1.0 и 1.1 устарели. TLS 1.2 — минимум; TLS 1.3 — цель. Слабые шифры (RC4, 3DES, всё с CBC-режимом в старых конфигурациях) должны быть отключены.
HSTS-заголовок. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload говорит браузерам никогда не использовать HTTP. Без HSTS man-in-the-middle может понизить соединение при первом контакте.
OCSP stapling. Сервер прикладывает подписанное доказательство валидности сертификата к TLS-handshake, экономя round-trip к OCSP-respondеру CA. Быстрее и приватнее. Большинство современных веб-серверов это поддерживают; включено мало где.

Быстрая проверка

echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

Для постоянного мониторинга с 30-дневными алертами и валидацией цепочки — SSL-чекер Nova Uptime.

Столп 3: Email-аутентификация#

Это столп, где 2026 год изменил правила. Принуждение Gmail и Yahoo для массовых отправителей означает, что отсутствующая или несинхронизированная DMARC-запись теперь стоит вам места в inbox, а не только репутации.

SPF — кто может отправлять за ваш домен#

SPF — это TXT-запись DNS, перечисляющая IP и домены, авторизованные отправлять почту от вашего имени. Две ловушки:

Лимит в 10 DNS-запросов. Каждый include: в SPF считается. Один SendGrid — это 3 запроса; добавьте Google Workspace (3), Mailchimp (1) и транзакционного провайдера (3) — и вы за лимитом. Принимающие серверы возвращают permerror, и ваша почта проваливается.
Квалификатор +all (или его отсутствие). Финальный квалификатор (-all, ~all, ?all, +all) говорит получателям, что делать с письмами из неперечисленных источников. +all означает «любой может отправлять как я» — никогда не используйте.

Валидируйте через SPF-чекер Nova Uptime.

DKIM — криптографическая подпись#

DKIM подписывает каждое исходящее сообщение приватным ключом. Получатель достаёт публичный ключ из selector._domainkey.yourdomain.com и проверяет подпись. Две ловушки:

Путаница с селекторами. Для DKIM нет wildcard. Вам нужно знать, какой селектор использует ваш почтовый сервис (s1, google, mandrill, selector1 и т. д.). Ключ лежит по адресу {selector}._domainkey.yourdomain.com.
Ротация ключей. DKIM-ключи нужно ротировать раз в год. Большинство команд настраивают их единожды и забывают на пять лет.

Проверяйте через DKIM-чекер Nova Uptime, который автоматически сканирует 50 распространённых селекторов.

DMARC — слой политики#

DMARC говорит принимающим серверам, что делать, если SPF и DKIM провалились. Три политики:

p=none — только мониторинг, никаких действий. Используйте первые 2–4 недели, пока собираете отчёты.
p=quarantine — отправлять провалившуюся почту в спам.
p=reject — отбрасывать сразу. Это и есть цель.

Большинство доменов застревают на p=none навсегда, потому что никто не читает агрегированные (rua) отчёты. Не будьте «большинством». Пройдите наш гайд по настройке DMARC-политики и валидируйте через DMARC-чекер Nova Uptime.

Alignment — то, что все упускают#

DMARC требует, чтобы домен SPF или DKIM синхронизировался с доменом заголовка From. Сообщение может пройти SPF (для mailgun.org) и пройти DKIM (подписан mandrillapp.com), но если в From стоит you@yourdomain.com, DMARC проваливается, потому что ничего не синхронизировано. Чините настройкой кастомных return-path и DKIM signing-доменов для каждого отправляющего сервиса.

Чтобы проверить все четыре сразу — используйте email health-чекер Nova Uptime: он оценивает SPF, DKIM, DMARC и alignment вместе.

Столп 4: Репутация (блок-листы)#

Даже с идеальной аутентификацией плохая репутация отправит вас в спам. DNSBL (DNS-based blocklists) — публичные табло.

Что отслеживают DNSBL#

Одни блок-листы отслеживают IP (адрес вашего отправляющего почтового сервера). Другие — домены (URI в теле сообщения). У каждого блок-листа свои критерии листинга, но общие триггеры: попадание в spam-traps, высокая доля жалоб, резкие скачки объёма и нахождение в одном IP-блоке с известными спамерами.

Списки, которые имеют значение

Spamhaus SBL/XBL/PBL/DBL — золотой стандарт. Крупные провайдеры обращаются к Spamhaus напрямую.
Barracuda Reputation Block List — активно используется корпоративными фильтрами.
SORBS — агрегирует несколько фидов; может быть агрессивным.
SpamCop — управляется жалобами пользователей; короткие сроки листинга, но высокий объём.

Почему вы можете оказаться в списке

Четыре самых частых причины: (1) скомпрометированный аккаунт на вашей платформе разослал спам, (2) клиент в shared-IP-сетапе сделал то же, (3) вы отправили кампанию по старой неверифицированной базе, (4) ваши формы позволяют неаутентифицированную регистрацию, и боты используют вашу платформу для рассылки.

Как проверить

Используйте чекер блок-листов Nova Uptime — он опрашивает 60+ DNSBL параллельно и показывает, какие именно списки пометили ваши IP и домены, со ссылками на делистинг для каждого.

Если вы в списке — сначала чините корневую причину (закройте скомпрометированный аккаунт, чистите базу, чините форму), затем подавайте запрос на делистинг. Повторное попадание через неделю с той же первопричиной гарантирует более длительный бан.

Столп 5: Uptime и производительность#

Это столп, за которым все следят — и даже здесь большинство команд смотрит только на одну метрику.

Что измерять

HTTP-код. 200 — здоровье. 4xx — ваша проблема. 5xx — проблема сервера. 3xx-редиректы должны разрешаться в 200 за 3 хопа.
Перцентили времени ответа. Медиана (p50) — сюжет; p95 и p99 — правда. Сайт с p50=200ms и p99=9 000ms имеет серьёзную проблему, затрагивающую 1 запрос из 100 — обычно медленный SQL или холодный кэш.
Мульти-региональная доступность. Однорегиональный мониторинг ловит ваши простои. Он пропускает простои ваших клиентов — flap BGP-маршрута в Азии, региональный инцидент Cloudflare, спор провайдеров о пиринге, затрагивающий 10% ваших пользователей.
Скриншоты при сбое. Когда сайт падает, фиксируйте экран, который видит пользователь. «Сайт недоступен» выглядит одинаково для монитора, что бы это ни было — 500, страница challenge от Cloudflare или сломавшийся iframe платёжного провайдера.
Истечение домена. Домены истекают. Автопродление ломается (просроченная карта, заблокированный аккаунт регистратора, биллинговое письмо на ящик уволившегося сотрудника). Отслеживайте дату истечения у регистратора — и возраст регистрации, который сигнализирует authority для SEO.

Для постоянного мониторинга с 59-секундным интервалом, мульти-регионом, скриншотами и алертами по WhatsApp/email/webhook — регистрируйтесь на странице тарифов Nova Uptime. Для разовых проверок возраста регистрации и истечения — чекер истечения домена и чекер возраста домена.

Чек-лист 5-минутной проверки здоровья#

Запускайте по порядку. У каждого шага чёткое pass/fail.

DNS — dig +short A yourdomain.com && dig +short AAAA yourdomain.com && dig +short MX yourdomain.com. Все три должны вернуть значения. Если MX пустой — почта сломана.
SSL — echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates. notAfter должен быть дальше 30 дней.
SPF — зайдите на /tools/spf-checker, введите домен. Балл должен быть 90+.
DKIM — зайдите на /tools/dkim-checker, введите домен. Статус должен быть «Configured».
DMARC — зайдите на /tools/dmarc-checker. Политика должна быть quarantine или reject, не none.
Email health (комбинированно) — /tools/email-health даёт оценку A–F по всему перечисленному выше.
Блок-листы — /tools/blacklist-checker. Цель — ноль листингов.
Глубокая SSL-проверка — /tools/ssl-expiry для валидации цепочки и 30-дневных алертов.
Истечение домена — /tools/domain-expiry. Должно быть дальше 60 дней; чем дальше, тем лучше для SEO-authority.
Uptime — curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://yourdomain.com. Статус 200, время меньше 1,5с.

Если что-то из этого валится — вы только что определили свой главный приоритет.

Реальные истории

Несколько примеров за последние полгода работы с командами, аудитировавшими свои домены:

Несинхронизированный DKIM, скрывавшийся полгода. B2B SaaS-компания отправляла транзакционные письма через кастомный поддомен (mail.theirsite.com), но d= тег DKIM был доменом провайдера, а не их. Grace-период Gmail означал, что при низких объёмах почта всё ещё попадала в inbox. Когда они запустили первую большую кампанию — 50 000 писем — open rate был 4%. Bounce-отчёты показывали, что Gmail тихо понижал сообщения месяцами. Починка — 10 минут DNS-правок. Урок: «доставляемость выглядит нормально» — это не измерение.

Промежуточный сертификат, который заметил только Safari. E-commerce сайт автопродлевал SSL через хостинг-провайдера. Новый сертификат деплоился корректно, но в bundle отсутствовал промежуточный. Chrome и Firefox кэшировали промежуточный с предыдущих визитов и продолжали валидацию. Safari (он не агрессивно кэширует промежуточные) показывал предупреждение на весь экран. Около 18% их checkout-трафика — iOS Safari. Они потеряли два дня выручки, прежде чем тикет от клиента сложил картину.

Висящий CNAME, ставший угоном. Старая маркетинговая лендинг-страница promo.theirdomain.com была CNAME на удалённое три года назад Heroku-приложение. Атакующий зарегистрировал то же имя приложения в Heroku, и в течение 12 часов этот поддомен отдавал произвольный HTML — включая фишинговую форму, имитировавшую страницу логина компании. Починка — 30 секунд чистки DNS. Обнаружение — ноль; команда узнала только когда клиент сообщил о фишинге. Ежемесячный аудит поддоменов поймал бы это.

Заключение

Здоровье домена — это пять столпов, не один. Пройдите 5-минутный чек-лист выше. Почините проваленные пункты. Затем поставьте постоянный мониторинг на то, что дрейфует со временем — сертификаты истекают, блок-листы меняются, регистрации заканчиваются, а SPF-записи растут, пока не сломают lookup-лимит. Все пять столпов — бесплатно, в одном дашборде Nova Uptime.

Domain Health Check: полный бесплатный аудит (DNS + SSL + Email + Uptime)