Припиніть вгадувати свій DNS: зручний для розробників огляд MX, SPF, DKIM і DMARC

Чому DNS-записи для email зараз важливі

Колись автентифікація email була необов’язковою. У 2026 році це базова вимога. Gmail і Outlook застосовують SPF і DKIM для масових відправників, а DMARC швидко стає обов’язковим для будь-якого домену, що надсилає транзакційні листи. Якщо ваші DNS-записи неправильні, ваші листи не доходять — без bounce, без попередження, просто тиша.

Проблема в тому, що ці записи документують як RFC, а не як інструменти. Більшість розробників копіюють приклади з інструкції налаштування свого email-провайдера й сподіваються на краще. Це працює, доки не потрібно усунути проблему, додати другий сервіс надсилання або пояснити клієнту, чому листи з його контактної форми потрапляють у спам.

Цей посібник проходить через MX, SPF, DKIM і DMARC у тому порядку, у якому ви, найімовірніше, з ними зіткнетеся: з достатньою кількістю деталей, щоб налаштувати їх правильно, і достатнім контекстом, щоб налагодити їх, коли щось зламається.

MX-записи: куди йде вхідна пошта

MX-записи повідомляють інтернету, які поштові сервери приймають email для вашого домену. Вони найпростіші з чотирьох, але їх також найлегше налаштувати неправильно.

MX-запис має дві частини: число пріоритету та hostname. Нижчі числа пріоритету перевіряються першими. Якщо ви використовуєте Google Workspace, ваші MX-записи можуть виглядати так:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Крапки в кінці важливі — вони вказують, що hostname є повністю кваліфікованим. Більшість DNS-провайдерів додають їх автоматично, але не всі.

Поширені помилки: спрямовувати MX-записи на A-запис замість hostname, виставляти всім пріоритетам однакове число (це нівелює сенс резервних серверів) або забути видалити старі MX-записи під час міграції між провайдерами. Застарілі MX-записи не просто безпечно лежать без діла — вони можуть спричинити поштові цикли або розділити доставку між двома скриньками.

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

SPF: яким серверам дозволено надсилати від вашого імені

SPF (Sender Policy Framework) — це TXT-запис, який перелічує IP-адреси та домени, авторизовані надсилати email від імені вашого домену. Це перша перевірка, яку виконують більшість поштових серверів, коли отримують повідомлення, що нібито надійшло від вас.

Базовий SPF-запис виглядає так:

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

Розберімо його:

• v=spf1 оголошує версію SPF
• include:_spf.google.com делегує перевірку SPF-запису Google
• ~all — це soft fail: відхиляти пошту з неперелічених джерел, але не надто суворо

Ви також можете використовувати ip4: або ip6:, щоб додати конкретні адреси до whitelist, або a і mx, щоб посилатися на A- та MX-записи вашого домену. Механізм all наприкінці керує тим, що станеться з поштою з джерел, яких ви не перелічили: -all — hard fail (відхилити), ~all — soft fail (позначити як підозріле), ?all — нейтрально (без позиції), а +all — повна вседозволеність (не використовуйте це).

SPF має дві гострі межі. По-перше, він ламається під час пересилання, бо сервер пересилання не входить до вашого SPF-запису. По-друге, SPF-записи мають ліміт lookup у десять DNS-запитів. Якщо ви включите забагато сторонніх сервісів, перевищите ліміт, і SPF перестане працювати. Виправлення — flatten ваш SPF-запис: замінити директиви include: фактичними діапазонами IP, але це потребує підтримки, коли провайдери змінюють свої IP.

DKIM: криптографічний доказ ідентичності відправника

DKIM (DomainKeys Identified Mail) додає цифровий підпис до вашого вихідного email. Сервер-отримувач перевіряє підпис за публічним ключем, опублікованим у вашому DNS. Якщо підпис дійсний і повідомлення не було змінено, DKIM проходить перевірку.

На відміну від SPF, DKIM витримує пересилання, бо підпис подорожує разом із повідомленням. Він також гнучкіший — ви можете мати кілька DKIM-ключів для різних сервісів надсилання, кожен зі своїм selector.

DKIM DNS-запис виглядає так:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selector (default у цьому прикладі) довільний — його обирає ваш email-провайдер. Значення p= — це публічний ключ, зазвичай довгий рядок, закодований у base64. Ваш email-провайдер генерує приватний ключ і використовує його для підписування вихідних повідомлень.

