Головна › Посібники

Налаштування SPF, DKIM і DMARC: записи, типові помилки, перевірка

Опубліковано 2026-11-03 ／ Оновлено 2026-11-03 ／ Автор Yuki Nakazawa

Налаштування SPF, DKIM і DMARC більше не є необов’язковим, якщо ви надсилаєте пошту від імені власного домену. Робіть це в такому порядку: опублікуйте один запис SPF, увімкніть підпис DKIM із ключем 2048 біт, а потім опублікуйте запис DMARC, почавши з p=none з увімкненими звітами. Заодно переконайтеся, що IP-адреса, з якої надсилається ваша пошта, має відповідний зворотний DNS (PTR).

Цей посібник підходить незалежно від того, чи надсилаєте ви пошту зі спільного хостингу, власного VPS, Google Workspace, Microsoft 365 або сервісу масових розсилань. Тут ви знайдете записи, які можна адаптувати під себе, помилки, що найчастіше ламають автентифікацію, і спосіб переконатися за заголовком справжнього листа, що все працює.

Наведені нижче факти звірено з RFC та офіційними сторінками Google, Yahoo і Microsoft станом на листопад 2026 року. Вимоги поштових сервісів змінюються, тож остаточним джерелом вважайте їхні сторінки.

Що підтверджують SPF, DKIM і DMARC і в якому порядку їх налаштовувати

SPF (Sender Policy Framework) дає змогу домену вказати в DNS, яким серверам дозволено надсилати його пошту. Сервер одержувача дивиться на адресу відправника в конверті (адресу SMTP MAIL FROM, яка потім з’являється як Return-Path), отримує запис SPF цього домену й перевіряє, чи є в списку IP-адреса, з якої йде підключення. Сам собою SPF нічого не каже про адресу From, яку бачить читач.

DKIM (DomainKeys Identified Mail) додає до кожного листа криптографічний підпис. Система відправлення підписує лист закритим ключем, а одержувачі перевіряють підпис за допомогою відкритого ключа, опублікованого в DNS. Дійсний підпис доводить, що домен, який підписав лист (значення d=), узяв на себе відповідальність за нього і що підписані заголовки й тіло листа не змінилися дорогою.

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

Порядок налаштування

1. Складіть список усіх систем, що надсилають пошту від імені вашого домену: власний сервер, Google Workspace або Microsoft 365, сервіси розсилок і транзакційних листів, вебформи, сервіси виставлення рахунків і служби підтримки.
2. Опублікуйте один запис SPF, який охоплює їх усі.
3. Увімкніть DKIM у кожній системі відправлення й опублікуйте її відкритий ключ.
4. Опублікуйте DMARC із p=none та адресою для звітів rua. Google радить після налаштування SPF і DKIM зачекати 48 годин, перш ніж додавати DMARC.
5. Читайте звіти, виправте джерела, які не проходять перевірку, а потім перейдіть на p=quarantine і зрештою на p=reject.

Налаштування SPF: один запис, десять запитів

SPF — це запис TXT на самому домені. Ось приклад домену, який надсилає пошту з власного сервера через IPv4 та IPv6 і також використовує Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

У більшості панелей керування DNS поле хоста залишають порожнім (або вводять @), вибирають TXT і вставляють значення, що починається з v=spf1. Типові складові:

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

• Один запис SPF на ім’я. RFC 7208 забороняє кілька записів SPF для одного домену; одержувачі повертають permerror, і SPF не проходить для жодного листа. Коли додаєте сервіс, редагуйте наявний запис і дописуйте його include:, а не створюйте другий запис v=spf1.
• Ліміт у 10 запитів. Механізми include, a, mx, ptr і exists та модифікатор redirect спричиняють запити DNS, і загальна їх кількість за всю перевірку, включно із запитами у вкладених include, не повинна перевищувати 10. Перевищення дає permerror. ip4:, ip6: і all запитів не потребують. RFC 7208 також каже, що одержувачам слід припиняти перевірку після двох запитів без відповіді, тож вилучайте include для сервісів, якими більше не користуєтеся.
• ~all чи -all. -all означає, що джерела поза списком не авторизовані (fail); ~all — що вони, імовірно, не авторизовані (softfail). Google рекомендує ~all для доменів Workspace; Microsoft рекомендує -all для доменів Microsoft 365, які також використовують DKIM і DMARC. Якщо ви ще не впевнені, що знайшли всіх відправників, почніть із ~all і залиште застосування політики DMARC.
• Піддоменам потрібен власний запис. Запис SPF на example.com не охоплює news.example.com. Якщо винести сервіс масових розсилань на окремий піддомен, він також отримає окремий ліміт у 10 запитів, а його репутація не змішуватиметься з поштою ваших співробітників.
• Синтаксичні помилки. Microsoft називає типові: include= замість include:, пробіл після двокрапки та крапка в кінці включеного домену.

Для доменів, які ніколи не надсилають пошту, опублікуйте v=spf1 -all, щоб їх було складніше підробити.

Налаштування DKIM: ключі 2048 біт і селектори

