Проверка домена: DNS, почта и SSL-сертификат

Что вы получите за одну проверку

• Перед переносом сайта — сохранить исходные адреса и проверить результат переключения.
• При смене почтового сервиса — сверить MX и записи отправителей.
• При жалобе на письмо — собрать DNS-контекст для дальнейшего разбора заголовков и журналов.
• Перед продлением — уточнить опубликованные сведения и проверить кабинет регистратора.
• При предупреждении браузера — сравнить проверяемое имя, сроки и альтернативные имена сертификата.

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

Шаг 1. Введите домен и запустите проверку

1. Откройте сервис проверки домена.
2. В поле «Домен» введите avg-it.ru. Для собственного объекта используйте его публичное DNS-имя, а не адрес страницы с путём.
3. В «Тип DNS-записи» оставьте «Все стандартные типы».
4. В «Имя записи» оставьте @: это сам введённый домен.
5. Поле DKIM-селектора пока оставьте пустым, если у вас нет значения из заголовка письма или панели почтового сервиса.
6. Нажмите «Проверить →» и дождитесь завершения каждого блока.

У почты, DNS, регистрации и сертификата свои результаты и время проверки. Смотрите не только надпись «Готово», но и содержание. В нашем примере без селектора DKIM сервис честно показал «Укажите селектор» — это не ошибка подписи и не доказательство отсутствия DKIM.

Что означает каждая DNS-запись

В проверенном ответе A для avg-it.ru — 178.49.141.10, MX — mail.avg-it.ru с приоритетом 10. Это разные назначения: адрес веб-сайта и сервер входящей почты. Само наличие MX не подтверждает доступность SMTP, существование ящика или доставку сообщения.

«Все стандартные типы» означает запрос перечисленных типов для выбранного имени. Это не выгрузка зоны и не поиск всех поддоменов: mail, vpn, autodiscover и имена SRV требуют собственных запросов.

Шаг 2. Проверьте отдельное имя: пример _dmarc

Оставьте «Домен»: avg-it.ru. Выберите TXT, в «Имя записи» введите _dmarc и снова нажмите «Проверить →». В блоке DNS должно быть указано полное имя _dmarc.avg-it.ru. Именно его сравнивайте с запрошенным, чтобы не проверять случайно другую запись.

При нашей проверке сервис вернул TXT с началом v=DMARC1; p=reject; sp=reject; и TTL 600 секунд. Отдельный DNS-запрос подтвердил ту же строку. В почтовом блоке и блоке регистрации некоторые данные при повторном запуске пришли из кеша — это видно по метке и времени.

• Для корня домена используйте @.
• Для локальной DMARC-записи — _dmarc.
• Для DKIM-записи — selector._domainkey, заменив selector реальным значением.
• Всегда проверяйте полное имя, которое сервис показал в результате.

Не принимайте отсутствие TXT по одному имени за отсутствие политики у всего почтового домена. Сначала уточните, какое имя действительно использует система и какой алгоритм проверки нужен.

SPF: разрешённые отправители, а не гарантия доставки

SPF описывает разрешённые источники для домена SMTP MAIL FROM, а в соответствующем сценарии — HELO. Для оценки конкретной отправки нужны IP соединяющегося сервера и проверяемая SMTP-идентичность; видимый пользователю From сам по себе недостаточен. Правила определены в RFC 7208.

В нашем снимке опубликовано v=spf1 ip4:178.49.141.4 include:_spf.yandex.net ~all. Здесь есть явный IPv4, подключаемая политика и окончание softfail. Это пример действующей записи на дату проверки, не шаблон для копирования в чужой домен.

• ip4: задаёт разрешённый IPv4-источник.
• include: требует проверки политики указанного домена.
• ~all: означает softfail для не совпавшего источника, а не обязательное помещение письма в спам.

Сервис показал один DNS-механизм верхнего уровня. Он не разворачивает вложенные include/redirect и не считает полный лимит: стандарт ограничивает число вызывающих DNS-запросы механизмов/модификаторов десятью при оценке. Не объявляйте такую запись «точно укладывающейся в лимит» по одному числу в интерфейсе.

DKIM: откуда взять селектор и что именно проверяется

Откройте оригинал полученного письма и найдите заголовок DKIM-Signature. В одной и той же подписи возьмите d= — домен подписанта и s= — селектор. При нескольких подписях не смешивайте значения разных заголовков. Принцип адресации ключа описан в RFC 6376.

DKIM-Signature: ... d=example.org; s=mail2026; ...