Налаштування DKIM майже завжди виконує ваш email-провайдер. Ваше завдання — скопіювати TXT-запис, який він надає, і вставити його у свій DNS. Складність у тому, що деякі DNS-провайдери погано працюють із довгими TXT-записами — вони або обрізають їх, або вимагають розбити значення на кілька рядків у лапках.

Щоб перевірити, чи працює DKIM, надішліть тестовий лист на адресу Gmail і перевірте headers. Шукайте dkim=pass у header Authentication-Results.

DMARC: застосування політик і звітність

DMARC (Domain-based Message Authentication, Reporting and Conformance) пов’язує SPF і DKIM разом і повідомляє серверам-отримувачам, що робити, коли автентифікація не проходить. Він також вмикає звітність, щоб ви могли бачити, хто надсилає email від імені вашого домену — як легітимно, так і з підміною.

Мінімальний DMARC-запис виглядає так:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none означає лише моніторинг — не відхиляти й не поміщати в карантин повідомлення, що не пройшли перевірку
• rua=mailto:[email protected] вказує, куди надсилати агреговані звіти

Коли ви впевнені, що SPF і DKIM працюють, можете посилити політику до p=quarantine (надсилати невдалі повідомлення в спам) або p=reject (відхиляти їх одразу). Також можна задати політику для піддоменів через sp= і вказати відсоток повідомлень, до яких застосовувати політику, через pct=.

DMARC-звіти — це XML-файли, які великі отримувачі надсилають щодня. Вони багатослівні й важкі для читання в сирому вигляді, але точно показують, які повідомлення пройшли або не пройшли автентифікацію і чому. Якщо легітимну пошту відхиляють, звіти покажуть, яка саме перевірка SPF або DKIM не проходить.

Одна пастка: DMARC вимагає alignment. Для SPF домен у header Return-Path має збігатися з доменом у header From (або бути піддоменом). Для DKIM домен d= у DKIM-підписі має збігатися з доменом From. Якщо ви використовуєте сторонній сервіс надсилання, він має підтримувати кастомні return paths або DKIM-підписування вашим доменом, а не своїм.

Як перевірити поточне налаштування

Більшість DNS-проблем невидимі, доки не спричинять збій. Ось як перевірити записи до того, як щось зламається:

1. Запитайте свої MX-записи: dig MX example.com має повернути hostnames і пріоритети ваших поштових серверів. Переконайтеся, що вони відповідають документації вашого email-провайдера.

1. Перевірте синтаксис SPF: dig TXT example.com і знайдіть запис v=spf1. Пропустіть його через SPF-валідатор, щоб виявити синтаксичні помилки й порушення ліміту lookup.

1. Перевірте DKIM-ключі: надішліть тестовий лист і перегляньте header DKIM-Signature. Витягніть selector і домен, а потім виконайте запит dig TXT selector._domainkey.example.com, щоб підтвердити, що публічний ключ існує.

1. Перевірте політику DMARC: dig TXT _dmarc.example.com має повернути ваш DMARC-запис. Переконайтеся, що rua= вказує на адресу, яку ви справді моніторите.

1. Протестуйте end-to-end: скористайтеся сервісом на кшталт mail-tester.com або надішліть лист на адресу Gmail і перевірте повні headers. Шукайте spf=pass, dkim=pass і dmarc=pass у header Authentication-Results.

Якщо ви налагоджуєте, чому листи не доходять, headers — ваш найкращий інструмент. Більшість поштових клієнтів дозволяють переглядати raw headers — у Gmail відкрийте повідомлення, натисніть три крапки й виберіть 'Показати оригінал'. Header Authentication-Results точно покаже, яка перевірка не пройшла і чому.

Коли використовувати політики піддоменів

Якщо ви надсилаєте email із кількох піддоменів — скажімо, newsletter.example.com для маркетингу та app.example.com для транзакційної пошти, — можна задати окремі DMARC-політики для кожного піддомену. Це дозволяє застосовувати суворі політики на піддоменах, які ви контролюєте, зберігаючи м’якшу політику на основному домені.

Компроміс — складність. Кожному піддомену потрібні власні SPF, DKIM і DMARC-записи, і вам потрібно відстежувати, які сервіси надсилання авторизовані для яких піддоменів. Для більшості невеликих команд один добре налаштований домен простіший і не менш безпечний.

Що робити, коли автентифікація ламається

Найпоширеніший сценарій збою — додавання нового сервісу надсилання без оновлення DNS. Якщо ви починаєте використовувати нового провайдера транзакційних email, потрібно додати його SPF include або діапазон IP, налаштувати DKIM-підписування вашим доменом і перевірити DMARC alignment.

