DNS-записи A, AAAA, MX, SPF, DKIM и TXT: практическое руководство

DNS для админа или девопса — это не абстрактная «система имён», а очень конкретный набор записей, от которых зависят:

— открывается ли сайт по домену;

— доходят ли письма в инбокс, а не в спам;

— работает ли интеграция с внешними сервисами.

В этой статье разберём базовые, но критически важные типы DNS-записей: A, AAAA, MX, SPF, DKIM и TXT. Фокус — практика: как читать зону, как вносить изменения и как не сломать прод при очередной правке.

Краткий обзор: какие бывают DNS-записи и за что они отвечают

С точки зрения администратора, DNS-запись — это строка в зоне домена, которая описывает, куда и как направлять запросы к этому домену (и его поддоменам). Базовая форма записи в зоне:

host    TTL    CLASS    TYPE    VALUE

На практике чаще всего вы видите это в виде таблицы в панели регистратора или хостинга.

Нас интересуют:

• A — IPv4-адрес (куда вести трафик по HTTP, SMTP и т.д.).
• AAAA — IPv6-адрес.
• MX — куда доставлять почту для домена.
• TXT — произвольный текст, в том числе SPF, DKIM, верификации у сервисов.
• SPF — не отдельный тип, а конкретный формат записи внутри TXT.
• DKIM — тоже формат записи внутри TXT, связанный с криптографической подписью писем.

Остальные типы (CNAME, NS, SRV, DMARC, CAA и т.д.) важны, но фундамент выстраивается вокруг этой связки.

Записи A и AAAA: куда «приходит» ваш домен

A и AAAA — фундамент. Без них домен не знает, куда указывать браузеру и клиентам.

Запись A (IPv4)

A-запись сопоставляет имя хоста и IPv4-адрес. Например:

@      300    IN    A      203.0.113.10
www    300    IN    A      203.0.113.10

В реальной панели:

• Хост: @ (или пусто) — корень домена, пример: example.com.
• Хост: www — поддомен www.example.com.
• Тип: A.
• Значение: 203.0.113.10 — IPv4 веб-сервера или VDS-сервера.

Распространённые сценарии:

• Сайт на отдельном сервере или виртуальном хостинге: указываете IP веб-сервера.
• Почта на другом сервере: всё равно нужен хотя бы один A (например, для mail.example.com), чтобы MX мог на него ссылаться.

Запись AAAA (IPv6)

AAAA-запись — то же самое, но для IPv6:

@      300    IN    AAAA   2001:db8:10::1
www    300    IN    AAAA   2001:db8:10::1

Типичные моменты:

• Если вы публикуете AAAA, убедитесь, что сервер действительно слушает по этому IPv6 и что файрволл настроен.
• Если IPv6 настроили «для галочки», но не проверяли, лучше пока не публиковать AAAA, чтобы не получить «висящие» запросы у пользователей с приоритетом IPv6.

TTL для A/AAAA и как не прострелить себе ногу

TTL (Time To Live) — сколько секунд резолверы могут кэшировать ответ. Практическая тактика:

• В штатном режиме: 3600–14400 секунд (1–4 часа).
• Перед миграцией сервера или сменой IP: за 24–48 часов временно уменьшите TTL до 300–600 секунд, подождите, после чего меняйте IP.
• После успешной миграции: верните TTL к более крупному значению, чтобы снизить нагрузку на DNS.

Важно: некоторые публичные резолверы всё равно могут кэшировать дольше, чем ваш новый TTL, так что не планируйте миграцию по секундам.

Запись MX: куда приходит почта

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

Структура MX-записи

Запись MX состоит из приоритета и доменного имени почтового сервера:

@      3600    IN    MX    10 mail.example.com.
@      3600    IN    MX    20 backup.example.net.

Ключевые моменты:

• Приоритет: чем меньше число, тем выше приоритет (10 выше, чем 20).
• Значение: это не IP, а доменное имя. На него уже должна указывать запись A (и при необходимости AAAA).
• Точка в конце имени (mail.example.com.) — в зонах это FQDN. В панелях управления её часто не нужно указывать, интерфейс добавляет домен автоматически.

Один сервер или несколько?

Минимум для работоспособности — одна MX-запись:

@      3600    IN    MX    10 mail.example.com.

Если у вас есть резервный сервер или «backup MX», то добавляется ещё запись с большим приоритетом:

@      3600    IN    MX    20 backup.example.net.

Отправители будут сначала пытаться доставить почту на приоритет 10, при недоступности — на 20.

Типичные ошибки с MX

• MX указывает на домен без A/AAAA. Например, MX → mail.example.com, но mail.example.com никуда не резолвится. Отправка писем будет невозможна.
• MX указывает на CNAME. Стандартом это не запрещено явно, но многие провайдеры и инструменты ругаются. Лучше всегда указывать MX на имя с A/AAAA, а не на CNAME.
• Путают @ и имя домена. В панели @ обычно означает «сам домен». Не нужно писать FQDN вида example.com в поле «Имя» для MX, если документация панели говорит использовать @.

TXT-записи: не только SPF и DKIM