Это условный фрагмент, не настоящая подпись и не результат проверки. Для такого примера в поле домена указывают example.org, в поле селектора — mail2026. Имя поиска ключа: mail2026._domainkey.example.org. Если вы заполнили отдельное поле селектора, не нужно вводить туда всё это имя целиком.

1. Возьмите d= и s= из одной подписи реального письма.
2. Введите d= в «Домен», s= в «DKIM-селектор».
3. Запустите проверку и прочитайте результат поиска ключа.
4. Для оценки подписи самого письма используйте почтовый верификатор и исходное сообщение.

Найденный публичный ключ ещё не доказывает, что письмо им правильно подписано. Для криптографической проверки нужны подпись, подписанные заголовки и тело. В нашем браузерном примере селектор не задавался; успешную проверку DKIM-подписи мы не заявляем.

DMARC: опубликованная политика и проверка письма

DMARC связывает домен видимого From с успешно проверенной SPF- или DKIM-идентичностью через alignment — сопоставление доменов. Достаточно одного подходящего успешного механизма. При strict alignment домены должны совпадать; relaxed использует правила определения организационного домена. Актуальная спецификация — RFC 9989, опубликованная в мае 2026 года.

• p=none: политика не просит ограничительных действий по DMARC.
• p=quarantine: запрос на карантин для не прошедших DMARC сообщений.
• p=reject: запрос на отклонение таких сообщений.
• rua: адрес назначения агрегированных отчётов.

Решение о приёме остаётся за получателем. Сервис показывает локальную запись точного имени, не выполняет DNS Tree Walk, не определяет наследование политики и не проверяет alignment конкретного письма. Поэтому «запись не найдена» в этом блоке нельзя автоматически переводить в «все письма домена не защищены».

Не включайте reject наугад: сначала учтите CRM, 1С, рассылки, сайт и подрядчиков, реально отправляющих почту. Для изменений нужен план проверки легитимных отправок и возможность отката.

Как связаны MX, SPF, DKIM и DMARC

Самая частая путаница — искать разрешённых отправителей в MX. MX направляет входящую почту. Исходящая почта может идти через другой сервис: это проверяют по фактической отправке и её настройкам. Разделите два направления на схеме своей компании.

Входящие: внешний отправитель → MX вашего домена → ваш почтовый сервис.

Исходящие: CRM / 1С / почтовый клиент → сервер отправки → получатель.

Получатель оценивает SPF, DKIM и сопоставление доменов DMARC.

Сервис показывает DNS-контекст, а не результат доставки письма.

Регистрация: куда смотреть перед продлением

В блоке «Регистрация» сервис показывает регистрируемый домен, источник WHOIS/RDAP, регистратора, доступные статусы и даты. В нашем снимке avg-it.ru указан TIMEWEB-RU и окончание регистрации 23 июня 2027 года. Это сведения на момент проверки; оплату и настройки автопродления подтверждают в кабинете регистратора.

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

Сервис использует технические источники реестров; IANA публикует RDAP bootstrap, а для выделения регистрационного домена используется Public Suffix List. Данные владельцев сервис не выводит. Ошибка или неполный ответ реестра не являются доказательством освобождения домена.

HTTPS-сертификат: имя, доверие и срок

Проверка TLS выполняется для введённого имени на порту 443. Смотрите соответствие имени, доверие цепочке, сроки и SAN — альтернативные имена. Одинаковый IP не делает сертификат подходящим для любого имени сайта. Правила идентификации сервиса описывает RFC 9525.

В нашем результате проверялся avg-it.ru; отдельное поле «Имя в сертификате» содержало www.avg-it.ru, но SAN включал оба имени. Поэтому нельзя делать вывод об ошибке только по одному отображаемому имени. На дату снимка сертификат действовал до 6 января 2027 года, сервис показывал 56 оставшихся дней.

Важная граница: для самого avg-it.ru результат относится к локальному TLS-узлу, доступность внешнего пути не проверяется. Успешный результат не доказывает, что любой клиент снаружи попадает на тот же узел. CDN, балансировщик и разные адреса могут предъявлять разные сертификаты.

• Проверьте точное имя: корень домена, www или другой поддомен.
• Повторите открытие сайта извне с реального клиентского подключения.
• Для SMTP STARTTLS, IMAP и других портов нужна отдельная проверка.
• Настройте мониторинг продления; действующий сертификат не подтверждает отсутствие уязвимостей сайта.

Кеш, TTL и ошибки: почему ответы отличаются

TTL показывает время кеширования DNS-ответа. TTL 600 секунд — десять минут, 900 — пятнадцать. Это не обещание, что любое изменение станет видно всем ровно через этот срок: важны предыдущий TTL, кеши резолверов, отрицательные ответы и изменения делегирования.

