SPF, DKIM і DMARC: це три TXT-записи в DNS домену, які доводять поштовим сервісам, що лист справді надіслали ви, а не шахрай. SPF перелічує сервери, яким дозволено відправляти пошту від імені домену, DKIM ставить на кожен лист криптографічний підпис, а DMARC пояснює отримувачу, що робити з листом, який не пройшов перевірку, і надсилає вам звіти. Налаштування зводиться до трьох записів у DNS-зоні (@, selector._domainkey і _dmarc) та перевірки тестовим листом, і нижче ми пройдемо цей шлях крок за кроком з готовими прикладами.
Як ми перевіряли
Вимоги Gmail, Yahoo і Microsoft ми звірили з офіційними сторінками 30.10.2026: правила Google для відправників пошти, FAQ Google щодо цих правил, Yahoo Sender Hub і правила Outlook.com Postmaster. Дані про протоколи взято з RFC 7208 (SPF), RFC 6376 і 8301 (DKIM) та RFC 9989, 9990 і 9991 (DMARC) на rfc-editor.org. Усі приклади DNS використовують документаційний домен example.com і тестові діапазони IP 203.0.113.0/24 та 198.51.100.0/24.
Чому без SPF, DKIM і DMARC листи потрапляють у спам
Протокол SMTP сам по собі не перевіряє відправника: будь-який сервер може поставити в поле «Від» адресу info@example.com. Google і Yahoo з лютого 2024 року вимагають автентифікацію листів, а з листопада 2025 року Gmail посилює контроль за дотриманням цих вимог: листи, які їм не відповідають, отримують тимчасові та остаточні відмови в доставці. Microsoft з 5 травня 2025 року застосовує схожі правила до Outlook.com, Hotmail і Live: домени, які надсилають туди понад 5000 листів на добу, повинні мати SPF, DKIM і DMARC. Листи, що не відповідають вимогам, потрапляють у папку «Небажана пошта», а згодом можуть відхилятися з помилкою 550 5.7.515.
Станом на 30.10.2026 вимоги Gmail виглядають так:
| Вимога | Усі відправники на Gmail | Масові відправники (близько 5000 листів на добу і більше) |
|---|---|---|
| SPF і DKIM | SPF або DKIM | SPF і DKIM |
| DMARC | не обов’язковий, рекомендований | обов’язковий, достатньо p=none |
| Домен From збігається з доменом SPF або DKIM | не вимагається | так |
| Прямий і зворотний DNS (PTR) для IP відправника | так | так |
| З’єднання через TLS | так | так |
| Скарги на спам у Postmaster Tools | нижче 0,3% | нижче 0,3%, бажано до 0,1% |
| Відписка в один клік | не вимагається | так, для маркетингових листів |
Як працюють SPF, DKIM і DMARC разом
Кожен механізм перевіряє своє, і жоден окремо не захищає домен повністю:
- SPF (RFC 7208) перевіряє, чи має IP-адреса сервера, що передає лист, право відправляти пошту від домену з конверта листа (MAIL FROM, у заголовках його видно як Return-Path). Адресу, яку людина бачить у полі «Від», SPF не перевіряє.
- DKIM (RFC 6376) перевіряє цифровий підпис. Сервер підписує заголовки й текст листа закритим ключем, а отримувач бере відкритий ключ із DNS за адресою selector._domainkey.example.com і переконується, що лист не змінювали дорогою.
- DMARC (RFC 9989, раніше RFC 7489) пов’язує обидві перевірки з адресою «Від». Лист проходить DMARC, якщо SPF або DKIM дали pass і домен, який вони перевірили, збігається з доменом у From. Це називається вирівнюванням (alignment). Якщо перевірка не пройдена, отримувач застосовує вашу політику: none, quarantine або reject.
Вирівнювання буває м’яким (relaxed, за замовчуванням) і суворим (strict). У м’якому режимі достатньо збігу основного домену: підпис з d=mail.example.com підходить для From: info@example.com. У суворому домени мають збігатися повністю.
| Запис | Де розміщується | Приклад значення | Що перевіряє |
|---|---|---|---|
| SPF | TXT на самому домені (@) | v=spf1 include:_spf.google.com ~all | IP сервера-відправника |
| DKIM | TXT або CNAME на selector._domainkey | v=DKIM1; k=rsa; p=MIIBIjAN… | підпис і цілісність листа |
| DMARC | TXT на _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@example.com | збіг з доменом From, політика, звіти |
Крок 1. З’ясуйте, хто надсилає пошту від вашого домену
Найчастіша причина проблем після ввімкнення DMARC: забутий відправник. Перш ніж редагувати DNS, складіть список усіх систем, які надсилають листи з адресами вашого домену:
- поштовий сервер хостингу, тобто скриньки на кшталт info@example.com (про базове налаштування пошти на хостингу ми писали окремо);
- Google Workspace, Microsoft 365 або Zoho Mail, якщо корпоративна пошта працює там;
- сайт: WordPress, інтернет-магазин, форми зворотного зв’язку;
- сервіс розсилок, CRM, система підтримки, облікові програми, що надсилають рахунки чи звіти.
Друге питання: де керується DNS. Записи треба додавати в зону на тих NS-серверах, на які делеговано домен, інакше їх ніхто не побачить. Перевірте це командою dig NS example.com +short і, якщо потрібно, розберіться, як працює делегування домену.
Крок 2. Налаштування SPF: синтаксис і готові приклади
SPF: це один TXT-запис на самому домені (ім’я @), який починається з v=spf1. Якщо ви ще плутаєтеся в типах записів, почніть з розбору DNS-записів A, CNAME, MX і TXT. Після версії йдуть механізми, що описують дозволених відправників, а наприкінці стоїть правило для всіх інших:
ip4:203.0.113.10іip6:2001:db8::1: конкретні адреси або підмережі;aіmx: адреси з A- і MX-записів домену;include:_spf.google.com: підключає SPF-запис іншого домену, так додають Google, Microsoft і сервіси розсилок;-all(жорстка відмова),~all(м’яка відмова, softfail),?all(нейтрально) і+all(дозволити всім, ніколи так не робіть).
; Пошта лише на хостингу
example.com. TXT "v=spf1 a mx ip4:203.0.113.10 -all"
; Google Workspace
example.com. TXT "v=spf1 include:_spf.google.com ~all"
; Microsoft 365
example.com. TXT "v=spf1 include:spf.protection.outlook.com -all"
; Хостинг + Google Workspace + сайт на іншому сервері
example.com. TXT "v=spf1 mx ip4:198.51.100.7 include:_spf.google.com ~all"
; Домен, з якого пошта не надсилається взагалі
example.com. TXT "v=spf1 -all"Головне правило: SPF-запис на домені має бути лише один. Якщо в зоні два рядки з v=spf1 (наприклад, один додала панель хостингу, а другий ви для Google), перевірка повертає permerror і SPF не проходить зовсім. Об’єднуйте всі механізми в один запис.
Ліміт у 10 DNS-запитів
Стандарт обмежує перевірку SPF десятьма механізмами, що потребують DNS-запиту: include, a, mx, ptr, exists і модифікатор redirect. Вкладені include теж рахуються, а ip4, ip6 і all ліміту не витрачають. Якщо запитів більше десяти, результат permerror, і для отримувача ваш SPF фактично не існує. Щоб вкластися в ліміт, приберіть include сервісів, якими вже не користуєтеся, замініть a і mx на ip4, не використовуйте застарілий ptr, а для сервісу розсилок налаштуйте окремий піддомен, наприклад news.example.com, зі своїм SPF.
~all чи -all
Різниця з’являється, коли лист прийшов з непереліченого сервера: -all просить відхилити його, ~all просить прийняти з позначкою підозрілого. Якщо налаштовано DMARC, остаточне рішення ухвалює його політика, тож обидва варіанти робочі. Поки список відправників не перевірено звітами DMARC, ставте ~all, а коли впевнені в ньому, переходьте на -all.
Крок 3. Налаштування DKIM: селектор, ключ і запис
Поштовий сервер створює пару ключів: закритий підписує листи, відкритий публікується в DNS як TXT-запис (деякі сервіси просять CNAME на свій запис). Ім’я запису складається із селектора і суфікса _domainkey, і в одного домену може бути кілька селекторів, по одному на кожну систему відправлення.
; TXT-запис з відкритим ключем, селектор mail
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."Довжина ключа: 2048 біт. RFC 8301 визнає ключі, коротші за 1024 біти, недійсними і рекомендує саме 2048. Такий ключ не вміщається в один рядок TXT (до 255 символів), тому його ділять на кілька рядків у лапках в межах одного запису. Більшість панелей роблять це самі, а при ручному копіюванні стежте, щоб у значенні p= не з’явилося пробілів, переносів або обрізаного кінця.
Де взяти DKIM-запис
- Хостинг з панеллю керування. Під час додавання поштового домену панель зазвичай генерує DKIM-ключ, часто 2048-бітний із селектором mail. Якщо DNS-зона домену обслуговується тим самим сервером, запис mail._domainkey може додатися автоматично. Інакше скопіюйте відкритий ключ з налаштувань поштового домену й додайте запис там, куди делеговано домен.
- Google Workspace. У консолі адміністратора відкрийте Apps > Google Workspace > Gmail > Authenticate email, виберіть домен, згенеруйте ключ 2048 біт (селектор за замовчуванням google), додайте TXT-запис google._domainkey і натисніть Start authentication. Без цього Gmail підписує листи технічним доменом Google, який не вирівнюється з вашим.
- Microsoft 365. У порталі Microsoft Defender відкрийте Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Microsoft просить два CNAME-записи, selector1._domainkey і selector2._domainkey, а їхні точні значення показує портал: формат цілі для нових доменів змінився у 2025 році, тож не складайте його вручну. Після появи записів у DNS увімкніть підпис перемикачем.
- Сервіс розсилок або CRM. У налаштуваннях відправника знайдіть розділ автентифікації власного домену: сервіс видасть один-два TXT або CNAME-записи для DKIM, а часто й піддомен для Return-Path.
Ключі бажано періодично змінювати, наприклад раз на 6-12 місяців, через новий селектор. Те саме стосується зміни провайдера: під час міграції пошти на інший хостинг новий сервер має власний ключ і IP, тому DKIM-запис треба замінити, а адресу в SPF оновити.
Крок 4. Налаштування DMARC: від спостереження до p=reject
DMARC-запис додають як TXT на піддомені _dmarc. Він складається з тегів, розділених крапкою з комою. Першим завжди йде v=DMARC1, а на практиці обов’язкова ще й політика p.
| Тег | Значення | Що означає |
|---|---|---|
| v | DMARC1 | версія, завжди перший тег |
| p | none, quarantine, reject | політика: лише звіти, у спам або відхилити |
| sp | none, quarantine, reject | окрема політика для піддоменів |
| np | none, quarantine, reject | політика для неіснуючих піддоменів (тег з RFC 9989) |
| rua | mailto:dmarc@example.com | куди надсилати щоденні зведені звіти |
| ruf | mailto:dmarc@example.com | звіти про окремі збої (надсилають далеко не всі) |
| adkim, aspf | r або s | м’яке чи суворе вирівнювання, за замовчуванням r |
| t | y або n | тестовий режим з RFC 9989 замість застарілого pct |
; Етап 1: лише спостереження і звіти
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
; Етап 2: листи, що не пройшли перевірку, ідуть у спам
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
; Етап 3: повний захист домену і піддоменів
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"Не починайте одразу з p=reject. Перші 2-4 тижні тримайте p=none і читайте звіти: Gmail, Yahoo, Microsoft та інші великі сервіси надсилають на адресу з rua XML-файли з переліком IP, які відправляли листи від вашого домену, і результатами SPF та DKIM. Для їх читання зручно підключити аналізатор звітів DMARC. Коли всі легітимні джерела проходять перевірку, переходьте на quarantine, а ще через кілька тижнів на reject. Якщо звіти мають приходити на інший домен, його власник повинен дозволити це записом example.com._report._dmarc.reports.example.net TXT "v=DMARC1".
Типовий запис, який додають деякі панелі хостингу: v=DMARC1; p=quarantine; pct=100. Він підходить, якщо пошта йде лише з хостингу. Підключаєте Google Workspace чи сервіс розсилок? Спершу налаштуйте для них SPF і DKIM, інакше їхні листи підуть у спам.
У травні 2026 року IETF опублікувала оновлений стандарт DMARC (RFC 9989, звіти описано в RFC 9990 і 9991), який замінив RFC 7489. Запис і далі починається з v=DMARC1, і чинні записи працюють без змін. Тег pct отримав історичний статус, натомість з’явилися t=y (тестовий режим) і np, а основний домен тепер визначається обходом DNS-дерева замість списку публічних суфіксів.
Як перевірити SPF, DKIM і DMARC
Командний рядок
# Linux і macOS
dig +short TXT example.com | grep spf1
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com
# Windows (cmd або PowerShell)
nslookup -type=TXT _dmarc.example.com
Resolve-DnsName -Type TXT mail._domainkey.example.comЯкщо команда нічого не повертає, запис ще не поширився (зачекайте час, заданий у TTL у DNS), доданий не в ту зону або має помилку в імені. Часта пастка: панель сама дописує домен до імені, і замість _dmarc.example.com виходить _dmarc.example.com.example.com, тому в полі імені пишіть лише _dmarc.
Заголовки тестового листа
Надішліть лист на скриньку Gmail, відкрийте його і в меню «Ще» виберіть «Показати оригінал». Угорі будуть рядки SPF, DKIM і DMARC зі статусом PASS. Повна картина міститься в заголовку Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=mail;
spf=pass (google.com: domain of info@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=info@example.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.comТут видно селектор DKIM (header.s), домен конверта (smtp.mailfrom) і домен From (header.from). Якщо dkim=pass, але підпис зроблено чужим доменом на кшталт d=sendservice.net, DMARC через нього не пройде: потрібен підпис саме вашим доменом. Для перевірки без командного рядка підійдуть MXToolbox (SPF, DKIM і DMARC Lookup, підрахунок DNS-запитів SPF), mail-tester.com (оцінка тестового листа) і Google Postmaster Tools (автентифікація і скарги для листів на Gmail).
Типові помилки SPF, DKIM і DMARC
| Помилка | Що бачить отримувач | Як виправити |
|---|---|---|
| Два TXT-записи з v=spf1 | spf=permerror | Об’єднати механізми в один запис |
| Понад 10 DNS-запитів у SPF | spf=permerror | Прибрати зайві include, замінити a і mx на ip4, винести розсилки на піддомен |
| +all або ?all наприкінці SPF | SPF не захищає домен | Використовувати ~all або -all |
| Обрізаний ключ DKIM або пробіли в p= | dkim=fail або dkim=neutral | Скопіювати ключ повністю, розбити на рядки до 255 символів |
| Селектор у DNS не збігається з s= у підписі | dkim=fail, ключ не знайдено | Звірити header.s у заголовках з ім’ям запису |
| Сервіс розсилок підписує листи своїм доменом | dmarc=fail при spf=pass і dkim=pass | Налаштувати в сервісі власний домен для DKIM і Return-Path |
| Одразу p=reject без аналізу звітів | листи CRM, сайту чи бухгалтерії зникають | Почати з p=none і посилювати поступово |
| Сайт надсилає листи від адреси @gmail.com через PHP mail() | відмова або папка «Спам» | Відправляти з адреси свого домену через SMTP з автентифікацією |
Окрема історія з пересиланням: коли скринька автоматично пересилає лист далі, IP-адреса вже не ваша і SPF ламається, тому DKIM потрібен обов’язково. На власному сервері перевірте ще PTR-запис IP і підтримку TLS. Масові розсилки багато хостерів обмежують. RichHost відправляє пошту з чистих IP, тож листи доходять до адресатів, а спамерів ми блокуємо. Проте розсилки все одно краще вести через окремий сервіс, щоб берегти репутацію домену; докладніше про це: у матеріалі про email-розсилки з хостингу.
Часті питання
Чи потрібні SPF, DKIM і DMARC, якщо я надсилаю кілька листів на день?
Так. Вимога Gmail мати SPF або DKIM стосується всіх відправників, а без DMARC будь-хто може підробити вашу адресу. Мінімальний набір налаштовується за пів години: SPF, DKIM від вашого поштового сервісу і DMARC з p=none та адресою для звітів.
Скільки часу набирають чинності нові записи?
Нові записи зазвичай видно за кілька хвилин, а зміну наявних видно після закінчення TTL старого значення, найчастіше за 1-4 години. Google попереджає, що DKIM у Workspace може запрацювати протягом 48 годин після додавання запису.
Чому DMARC показує fail, хоча SPF має статус pass?
SPF перевіряв домен конверта (Return-Path), а він відрізняється від домену у From, наприклад bounce.sendservice.net. DMARC зараховує лише вирівняний результат. Налаштуйте DKIM-підпис вашим доменом або власний Return-Path у сервісі, що відправляє листи.
Що прописати для домену, з якого пошта не надсилається?
Захистіть його від підробки двома записами: v=spf1 -all на самому домені і v=DMARC1; p=reject на _dmarc. За бажання додайте порожній DKIM-ключ *._domainkey TXT "v=DKIM1; p=", який прямо каже, що дійсних підписів у домену немає.
Записи правильні, а листи все одно йдуть у спам. Що далі?
Автентифікація дає лише допуск, далі вирішує репутація. Перевірте IP і домен у чорних списках (MXToolbox Blacklist Check), скарги в Postmaster Tools, посилання для відписки і чистоту бази. Новий домен «прогрівайте», нарощуючи обсяги поступово.
Висновок
Робоча схема: один SPF-запис з усіма відправниками, DKIM з ключем 2048 біт для кожного сервісу, DMARC спершу з p=none і звітами, потім quarantine і reject. Після кожної зміни перевіряйте записи командою dig і тестовим листом, а звіти DMARC переглядайте хоча б раз на місяць.
На тарифах віртуального хостингу RichHost пошта для домену є в кожному пакеті, кількість скриньок не обмежена, а листи йдуть із чистих IP. Якщо домену ще немає, його можна зареєструвати разом з хостингом і одразу налаштувати пошту за цією інструкцією.