TXT-запись — это универсальный контейнер для текстовой информации. Через него реализованы многие современные механизмы:

• SPF (определяет разрешённых отправителей почты для домена);
• DKIM (публикация публичного ключа подписи писем);
• DMARC, BIMI, MTA-STS, TLS-RPT и другие политики по почте;
• верификации у сторонних сервисов ("google-site-verification", "facebook-domain-verification" и т.п.).

Общая форма простой TXT-записи:

@    3600    IN    TXT    "some text value"

В панели вы обычно указываете только текст без кавычек, интерфейс сам расставляет их при формировании зоны.

Отдельно о DMARC, ARC и оценке почты можно почитать в статье DNS-записи для аутентификации почты.

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

SPF (Sender Policy Framework) — это политика в виде TXT-записи, которая позволяет домену объявить: с каких IP и доменов можно отправлять почту с адресами вида user@example.com. Почтовые сервисы при приёме письма сверяют отправителя с SPF, чтобы понять, легитимно ли оно.

Где хранится SPF

Исторически был тип записи SPF, но он признан устаревшим. Сейчас SPF публикуется только как TXT-запись в корне домена (для домена отправителя в поле Envelope-From / Return-Path).

Пример базового SPF:

@    3600    IN    TXT    "v=spf1 ip4:203.0.113.10 -all"

Расшифровка:

• v=spf1 — версия SPF (обязательный префикс).
• ip4:203.0.113.10 — разрешить отправку с этого IP.
• -all — всем прочим IP запретить (жёсткая политика).

Модификаторы SPF на примерах

Чаще всего SPF получается длиннее, чем один IP-адрес:

@    3600    IN    TXT    "v=spf1 ip4:203.0.113.10 include:_spf.mailprovider.net ~all"

Что используется на практике:

• ip4: и ip6: — добавление конкретных адресов или подсетей;
• a, mx — разрешить IP из A/MX-записей домена;
• include:example.net — «подтянуть» SPF другой зоны (обычно у почтового сервиса);
• квалификаторы +, -, ~, ? задают строгость.

Квалификатор +all разрешает всем отправителям слать почту от домена (в продакшене использовать нельзя), -all строго запрещает, ~all даёт «мягкий фейл» и часто используется как промежуточный этап, ?all даёт нейтральное решение.

Типичные ошибки с SPF

• Несколько SPF-записей. По стандарту должна быть только одна SPF-политика на домен (то есть одна TXT-запись, начинающаяся с v=spf1). Две и более приведут к непредсказуемому результату.
• Слишком много include. Есть лимит в 10 DNS-запросов при проверке SPF (каждый include:, a, mx и т.п. может создавать дополнительные запросы). При превышении политика считается ошибочной.
• Использование +all. Это фактически отключение SPF: разрешено всем. Такое иногда делают «чтобы ничего не ломать», но это сильно бьёт по репутации домена.

DKIM: криптографическая подпись писем через DNS

DKIM (DomainKeys Identified Mail) — это механизм, который позволяет домену подписывать исходящие письма криптографической подписью. При получении письма почтовый сервер может проверить подпись, используя публичный ключ, опубликованный в DNS.

Как DKIM выглядит в DNS

DKIM тоже публикуется через TXT-запись, но не в корне домена, а на специальном поддомене:

selector1._domainkey    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Компоненты:

• selector1 — селектор, имя ключа. Позволяет иметь несколько ключей и ротацию.
• _domainkey — фиксированный суффикс DKIM; вместе получается selector1._domainkey.example.com.
• Значение TXT — набор параметров: версия v=DKIM1, тип ключа k=rsa, публичный ключ p=... и др.

Тонкости ротации ключей, нескольких селекторов и взаимодействия с ARC подробно разбираем в статье управление DKIM-ключами и селекторами.

Как формируется подпись DKIM

На стороне вашего почтового сервера или почтового сервиса происходит следующее:

1. Генерируется пара ключей: приватный (хранится в MTA или почтовом сервисе) и публичный (публикуется в DNS).
2. Сервер подписывает определённые заголовки и тело письма приватным ключом и добавляет в письмо заголовок DKIM-Signature.
3. При получении письма адресат делает DNS-запрос за selector._domainkey.example.com, получает публичный ключ и проверяет подпись.

При корректной подписи и совпадении домена в DKIM с доменом отправителя (или доменом из From) возрастает доверие к письму — это важный фактор для попадания в инбокс, а не в спам.

Типичные ошибки с DKIM

• Обрезка ключа при копировании. Некоторые панели режут строки по длине, где-то требуется вручную объединить несколько строк в одну. Нельзя «терять» символы в начале или конце ключа.
• Лишние пробелы или переносы строк в значении TXT, которых не ожидает сервис.
• Неправильный селектор. Сервис просит создать запись для mx1._domainkey, а в DNS оказывается mx._domainkey или просто _domainkey.
• Очень маленький TTL при редких изменениях. DKIM-ключи редко меняются, обычно TTL 1–4 часа или даже сутки уместен, это снижает накладные расходы на DNS.

Практический пример: базовая зона для сайта и почты

Рассмотрим типичную задачу: у вас есть домен example.com. Вы хотите, чтобы:

• сайт открывался по example.com и www.example.com;
• почта ходила через внешний почтовый сервис;
• SPF и DKIM были корректно настроены.

Возможная конфигурация зоны:

; A/AAAA для сайта
@                3600    IN    A        203.0.113.10
www              3600    IN    A        203.0.113.10
@                3600    IN    AAAA     2001:db8:10::1
www              3600    IN    AAAA     2001:db8:10::1

; MX для внешнего почтового сервиса
@                3600    IN    MX       10 mx1.mailprovider.net.
@                3600    IN    MX       20 mx2.mailprovider.net.

; SPF для домена
@                3600    IN    TXT      "v=spf1 include:_spf.mailprovider.net -all"

; DKIM-ключ, сгенерированный почтовым сервисом
selector1._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

В панели DNS у регистратора это обычно разбивается на несколько записей, каждая со своим именем, типом и значением. Главное — не пытаться «размазать» SPF по нескольким TXT-записям и не менять селектор у DKIM на свой вкус.

Как проверять DNS: что важно смотреть после изменений

Любые правки в зоне нужно проверять снаружи, не только в панели. Основные шаги ниже.

Проверка A/AAAA и MX

Для A/AAAA и MX удобно использовать команды:

dig example.com A +short
 dig example.com AAAA +short
 dig example.com MX +short
 dig mail.example.com A +short

Проверяйте, что:

• корневой домен и нужные поддомены резолвятся на ожидаемые IP;
• MX указывают на реальные имена, для которых есть A/AAAA;
• для почтового IP корректно настроен PTR (обратная зона) и он согласован с именем, которое используется в HELO или EHLO.

Проверка TXT/SPF/DKIM

Для TXT-записей:

dig example.com TXT +short
 dig selector1._domainkey.example.com TXT +short

Проверьте, что:

• SPF-запись единственная и начинается с v=spf1;
• нет лишних кавычек, экранирующих символов и обрезанных фрагментов;
• DKIM-запись полностью совпадает с тем, что дал ваш почтовый сервис.

Дополнительно используйте специализированные проверки SPF и DKIM (онлайн-инструменты или утилиты MTA), чтобы убедиться, что политика не превышает лимиты и синтаксис корректен.

Типичные сценарии и «подводные камни» при работе с DNS

Смена хостинга для сайта

Если вы переносите сайт на другой сервер, но почта остаётся там же, достаточно поменять A и AAAA для нужных хостов (обычно @ и www). MX, SPF и DKIM при этом трогать не нужно, если не меняется почтовый сервис.

Частая ошибка — меняют DNS-серверы целиком на NS другого хостинга, не перенеся туда MX, SPF и DKIM из старой зоны. В результате сайт поднимается, а почта внезапно ломается, потому что в новой зоне нет нужных почтовых записей.

Если вы переезжаете на новый виртуальный хостинг или на собственный VDS, заранее спланируйте, какие записи будут меняться и как долго пользователи могут видеть старые IP из кэша.

Подключение нового почтового сервиса

При переходе на сторонний почтовый сервис (корпоративная почта, облачный почтовый хостинг) обычно нужно сделать три вещи:

• обновить MX, чтобы письма шли на сервера нового провайдера;
• добавить или изменить SPF-политику так, чтобы она включала разрешённых отправителей нового сервиса;
• добавить DKIM-записи с селекторами и ключами, которые выдаёт сервис.

Частая ошибка — добавить новый SPF вместо старого (получается две политики) или забыть удалить старый include: от предыдущего сервиса. В результате SPF становится некорректным, а письма начинают попадать в спам.

Несколько поддоменов с разными сервисами

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

• api.example.com — отдельный сервер или балансировщик;
• mail.example.com — почтовый сервер;
• static.example.com — CDN или другой хостинг статики.

Помните, что SPF и DMARC оцениваются по домену отправителя (из From и Envelope-From), а не по поддомену сервера. То есть если письма уходят как noreply@api.example.com, нужно смотреть политику именно для api.example.com, а не только для корневого example.com, либо грамотно выстроить наследование (например, через параметр sp= в DMARC).

Минимальный чек-лист по DNS для продового домена

Для домена, который обслуживает боевой сайт и рабочую почту, разумно пройтись по короткому чек-листу:

• Есть ли A (и при необходимости AAAA) для корня домена и основных поддоменов.
• Все ли MX указывают на имена, для которых существуют A и AAAA-записи.
• Есть одна и только одна SPF-политика в виде TXT-записи с префиксом v=spf1.
• SPF не нарушает лимит в 10 DNS-запросов.
• DKIM-записи присутствуют и действительно используются вашим MTA или почтовым сервисом.
• TTL для часто меняемых записей (A и AAAA при миграциях) не слишком велик; для редко меняемых (DKIM, MX) — достаточно велик, чтобы не создавать лишнюю нагрузку.

Если держать в порядке эти несколько типов записей — A, AAAA, MX, а также TXT с SPF и DKIM — вы уже закроете большую часть практических задач по DNS для веб-проектов и корпоративной почты. Остальные типы дополняют картину, но фундамент остаётся тем же.