Как DNS-записи портят репутацию домена и доставляемость писем

DNS — это не просто техническая абстракция, которую настраивают один раз при запуске сайта. Это фундамент, на котором держится доступность ресурса, работа почты и доверие к домену со стороны поисковых систем и почтовых серверов. Ошибки в DNS-записях незаметны для обычного посетителя, но они постепенно разрушают репутацию домена, снижают доставляемость писем и, как следствие, влияют на SEO. В этой статье разберём, какие именно записи чаще всего становятся проблемой, почему это происходит и как это исправить.

Поисковые системы и почтовые сервисы не доверяют доменам, у которых есть технические проблемы. Если DNS настроен некорректно, это может привести к:

• Проблемам с доступностью сайта — если устаревшие NS-записи указывают на неработающие серверы, часть пользователей не сможет открыть сайт, что увеличивает показатель отказов и снижает поведенческие факторы.
• Блокировке писем — почтовые системы (Gmail, Яндекс.Почта, Outlook) проверяют SPF, DKIM и DMARC записи. Если их нет или они неверны, письма попадают в спам или не доставляются вовсе.
• Падению доверия — если домен используется для фишинга (из-за отсутствия защиты), его репутация падает, и поисковые системы могут понизить сайт в выдаче.

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

1. SPF/TXT записи (отправка почты)

SPF (Sender Policy Framework) — это TXT-запись, которая указывает, какие серверы имеют право отправлять почту от имени вашего домена. Если SPF настроен неправильно, возможны два сценария:

• Слишком жёсткая политика — письма с легитимных серверов (например, от CRM-системы или почтового сервиса) блокируются.
• Слишком слабая политика — злоумышленники могут отправлять письма от вашего имени (спуфинг), что быстро разрушает репутацию домена.

Пример типичной ошибки: указан только один IP-адрес, хотя почта отправляется через несколько сервисов. Или наоборот — включена запись +all, которая разрешает отправку с любых серверов. И то, и другое вредит доставляемости.

2. Устаревшие NS-записи (серверы имён)

NS-записи определяют, какие DNS-серверы отвечают за ваш домен. Если вы сменили хостинг или DNS-провайдера, но не обновили NS-записи у регистратора, домен может стать недоступным для части пользователей. Поисковые системы, обнаружив неработающие серверы, могут временно исключить страницы из индекса. Кроме того, устаревшие NS-записи — частая причина, по которой не обновляются другие записи (A, MX и т.д.).

3. MX-записи (почтовые серверы)

Неправильные MX-записи — это прямая причина потери писем. Например, если вы используете Google Workspace для почты, но MX-запись указывает на ваш старый почтовый сервер, письма будут уходить в никуда. Многие владельцы бизнеса узнают об этом только когда клиенты жалуются, что не получили ответа.

4. A/AAAA записи (IP-адреса)

Если A-запись указывает на старый IP-адрес, который больше не принадлежит вашему серверу, сайт может открываться с ошибкой или подменяться на другой. Это катастрофа для SEO: поисковый робот видит не тот контент, что вы ожидаете, или вообще не может загрузить страницу.

5. CNAME-записи (псевдонимы)

CNAME-записи часто используются для поддоменов (например, www или mail). Если целевой домен, на который указывает CNAME, перестал существовать или изменил IP, поддомен станет недоступным.

Представьте: вы отправили коммерческое предложение, но клиент его не получил. Письмо ушло в спам или было отклонено почтовым сервером получателя. Причина — неправильные DNS-записи для аутентификации почты. Помимо SPF, важны:

• DKIM — цифровая подпись, подтверждающая, что письмо не было изменено при передаче. Если DKIM-запись отсутствует или настроена неверно, почтовые системы могут считать письмо подозрительным.
• DMARC — политика, которая говорит почтовому серверу, что делать с письмами, не прошедшими проверку SPF или DKIM. Без DMARC домен остаётся незащищённым.