Друга найпоширеніша проблема — пересилання. Якщо користувачі пересилають ваш email на іншу адресу, SPF не пройде перевірку, бо сервер пересилання не входить до вашого SPF-запису. DKIM зазвичай витримує пересилання, тож доки DKIM проходить і ваша DMARC-політика дозволяє часткове alignment, повідомлення має бути доставлене. Якщо ви бачите, що переслану пошту відхиляють, перевірте свою DMARC-політику — p=reject зі strict alignment зламає пересилання.

Третя проблема — поширення DNS. Зміни DNS-записів можуть поширюватися годинами, а різні поштові сервери кешують записи на різний час. Якщо ви щойно оновили запис, а він не працює, зачекайте кілька годин і протестуйте знову. Перевірити поширення можна інструментом на кшталт whatsmydns.net.

Ключові висновки

• MX-записи маршрутизують вхідну пошту; SPF, DKIM і DMARC автентифікують вихідну пошту. Вони розв’язують різні проблеми, і вам потрібні всі чотири.
• SPF ламається під час пересилання й має ліміт у десять lookup. DKIM витримує пересилання, але потребує налаштування для кожного сервісу. DMARC пов’язує їх разом і вмикає звітність.
• Почніть із p=none у DMARC, моніторте звіти кілька тижнів, а потім посильте до p=quarantine або p=reject, коли будете впевнені, що легітимна пошта проходить.
• DNS-помилки тихі. Тестуйте конфігурацію реальним email і переглядайте headers, щоб підтвердити проходження SPF, DKIM і DMARC.
• Якщо автентифікація ламається після додавання нового сервісу надсилання, перевірте SPF includes, DKIM selectors і DMARC alignment. Headers покажуть, яка перевірка не пройшла.

FAQ

Q: Чи можу я мати кілька SPF-записів?

A: Ні. Кілька SPF-записів призведуть до того, що всі вони будуть проігноровані. Якщо потрібно авторизувати кілька сервісів, використовуйте директиви include: в одному SPF-записі або перелічіть діапазони IP напряму. Стежте за лімітом у десять lookup.

Q: Чи потрібен мені DMARC, якщо я надсилаю лише кілька листів на день?

A: Так. DMARC не про обсяг — він про доведення того, що ви є тим, за кого себе видаєте. Навіть невеликі домени виграють від DMARC, бо він запобігає підміні й дає видимість проблем доставки. Почніть із p=none і адреси для звітів.

Q: Що станеться, якщо DKIM і SPF обидва не пройдуть, але email виглядає легітимним?

A: Це залежить від вашої DMARC-політики. Якщо p=none, пошта доставляється з попередженням. Якщо p=quarantine, вона потрапляє в спам. Якщо p=reject, її відхиляють. Саме тому слід моніторити DMARC-звіти перед застосуванням суворої політики — у вас можуть бути легітимні відправники, про яких ви не знали.

Q: Чи можу я використовувати той самий DKIM-ключ для кількох доменів?

A: Технічно так, але не варто. Кожен домен має мати власну пару DKIM-ключів. Спільні ключі ускладнюють ротацію й збільшують масштаб наслідків, якщо приватний ключ буде скомпрометовано.

Q: Як часто слід ротувати DKIM-ключі?

A: Універсального правила немає, але раз на рік — розумно для більшості доменів. Якщо ви підозрюєте, що ключ було скомпрометовано, ротувати потрібно негайно. Переконайтеся, що новий публічний ключ опублікований у DNS до того, як почнете підписувати новим приватним ключем, і залиште старий ключ у DNS на кілька днів після ротації, щоб обробити затриману пошту.

<!-- tool-cta:start -->

💡 Спробуйте це: Перевірте опубліковану політику будь-якого домену за допомогою DMARC Lookup, щоб побачити, як на практиці поєднуються записи MX, SPF і DMARC.

<!-- tool-cta:end -->

Джерела

• RFC 7208: Sender Policy Framework (SPF) — Специфікація SPF, зокрема правила синтаксису та ліміт у десять lookup.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Специфікація DKIM, що охоплює створення та перевірку підписів.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Специфікація DMARC, зокрема синтаксис політик і формат агрегованої звітності.
• Google Workspace: Prevent spoofing and spam — Практичні рекомендації з налаштування SPF, DKIM і DMARC для доменів Google Workspace.