DNS-записи A/AAAA/CNAME/MX/TXT: що це таке і як налаштувати без болю

DNS — це як телефонна книга інтернету. Люди пам’ятають назви (example.com), а сервери працюють з адресами (IP). І от DNS займається простим на вигляд, але критично важливим завданням: перекладає домен у конкретні “куди йти” — на який сервер віддати сайт, куди доставити пошту, які політики безпеки застосувати, як перевірити підпис листа, чи дозволяти відправку з домену тощо.

Якщо коротко: DNS-записи — це правила маршрутизації для домену. Неправильно налаштовані записи дають класичні симптоми: сайт “не відкривається”, пошта “не доходить”, сервіси “не підтверджують домен”, а користувачі бачать то стару версію сайту, то нову. І головне — це часто не баг сервера, а банальна помилка в зоні.

Нижче розберемо A, AAAA, CNAME, MX, TXT: що означають, де їх ставлять, як вони взаємодіють, і як зробити налаштування так, щоб потім не розгрібати проблеми з доставкою пошти та індексацією сайту. Якщо ви плануєте купити домен, під’єднати надійний хостинг, або підняти проект на VPS/виділеному сервері, ці основи — обов’язкові.

Перед тим як створювати записи: що таке зона, хост, TTL і “пропагація”

Домен, зона і хости

  • Домен: example.com

  • Хост/піддомен: www.example.com, api.example.com, mail.example.com

  • DNS-зона: набір усіх правил (записів) для домену.

Більшість панелей показують поле “Name/Host” — це ліва частина (наприклад www), а поле “Value/Target” — це права частина (IP або домен-ціль).

TTL (Time To Live)

TTL — це час кешування відповіді DNS на резолверах (провайдери, корпоративні DNS, ваш браузер частково, тощо).

  • Поставили TTL 3600 — значить “тримайте це значення годину”.

  • Для міграцій зручно тимчасово знижувати TTL (наприклад 300 секунд), щоб зміни швидше “роз’їхались”.

Пропагація DNS

Те, що в панелі ви змінили запис, не означає, що весь інтернет уже побачив нове значення. Частина кешів триматиме старе значення до завершення TTL. Тому “у мене вже працює, а в знайомого ні” — абсолютно нормальна ситуація.

A-запис: “домінує” у світі IPv4

Що таке A

A (Address) record вказує: “цей домен/піддомен відповідає IPv4-адресі”.

Приклад:

  • example.com → 203.0.113.10

  • www.example.com → 203.0.113.10

Коли використовують

  • Підключення сайту до сервера (shared hosting, VPS, dedicated).

  • Підключення api, cdn, panel, app до окремих IP.

Типовий сценарій для сайту

Часто роблять так:

  • @ (або порожнє ім’я) — A на IP сервера

  • www — або A на той самий IP, або CNAME на @ (про це нижче)

Приклад у панелі:

  • Type: A
    Name: @
    Value: 203.0.113.10
    TTL: 3600

  • Type: A
    Name: www
    Value: 203.0.113.10
    TTL: 3600

Типові помилки

  1. Забули про www: example.com відкривається, а www.example.com — ні (або навпаки).

  2. Вказали внутрішній IP типу 192.168.x.x — ззовні це не працює.

  3. Залишили старий A після міграції — частина людей потрапляє на старий сервер.

AAAA-запис: те саме, але для IPv6

Що таке AAAA

AAAA record вказує домен на IPv6-адресу.

Приклад:example.com → 2001:db8::10

Чи потрібно ставити AAAA всім?

Якщо ваш сервер/хостинг реально налаштований на IPv6 (вебсервер слухає IPv6, фаєрвол дозволяє, маршрути є), тоді AAAA — плюс: сучасні мережі можуть ходити по IPv6 швидше/стабільніше.

Але якщо поставити AAAA “просто так”, а сервер по IPv6 не працює — отримаєте дивний баг: у частини користувачів сайт не відкривається, бо їхні провайдери віддають перевагу IPv6.