DKIM складається з двох частин: система відправлення підписує листи закритим ключем, а в DNS публікується відповідний відкритий ключ. У Google Workspace, Microsoft 365, більшості панелей керування хостингом і більшості поштових сервісів ключ генерують у консолі адміністратора й копіюють показане там значення для DNS.

Довжина ключа та селектори

Використовуйте ключ RSA довжиною 2048 біт. RFC 8301 встановлює мінімум у 1024 біти й зазначає, що підписувачам слід використовувати щонайменше 2048 біт; він також забороняє rsa-sha1. Рекомендації Google збігаються: вибирайте 2048 біт, якщо ваш DNS-хостинг це підтримує, і переходьте на 1024 лише тоді, коли не підтримує.

Селектор — це мітка, яка вказує, яким ключем підписано лист, тож домен може мати кілька ключів одночасно: по одному на кожен сервіс відправлення або на кожен період ротації. Відкритий ключ розміщується в selector._domainkey.yourdomain. Google Workspace за замовчуванням використовує селектор google. Microsoft 365 використовує два записи CNAME, selector1._domainkey і selector2._domainkey, що вказують на ключі, розміщені в Microsoft; точні цілі беріть із порталу Defender або з Get-DkimSigningConfig, бо формат залежить від тенанта.

Публікація довгого відкритого ключа

Відкритий ключ 2048 біт довший за 255 символів, дозволених в одному рядку символів DNS, тож у форматі файлу зони його записують як кілька рядків у лапках в одному записі TXT:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Замініть частини в дужках своїм справжнім ключем. Одержувачі з’єднують рядки без пробілів між ними, тож ділити ключ можна в будь-якому місці. Багато панелей керування ділять довгі значення автоматично: спершу вставте значення повністю, а ділите його самостійно лише тоді, коли панель його не приймає. Переконайтеся, що під час копіювання нічого не загубилося; порожнє p= означає, що ключ відкликано.

На власному VPS із Postfix чи подібним MTA пару ключів може створити milter для підпису, як-от OpenDKIM, наприклад opendkim-genkey -b 2048 -s selector1 -d example.com. Опублікуйте вміст згенерованого файлу відкритого ключа так, як показано вище.

Переконайтеся, що листи справді підписуються

Відкрийте надісланий вами лист і знайдіть заголовок DKIM-Signature:. Його тег d= має містити ваш домен, а s= — опублікований вами селектор. Багато поштових сервісів за замовчуванням підписують листи власним доменом; такий підпис проходить DKIM, але не узгоджується з вашим доменом From, тож для DMARC не допомагає. Увімкніть у сервісі автентифікацію власного домену, щоб d= став вашим доменом.

Налаштування DMARC: почніть із p=none, потім посилюйте

DMARC — це запис TXT у _dmarc під вашим доменом. Почніть із режиму моніторингу, у якому одержувачів просять не змінювати обробку вашої пошти, і запросіть агреговані звіти:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Агреговані звіти — це машинозчитувані зведення про те, з яких IP-адрес надсилалася пошта від імені вашого домену і чи пройшла вона перевірку; Google радить отримувати їх в окрему скриньку чи групу. Коли звіти покажуть, що кожне легітимне джерело проходить перевірку з узгодженням, посильте політику, редагуючи той самий запис, а не додаючи другий:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Узгодження простими словами

Щоб пройти DMARC, принаймні один із механізмів, SPF або DKIM, має пройти для домену, що відповідає домену From. У м’якому режимі мають збігатися організаційні домени, тож підпис DKIM із d=example.com узгоджується з поштою від alerts@news.example.com. Суворий режим вимагає точного збігу. Поштові сервіси часто використовують у Return-Path власний домен, тож SPF не узгоджуватиметься, навіть коли проходить; узгоджений DKIM — практичний спосіб провести такі листи через DMARC.

Якщо вам потрібна інша політика для піддоменів, додайте sp=. Наприклад, p=reject; sp=quarantine відхиляє листи з основного домену, які не пройшли перевірку, а такі самі листи з піддоменів лише відправляє в карантин.

Про оновлений стандарт

У травні 2026 року DMARC перевидано як RFC 9989, що замінює RFC 7489. Наявні записи працюють і далі та, як і раніше, починаються з v=DMARC1. Новий стандарт прибирає тег pct, який рідко застосовувався точно, крім значень 0 або 100, і додає теги на кшталт t=y (тестовий режим) і np (політика для неіснуючих піддоменів). Деякі довідкові сторінки провайдерів досі показують pct, тож найоднозначніший спосіб поступово ввести застосування політики — крок за кроком змінювати значення p=.

Зворотний DNS (PTR) для IP-адреси відправлення

Зворотний DNS зіставляє IP-адресу з ім’ям хоста. Google вимагає від усіх, хто надсилає на особисті облікові записи Gmail, мати запис PTR, ім’я хоста в якому знову вказує на ту саму IP-адресу відправлення, а Yahoo вимагає коректних прямого і зворотного DNS для IP-адрес відправлення та рекомендує змістовний, не шаблонний запис PTR.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