У самого сервиса результаты могут кешироваться до пяти минут. У каждого блока есть время и метка «Из кеша» или свежий результат. После изменения DNS сначала убедитесь, что смотрите данные, полученные уже после изменения, затем сравните нужное имя и тип через другой резолвер.

• Нет записей выбранного типа: проверьте имя, тип и авторитетный источник.
• NXDOMAIN: ответ о несуществующем имени; не путайте с тайм-аутом.
• SERVFAIL или тайм-аут: ошибка получения ответа, а не доказательство отсутствия записи.
• Неверный ввод: сервис предназначен для публичных доменных имён; при проверке 127.0.0.1 он показал «Не выполнено» и предложил исправить имя.

Локальные зоны Active Directory и split DNS могут давать сотрудникам другие адреса. Публичный сервис не видит внутреннюю DNS-картину компании: сравните ответы из LAN, VPN и внешней сети.

Независимая сверка в Windows PowerShell

Следующие команды только читают публичные DNS-ответы, настройки не меняют. Запускайте их в PowerShell Windows с модулем DnsClient. Синтаксис приведён в документации Resolve-DnsName Microsoft. В примере явно выбран резолвер 1.1.1.1; если корпоративная политика запрещает внешние DNS-запросы, используйте разрешённый сервер и отметьте это в протоколе.

Адрес сайта

Resolve-DnsName -Name avg-it.ru -Type A -Server 1.1.1.1 -DnsOnly

-Name задаёт имя, -Type A — IPv4-запись, -Server — резолвер, -DnsOnly — DNS без LLMNR/NetBIOS. Ожидается ответ с IP-адресом и TTL. Во время подготовки получен 178.49.141.10.

Сервер входящей почты

Resolve-DnsName -Name avg-it.ru -Type MX -Server 1.1.1.1 -DnsOnly

Команда возвращает MX-имена и приоритеты. При сверке получены mail.avg-it.ru и Preference 10. Она не подключается к почтовому порту и не проверяет ящики.

TXT самого домена

Resolve-DnsName -Name avg-it.ru -Type TXT -Server 1.1.1.1 -DnsOnly

В ответе ищите строку, начинающуюся с v=spf1. Другие TXT могут служить подтверждению домена и иметь другое назначение. В нашем случае строка SPF совпала с показанной в сервисе.

Локальная DMARC-запись

Resolve-DnsName -Name _dmarc.avg-it.ru -Type TXT -Server 1.1.1.1 -DnsOnly

Запрашивается отдельное полное имя. При подготовке получена та же DMARC-строка, что в интерфейсе. Сохраняйте дату, резолвер и значения; TTL в повторном ответе может отличаться. Эта команда тоже не выполняет полный алгоритм DMARC для письма.

Три ситуации из практики: куда двигаться дальше

Для жалобы на спам дополнительно нужны репутация отправляющего IP/домена, содержимое, история отправок и политика получателя. Сервис не вычисляет рейтинг письма, не проверяет спам-базы и не гарантирует доставляемость. «SPF опубликован» и «письмо прошло SPF» — разные утверждения.

Результат Authentication-Results изучайте в контексте доверенного принимающего сервера: произвольный заголовок в письме может быть подделан. Фиксируйте конкретное сообщение, время и точку наблюдения, а не только общий скриншот DNS.

Что считать проверенным после изменения

1. Сохранены исходные записи, исполнитель и план отката.
2. Проверены точные имена и нужные типы; ответы сверены с проектом.
3. Учтены кеши, предыдущие TTL и время наблюдения.
4. Сайт открыт снаружи и из корпоративной сети по нужным именам.
5. Для почты выполнены реальные приём и отправка, включая 1С, CRM и сайт.
6. Заголовки, SMTP-результаты и доверенные журналы подтверждают нужное поведение.
7. Доступ к регистратору и продление контролируются ответственным.
8. Сертификат и сроки продления находятся под мониторингом.

DNS: что опубликовано и для какого имени.

TLS: какое имя и узел проверены на 443.

Письмо: подпись, источник и сопоставление доменов.

Работа сервиса: вход, отправка, приём и журналы.

Успех одного уровня не заменяет остальные.

Сохраните результаты и план проверки

Начать проверку можно прямо в сервисе AVG IT. Не передавайте в публичные формы пароли, приватные ключи, внутренние адреса и полные письма: для этой проверки достаточно публичного имени и при необходимости DKIM-селектора.

Поможем связать DNS с работой сайта и почты

Частые вопросы