Практична порада

  • Якщо не впевнений — краще не ставити AAAA, ніж поставити неправильний.

  • Якщо є надійний хостинг/VPS з повною підтримкою IPv6 — тоді ставте і тестуйте.

CNAME: “псевдонім” на інший домен

Що таке CNAME

CNAME (Canonical Name) каже: “цей хост — це псевдонім іншого домену”.

Приклад:

  • www.example.com → example.com

  • shop.example.com → shops.platform.com

  • verify.example.com → some-verification.service.com

Тут важливо: CNAME не вказує на IP напряму, він вказує на інше ім’я, а вже там DNS розрулить IP через A/AAAA.

Коли CNAME — ідеальний

  • Для www (дуже поширений випадок).

  • Для підключення сторонніх сервісів: CDN, CRM, email-провайдери, payment-віджети, конструктори, тощо.

  • Для верифікації домену в сервісах: часто дають саме CNAME.

Головне правило CNAME

На одному й тому самому імені не можна мати CNAME і інші записи.
Тобто якщо www — CNAME, то для www не має бути A/AAAA/TXT/MX одночасно.

Про “корінь домену” (@) і CNAME

Багато DNS-провайдерів не дозволяють CNAME на @ (apex). Причина проста: у корені домену потрібні ще NS/SOA та інші системні записи, а CNAME конфліктує з концепцією “єдиний запис”.

Іноді провайдери пропонують “ALIAS/ANAME” — це їхній трюк, який поводиться як CNAME для кореня, але технічно реалізовано інакше. Якщо у вашій панелі є ALIAS/ANAME — ок, але це не стандартний DNS-тип, а реалізація провайдера.

MX: куди доставляти пошту для домену

Що таке MX

MX (Mail Exchange) вказує, які сервери приймають пошту для домену.

Приклад:

  • example.com → mail.example.com (priority 10)

  • example.com → backup.mail.example.com (priority 20)

Чим менше число priority, тим вищий пріоритет.

Два популярні сценарії

Сценарій А: Пошта на вашому сервері

  1. Ставите A/AAAA для mail:

    • mail.example.com → IP сервера

  2. Ставите MX для домену:

    • MX @ → mail.example.com priority 10

Сценарій Б: Пошта на Google Workspace / Microsoft 365 / провайдері

Тоді провайдер дає список MX записів (кілька штук). Ви повністю замінюєте поточні MX на їхні значення.

Типові помилки з MX

  1. MX вказали на IP — за стандартом MX має вказувати на домен, не на IP.

  2. Не створили A/AAAA для mail-хоста, якщо MX веде на mail.example.com.

  3. Залишили старі MX разом з новими — отримаєте кашу доставки: частина листів буде йти не туди.

  4. Неправильна пріоритезація — backup з нижчим числом, ніж primary.

TXT: універсальний “контейнер” для політик і підтверджень

Що таке TXT

TXT record — це текстове поле, куди сервіси кладуть налаштування та докази володіння доменом.

Найчастіше TXT використовують для:

  • SPF — політика, хто має право надсилати листи від домену

  • DKIM — публічний ключ для перевірки підпису

  • DMARC — правила обробки листів, що не пройшли SPF/DKIM

  • Верифікації домену (Google, Meta, Stripe, Cloudflare, etc.)

  • Інколи — налаштувань для різних сервісів (наприклад, google-site-verification=...)

SPF (TXT)

SPF виглядає так:

  • Name: @

  • Value: v=spf1 include:_spf.google.com ~all

Сенс: “дозволяю відправку з домену тим, кого вказує Google; іншим — softfail”.

Якщо пошта йде з вашого VPS:

  • v=spf1 ip4:203.0.113.10 -all

DKIM (TXT)

DKIM зазвичай створюється на піддомені виду:

  • selector._domainkey.example.com

Наприклад:

  • Name: email._domainkey

  • Value: v=DKIM1; k=rsa; p=...

