Если вы админ, девопс или вебмастер, рано или поздно вы упираетесь в DNS. Нужно прикрутить домен к сайту, перевести почту на новый сервис, поднять SPF/DKIM/DMARC, а параллельно не положить трафик и не потерять ни одно письмо. В этой статье собрал концентрат практики: как за 30 минут настроить A/AAAA, CNAME, MX, SPF, DKIM и DMARC для типового проекта, что и как проверить, и где чаще всего ошибаются.
Зачем вебмастеру разбираться в DNS
DNS — это адресная книга интернета. От того, как вы настроите записи, зависит доступность сайта, доставка почты и репутация домена. Ошибки в A/AAAA бьют по сайту, ошибки в MX/ SPF/ DKIM/ DMARC — по почте: письма попадают в спам или вовсе не доходят. При этом большинство задач реально закрыть за полчаса, если знать последовательность и быстро проверять изменения.
Наша цель — безопасная и предсказуемая настройка. Мы не будем изобретать сложные конструкции, вместо этого возьмём проверенные паттерны: минимально необходимые записи, осознанные TTL, без лишних «магий» и с понятными инструментами проверки.
Базовые записи для сайта: A и AAAA
Что такое A/AAAA и когда их использовать
Запись A указывает IPv4-адрес хоста, а AAAA — IPv6. Для домена второго уровня (апекс, например example.com) и для поддоменов (www.example.com) чаще всего вам нужны обе: мир давно живёт в dual-stack, и поддержка AAAA улучшит доступность и задержки для пользователей с IPv6. Если на сервере нет IPv6, ставьте хотя бы A, а AAAA не публикуйте «пустышкой».
Совет по устойчивости: если у вас кластер или балансировщик, укажите несколько адресов в нескольких A/AAAA. Клиенты и резолверы сами выберут рабочий. Не забудьте синхронизировать мониторинг — простой одного адреса не должен бить по аптайму всего домена.
Если сайт хостится у нас, актуальные IPv4/IPv6 для записи берите в панели вашего тарифа: виртуальный хостинг или VDS. В большинстве случаев достаточно указать эти IP в апексе и для www.
TTL и распространение изменений
TTL определяет, как долго резолверы могут кэшировать ответ. Для миграций удобно временно снизить TTL до 300–600 секунд за 24 часа до смены адресов, а после — вернуть на 3600–14400 секунд. Слишком маленький TTL в постоянном режиме создаёт лишнюю нагрузку на DNS и может замедлить первый запрос пользователей. Подробнее о переносе без простоя — наш гайд по миграции без простоя.
Проверка A/AAAA
Проверять записи удобно через командную строку. Несколько базовых команд:
# Проверить A/AAAA конкретного хоста
dig +short A example.com
dig +short AAAA example.com
# С учётом авторитетных NS (когда нужно убедиться в первоисточнике)
dig @ns1.example.net example.com A +norecurse
# Альтернатива
nslookup -type=A example.com
nslookup -type=AAAA example.com
# Быстрый ping по IP-версии
ping -4 example.com
ping -6 example.com
Если ответ пустой — проверьте, правильно ли опубликованы записи, нет ли конфликтующего CNAME (он исключает наличие A/AAAA на том же имени), и что ваша рабочая станция не использует устаревший кэш. При необходимости очистите кэш резолвера на локальной машине.
Типовые сценарии
Для сайта на одном сервере: на апексе домена укажите A/AAAA на IP сервера, а для www делайте CNAME на апекс или повторяйте те же A/AAAA. Если используете CDN, то обычно провайдер просит создать CNAME на техническое имя CDN; помните, что на апексе домена стандартный CNAME запрещён. Для апекса используйте A/AAAA, либо провайдерские псевдозаписи ALIAS/ANAME (если они поддерживаются в вашей панели), которые внешне ведут себя как CNAME, но совместимы со стандартом для апекса.
Псевдонимы: CNAME
Зачем нужен CNAME
CNAME — это псевдоним одного имени на другое. Клиент сначала резолвит целевое имя, затем использует его A/AAAA. Идеально подходит для www, поддоменов вида static, подключений к SaaS/ CDN, когда конечный адрес динамичен и управляется внешним сервисом. Если вы делаете стейджинг среды для CMS, посмотрите нашу инструкцию по staging и DNS.
Ограничения CNAME
Главное правило: на одном и том же имени не может быть CNAME и любых других записей (кроме некоторых DNSSEC служебных). Поэтому нельзя публиковать CNAME вместе с MX, TXT или A на одном имени. И второй важный момент — CNAME нельзя на апексе домена (example.com). Для апекса используйте A/AAAA или специальные псевдозаписи панели.
Проверка и отладка CNAME
Проверьте, на что указывает псевдоним, и резолвится ли целевое имя в адреса:
dig +short CNAME www.example.com
# Затем — финальные адреса
dig +short A www.example.com
Избегайте длинных цепочек CNAME→CNAME: каждый дополнительный шаг — это задержка и потенциальная точка отказа. Замкнутые циклы (ошибочный CNAME на самого себя) проявятся ошибками резолвинга.
Почта: MX
Принцип работы MX
Записи MX указывают, куда доставлять входящие письма для домена. У MX есть приоритет (меньшее число — выше приоритет). Обычно публикуют несколько MX на разные имена хостов почтового сервера. Важно: каждое имя из MX должно резолвиться в A/AAAA. Ссылка на CNAME запрещена стандартом — это частая ошибка.
Тайминги и TTL
Типичный TTL для MX — 3600–14400 секунд. Если вы переносите почту, снизьте TTL заранее. И помните: отправители кэшируют не только MX, но и A/AAAA целевых хостов. В день миграции убедитесь, что и MX, и A/AAAA новых хостов актуальны.
Проверка MX
dig +short MX example.com
# Посмотреть адреса целевых хостов
for h in $(dig +short MX example.com | awk '{ print $2}'); do
echo "=== $h ==="; dig +short A $h; dig +short AAAA $h; done
Если MX отсутствует, большинство отправителей попробуют доставить письмо на A/AAAA апекса домена (плохая практика). Явно укажите MX, чтобы контролировать поток писем и репутацию. Если домен ещё не куплен — оформите его через регистрацию доменов и подключите к вашей DNS-панели.
Аутентификация почты: SPF, DKIM, DMARC за 30 минут
SPF: кто имеет право отправлять почту от имени домена
SPF публикуется как запись TXT на апексе домена. Он перечисляет источники, которым разрешено отправлять письма с вашим доменом. Базовый шаблон: v=spf1 ... -all, где механизмы внутри описывают разрешённые пути: a (адреса из A/AAAA домена), mx (адреса из MX), ip4/ip6, include: для доверия внешним провайдерам.
# Пример простого SPF (сайт шлёт письма с того же сервера)
v=spf1 a mx -all
# Пример со сторонним сервисом рассылок
v=spf1 a mx include:_spf.mailer.example ip4:203.0.113.0/24 -all
Ключевая ловушка SPF — лимит в 10 DNS-запросов на обработку одного SPF. Сюда входят include, mx, a, ptr, exists. Перебор лимита приведёт к permerror у получателя. Избегайте каскадов include, дублирующих провайдеров. Всегда публикуйте одну SPF-запись на домен; две и более считаются ошибкой.
Хвост политики: -all (жёсткий запрет), ~all (мягкое), ?all (неизвестно). Для продакшна разумно начать с ~all, собрать отчёты через DMARC, затем ужесточить до -all, когда будете уверены, что все легитимные источники учтены.
DKIM: подпись содержимого письма
DKIM подписывает письмо закрытым ключом, а открытый публикуется в DNS как TXT на имени вида <selector>._domainkey.example.com. Селектор различает ключи: удобно для ротации и разделения сервисов. Для новых внедрений используйте ключи 2048 бит. Некоторые панели требуют разбить длинный ключ на несколько строк — это нормально, DNS склеит их на стороне клиента.
# Имя записи (пример)
selector1._domainkey.example.com
# Значение TXT (упрощено)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B...IDAQAB
Проверьте, что d= в заголовке подписи совпадает с вашим доменом (или поддоменом, если так задумано), а селектор s= соответствует записи. Планируйте ротацию ключей: заведите новый селектор, распространите, переключите отправку, удалите старый после истечения TTL плюс запас.
DMARC: политика и отчётность
DMARC позволяет задать политику обработки писем, не прошедших SPF/DKIM и выравнивание домена (alignment), а также получать агрегированные отчёты. Публикуется как TXT на _dmarc.example.com. Ключевые теги: p=none|quarantine|reject, rua= (куда отправлять агрегированные отчёты), ruf= (форензик-отчёты, используйте осторожно), aspf=/adkim= (режим выравнивания, r — relaxed, s — strict), pct= (процент применения).
# Стартовая запись (сбор статистики, без блокировок)
_dmarc.example.com IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; fo=1; adkim=r; aspf=r"
# Боевой режим (строгая политика)
_dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; adkim=s; aspf=s; pct=100"
Выравнивание означает, что домены в SPF/DKIM должны соответствовать домену из From (с точностью до поддомена — при relaxed, или строго — при strict). На практике сначала ставят p=none, наблюдают отчёты 1–2 недели, затем переходят на quarantine и далее на reject, когда ложноположительных почти нет.
Пошаговый план «за 30 минут»
- 0–5 минут: проверьте, кто авторитетные NS вашего домена, и где редактируется зона. Убедитесь, что у вас есть доступ и что изменения не конфликтуют с параллельными задачами коллег. Если домен ещё не куплен, оформите его через регистрацию доменов.
- 5–10 минут: настройте
A/AAAAдля апекса домена, проверьте разрешение имени, временно уменьшитеTTL, если планируете миграцию. ДобавьтеwwwкакCNAMEна апекс или повторитеA/AAAA. - 10–15 минут: подключите любые дополнительные поддомены с
CNAMEна внешний сервис (CDN, статический хостинг). ИзбегайтеCNAMEна апексе; если нужен псевдоним на корне, используйте спецмеханизмы панели. - 15–20 минут: создайте
MXзаписи на имена почтовых серверов. Убедитесь, что каждое имя изMXрезолвится вA/AAAA. Проверьте приоритеты. - 20–25 минут: соберите все источники отправки почты (ваш сервер, CRM, платформа рассылок), составьте один
SPFбез превышения лимита 10 запросов. Начните с~all, чтобы отловить забытые источники. - 25–30 минут: сгенерируйте
DKIM-ключи у провайдера отправки, опубликуйтеTXTс селектором, включите подпись на отправляющем сервере. СоздайтеDMARCсp=noneиrua=на ваш почтовый ящик аналитики. Проверьтеdigвсех записей.
Быстрее всего внедряется SPF и DMARC p=none. На DKIM больше времени уходит на генерацию ключа и включение подписи на стороне отправителя.
Пример минимальной зоны для сайта и почты
Ниже — лаконичный пример записей для типового домена. Формат BIND, но те же значения легко вносятся через любую панель DNS.
$ORIGIN example.com.
$TTL 3600
@ IN A 198.51.100.10
@ IN AAAA 2001:db8::10
www IN CNAME example.com.
static IN CNAME cdn.vendor.net.
; Почта
@ IN MX 10 mx1.mailhost.net.
@ IN MX 20 mx2.mailhost.net.
mx1 IN A 198.51.100.20
mx1 IN AAAA 2001:db8::20
mx2 IN A 198.51.100.21
; SPF/DKIM/DMARC
@ IN TXT "v=spf1 a mx include:_spf.mailhost.net -all"
selector1._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B...IDAQAB"
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; adkim=r; aspf=r"
Адаптируйте под свои значения и убедитесь, что все целевые имена резолвятся. Если провайдер DKIM выдал ключ 2048 и он длинный — разнесите его на несколько строк в интерфейсе, панель обычно автоматически формирует корректную запись.
Проверка и отладка: что реально важно
Не полагайтесь на «вроде работает». Убедитесь в корректности каждой записи и в её видимости со стороны интернета. Список минимальных проверок:
- A/AAAA: резолвятся, пингуются по нужной IP-версии, открывается ваш сайт;
- CNAME: цепочка конечна, целевое имя резолвится в адреса, нет конфликтующих записей на том же имени;
- MX: видны приоритеты, целевые имена резолвятся в A/AAAA, SMTP-порт 25/587 доступен (если вы сами принимаете/отправляете);
- SPF: один TXT с
v=spf1, без дубликатов, без превышения лимита 10 запросов; - DKIM:
digвозвращает ключ селектора, отправленные письма содержат заголовокDKIM-Signatureи проходит валидация; - DMARC: запись доступна по
_dmarc.example.com, отчёты приходят на указанный адрес, политика постепенно ужесточается.
# Быстрые проверки текста записей
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com
# Проверить MX и доступность SMTP баннера
nc -vz mx1.mailhost.net 25
Для диагностики доставки почты отправьте тестовые письма на внешние ящики и проверьте заголовки: SPF Pass/Softfail, DKIM Pass/Fail, DMARC Policy Applied. Ошибки в отчётах DMARC помогут найти забытые источники отправки или невыравненные домены.
Частые ошибки и как их исправить
- Две SPF-записи на домен. Оставляйте одну. Слейте механизмы в один TXT, соблюдая лимит запросов.
- CNAME на апексе. Стандарт запрещает. Используйте A/AAAA или провайдерские ALIAS/ANAME.
- MX указывает на CNAME. Нельзя. Перепишите MX на имя хоста, у которого есть A/AAAA.
- Превышен лимит 10 DNS-запросов в SPF. Уберите лишние include, замените «mx»/«a» на конкретные ip4/ip6, если это безопасно.
- Слишком длинный DKIM без кавычек/экранирования. Разбейте значение TXT на несколько строк, проверьте кавычки в панели.
- Отсутствует DMARC или неправильный синтаксис. Минимум:
v=DMARC1; p=none; rua=mailto:.... Проверьте теги и точки с запятыми. - TTL 86400 при миграции. Снизьте до 300–600 заранее, затем верните на рабочее значение.
- Несогласованность A/AAAA. IPv6 ведёт на другой хост, чем IPv4. Держите паритет адресов или отключите AAAA, если сервис не готов.
Безопасность и устойчивость: на что ещё обратить внимание
Держите минимум два авторитетных NS на разных площадках. Для почты публикуйте несколько MX с приоритетами и мониторьте их доступность. Следите за размером зоны и аккуратно используйте wildcard-записи — они могут неожиданно перехватить трафик на «служебные» поддомены. Если ваша платформа поддерживает DNSSEC, включайте его, но только после проверки, что ваш регистратор и NS корректно обмениваются DS-записями; некорректный DNSSEC ломает резолвинг сильнее, чем любой другой сбой.
Планируйте изменения: сначала снизьте TTL, потом правьте записи, затем проверяйте авторитетные NS и кэши. Для массовых правок ведите changelog и храните экспорт зоны в системе контроля версий — это экономит часы при откатах и аудитах. Для HTTPS и STARTTLS заранее подготовьте SSL-сертификаты — это улучшит репутацию почты и защиту сайта.
FAQ коротко
Можно ли держать только SPF без DKIM/DMARC?
Можно, но это слабая защита. Без DKIM/DMARC вы не контролируете политику и не получаете отчёты. Минимум — SPF + DMARC p=none, затем подключайте DKIM и ужесточайте политику.
Почему письма иногда приходят, хотя SPF/DMARC строгие?
Отправители могут кэшировать записи, есть ретраи и разные трактовки политик. Кроме того, письма могут проходить по DKIM при провале SPF. Проверяйте выравнивание и отчёты DMARC.
Что выбрать: ~all или -all в SPF?
Начните с ~all (мягкий режим) на этапе внедрения и сбора статистики, после валидации всех источников переключайтесь на -all.
Можно ли указывать IP вместо include в SPF?
Да, это снижает количество DNS-запросов. Но IP-пулами управляет провайдер отправки, они могут меняться. Если фиксируете IP, следите за обновлениями.
Нужно ли публиковать AAAA, если сервер без IPv6?
Нет. Публикуйте только те записи, за которыми есть реально работающие сервисы. Пустая AAAA приведёт к ошибкам для клиентов с приоритетом IPv6.
Подведём итог: грамотная настройка DNS — это не магия, а аккуратная последовательность действий. Разложите задачу на блоки A/AAAA, CNAME, MX, SPF, DKIM, DMARC, проверьте каждый шаг инструментами и не забывайте про TTL. В результате ваш сайт будет стабильно доступен, а почта — доставляться и защищать репутацию домена.