Эти записи — TXT-записи, и их нужно проверять и обновлять при смене почтового провайдера или добавлении новых сервисов. Если вы, например, подключили email-маркетинговую платформу, но не добавили её серверы в SPF — её письма будут блокироваться.

Шаг 1. Полная проверка DNS-записей

Используйте специализированные инструменты, которые покажут все записи домена с их текущими значениями и TTL. Например, вы можете воспользоваться бесплатным инструментом «DNS-записи домена» oWeb Solutions, который проверяет записи A, AAAA, CNAME, MX, NS, TXT и показывает TTL. Это поможет быстро выявить несоответствия: устаревшие IP, неправильные почтовые серверы или отсутствие обязательных TXT-записей.

Шаг 2. Проверка SPF, DKIM и DMARC

После получения списка TXT-записей найдите SPF-запись. Она должна начинаться с v=spf1 и содержать список разрешённых IP-адресов и серверов. Убедитесь, что в конце нет +all (это разрешает всем). Вместо этого используйте -all (строгий запрет) или ~all (мягкий запрет). Если запись длинная, проверьте, не превышает ли она лимит в 10 обращений к DNS (lookup limit) — это частая ошибка.

Для DKIM найдите TXT-запись вида имя_селектора._domainkey.вашдомен.ru. Она должна содержать публичный ключ. DMARC-запись обычно имеет вид _dmarc.вашдомен.ru и содержит политику (например, p=quarantine или p=reject).

Шаг 3. Проверка NS-записей

Сравните NS-записи домена с теми, которые указаны у вашего хостинг-провайдера или DNS-сервиса. Если вы используете Cloudflare, NS должны быть *.ns.cloudflare.com. Если вы перешли на другой хостинг, но NS остались старыми — это проблема. Обновить их можно только в панели регистратора домена. После изменения NS подождите 24–48 часов для полного распространения (учитывайте TTL).

Шаг 4. Проверка MX-записей

Убедитесь, что MX-запись указывает на правильный почтовый сервер. Если используете Google Workspace — это aspmx.l.google.com и другие серверы Google. Если Яндекс.Почта для домена — mx.yandex.ru. Проверьте приоритет (число перед сервером): меньшее число — более высокий приоритет. Ошибка в приоритете может привести к тому, что почта будет доставляться на неработающий сервер.

Шаг 5. Проверка A/AAAA записей

Узнайте текущий IP-адрес вашего сервера (у хостинг-провайдера) и сравните с тем, что указан в A-записи. Если сайт использует IPv6, проверьте AAAA-запись. Если домен привязан к CDN (например, Cloudflare), A-запись может показывать IP-адреса CDN — это нормально, но убедитесь, что они не устарели.

Шаг 6. Проверка TTL (Time to Live)

TTL определяет, как долго DNS-записи кешируются у провайдеров и на устройствах. Если вы планируете менять DNS (например, при переезде на другой хостинг), за 24–48 часов уменьшите TTL до 300–600 секунд (5–10 минут). После изменений верните TTL обратно (обычно 3600–86400 секунд). Если TTL слишком высокий, обновление записей может занять несколько дней, что вызовет ошибки доступности.

Рекомендуется проводить полную проверку DNS-записей раз в месяц, а также после любых изменений на сервере или у провайдера. Это поможет:

• Избежать потери писем — клиенты будут получать ваши ответы и рассылки.
• Защитить домен от спуфинга — злоумышленники не смогут использовать ваш домен для фишинга.
• Сохранить доступность сайта — пользователи и поисковые роботы всегда будут видеть актуальный контент.
• Не потерять позиции в поиске — стабильно работающий сайт с чистой репутацией получает больше доверия от поисковых систем.

Не ждите, пока начнутся проблемы. DNS-записи — это тихий убийца репутации домена. Регулярная проверка и своевременные исправления сохранят вашу почту, сайт и бизнес.