selector — це “ім’я ключа” (ви його задаєте в поштовій системі або дає провайдер).

DMARC (TXT)

DMARC — це теж TXT, але на фіксованому імені:

  • Name: _dmarc

  • Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s

DMARC дуже дисциплінує домен: він каже отримувачу, що робити, якщо лист не пройшов перевірки. Для бізнесу це критично, бо впливає на доставку в Inbox vs Spam.

Типові помилки з TXT

Два SPF-записи в одному домені — так не можна. SPF має бути один (можна об’єднати правила в один рядок).

Неправильний синтаксис (пробіли, лапки, розриви рядків). Більшість панелей самі “розрізають” довгі значення — це нормально, але не всюди.

DKIM записали не на тому імені (плутають селектор або _domainkey).

Занадто жорстка політика DMARC одразу (p=reject), коли SPF/DKIM ще не в порядку — і ви самі почнете “відрізати” свою ж розсилку

Практичні приклади налаштування: сайт + пошта + базова безпека

Приклад 1: Сайт на VPS/хостингу, пошта через сторонній сервіс

Хочете: сайт на сервері, а пошта — умовно Google Workspace.

DNS:

  1. @ — A → IP сервера

  2. www — CNAME → @ (або A на IP)

  3. MX — записи Google (повністю замінити на їхній список)

  4. TXT SPF — include Google

  5. DKIM/DMARC — як дасть провайдер пошти

Тут важливий нюанс: MX не впливає на сайт, це лише пошта. Люди часто бояться “зміню MX — і сайт впаде”. Ні, сайт живе у A/AAAA/CNAME.

Приклад 2: І сайт, і пошта на одному сервері

  1. @ — A → IP

  2. www — A або CNAME

  3. mail — A → IP

  4. MX @ → mail.example.com priority 10

  5. TXT SPF — ip4:... -all

  6. DKIM — TXT на selector._domainkey

  7. DMARC — TXT на _dmarc

Цей сценарій часто обирають, коли беруть VPS або виділений сервер і хочуть повний контроль. На практиці це дає гнучкість, але й відповідальність: треба правильно налаштувати SPF/DKIM/DMARC, PTR/rDNS, TLS, інакше доставку може штормити.

Чек-лист: як налаштувати DNS правильно з першого разу

Ось коротка “пам’ятка”, яка рятує години часу:

Сайт:

  • Є A (і AAAA лише якщо реально працює IPv6)

  • Є запис для www (A або CNAME)

  • TTL адекватний (на час міграції 300–600, потім 3600+)

Пошта:

  • MX вказує на доменні імена, не на IP

  • Якщо MX веде на mail.example.com — для mail є A/AAAA

  • Старі MX видалені, якщо ви переходите на нового провайдера

TXT-політики:

  • SPF рівно один

  • DKIM на правильному селекторі selector._domainkey

  • DMARC починайте з p=none, далі посилюйте (quarantine/reject), коли впевнені

Типові конфлікти:

  • На одному імені не змішуйте CNAME з A/TXT/MX

  • Не ставте AAAA, якщо IPv6 не готовий

  • Перевіряйте, що панель не додає “.example.com” автоматично (деякі панелі просять повний домен, деякі — тільки хост)

DNS — штука невидима, але вона або працює як годинник, або з’їдає нерви. Коли у вас надійний хостинг або швидкий VPS з нормальною панеллю керування DNS, половина типових проблем просто не виникає: записи створюються правильно, TTL контролюється, є підказки по SPF/DKIM, а міграції проходять без “два дні не працює пошта”.

Якщо ви на етапі “хочу купити домен і підключити хостинг/віртуалку”, не економте на базових речах: DNS, пошта і правильні записи — це фундамент, на якому тримається і сайт, і доставка листів, і репутація домену.

Потрібен виділений сервер?
Потужні конфігурації та
швидкий запуск під ключ
Обрати сервер