Запис PTR розміщується не в зоні вашого домену. Ним керує власник IP-адреси, тож на VPS його задають у панелі керування провайдера (часто цей розділ називається reverse DNS або rDNS), а потім створюють відповідний запис A (AAAA для IPv6) у власному DNS. Якщо ви надсилаєте через IPv6, з IPv6-адресою треба зробити те саме. У Google Workspace, Microsoft 365, поштових сервісах і на більшості спільних хостингів IP-адресами відправлення та їхнім зворотним DNS керує провайдер.

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

Прочитайте Authentication-Results

Надішліть тестовий лист на зовнішню скриньку й перегляньте повні заголовки. У Gmail відкрийте лист і виберіть «Показати оригінал». Довідка Google щодо DKIM зазначає, що надсилати слід іншому користувачеві, а не собі. Знайдіть заголовок на кшталт такого:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Точний вигляд залежить від одержувача. Важливо, щоб були spf=pass, dkim=pass і dmarc=pass, а ваш домен стояв у header.i чи header.d і в header.from. Якщо SPF проходить для домену сервісу, а DKIM показує інший домен, DMARC не пройде: спершу виправте узгодження DKIM.

Запитайте DNS безпосередньо

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

У Windows те саме робить nslookup -type=TXT _dmarc.example.com. Поширення змін DNS може потребувати часу; за даними Google, SPF і DKIM можуть почати працювати лише через 48 годин кожен. Безкоштовні онлайн-перевірки також можуть розібрати ваші записи й підрахувати запити SPF.

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

Вимоги Gmail, Yahoo і Outlook.com до відправників

Великі поштові сервіси тепер вимагають автентифікації. Станом на листопад 2026 року на їхніх офіційних сторінках сказано таке.

• Gmail (діють із 1 лютого 2024 року): усім, хто надсилає на особисті облікові записи Gmail, потрібні SPF або DKIM, прямий і зворотний DNS, що відповідають один одному, з’єднання TLS і частка спаму нижче 0,3% у Postmaster Tools. Тим, хто надсилає понад 5 000 листів на день, також потрібні і SPF, і DKIM, запис DMARC (p=none допустимо), домен From, узгоджений із SPF або DKIM, і відписка одним кліком для маркетингових листів. Ключі DKIM мають бути щонайменше 1024 біти, рекомендовано 2048.
• Yahoo (застосовуються з лютого 2024 року): усім відправникам потрібні SPF або DKIM, коректні прямий і зворотний DNS і частка спаму нижче 0,3%. Масовим відправникам потрібні і SPF, і DKIM, політика DMARC щонайменше p=none, яку лист проходить, узгодження From (м’якого режиму достатньо), робоча відписка одним кліком і коректні прямий і зворотний DNS для IP-адрес відправлення.
• Outlook.com (споживчий сервіс, що обслуговує outlook.com, hotmail.com і live.com): домени, які надсилають понад 5 000 листів на день, мають проходити SPF і DKIM та публікувати DMARC щонайменше з p=none, узгоджений із SPF або DKIM. Microsoft повідомила, що з 5 травня 2025 року листи, які не відповідають вимогам, відхилятимуться з помилкою 550; 5.7.515.

Повний текст читайте в рекомендаціях Google для відправників, найкращих практиках Yahoo для відправників і оголошенні Microsoft щодо Outlook.com. Навіть якщо ви надсилаєте значно менше листів, налаштування всіх трьох механізмів уже зараз означає, що зниження порогу в майбутньому не застане вас зненацька. Про проблеми, специфічні для Gmail, див. статтю Gmail не доставляє ваші листи.

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

• Другий запис SPF. Окремий новий запис v=spf1 для кожного сервісу робить SPF недійсним для всього домену. Об’єднайте все в один запис.
• Забагато include. Старі сервіси, що залишилися в SPF, з’їдають ліміт у 10 запитів. Вилучіть те, чим більше не користуєтеся, і перенесіть масові розсилання на піддомен.
• Ключ опубліковано, але підпис не ввімкнено. У Google Workspace після того, як запис DNS почав діяти, треба ще натиснути «Почати автентифікацію» (Start authentication); на інших платформах є схожий перемикач.
• Сервіс підписує листи власним доменом. І SPF, і DKIM проходять, а DMARC — ні. Увімкніть підпис власним доменом.
• Одразу p=reject. Забута вебформа чи система виставлення рахунків за ніч перестає доставляти листи. Почніть із p=none і читайте звіти.
• Пошкодження під час копіювання. Зайві лапки всередині значення, обрізаний ключ або ім’я хоста, яке перетворюється на _dmarc.example.com.example.com, бо панель сама додає домен. Швидка перевірка через dig виявляє все це.

Поширені запитання

Використані офіційні сторінки

Факти в цій статті на момент публікації звірено з наведеними нижче офіційними сторінками. Правила й поведінка сервісів можуть змінюватися без попередження, тож перш ніж покладатися на щось важливе, перевірте офіційні сторінки.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Схожі посібники

Усі посібники →