Як налаштувати DMARC, SPF і DKIM та не зламати доставку листів

SPF, DKIM і DMARC давно перестали бути “технічними дрібницями для айтішників”. Для малого та середнього бізнесу це вже базова умова нормальної доставлюваності листів, захисту домену від підміни та стабільної роботи маркетингових, сервісних і транзакційних розсилок. Якщо налаштувати все поспіхом, можна випадково зламати частину листів: щось піде у spam, щось перестане доходити, а якийсь сервіс взагалі втратить право відправляти від вашого домену. Добра новина в тому, що цього легко уникнути, якщо рухатися поетапно.

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

Зміст

• Чому це важливо для бізнесу
• Що таке SPF, DKIM і DMARC простими словами
• Що перевірити до змін у DNS
• Безпечний план впровадження
• Типові помилки, які ламають доставку
• Як виглядають записи та що в них важливо
• Як перевірити налаштування без ризику
• Чеклист для SMB
• FAQ

Чому це важливо для бізнесу

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

Особливо це критично, якщо ви використовуєте кілька джерел відправки: корпоративну пошту, CRM, сервіс email-маркетингу, форму з сайту, helpdesk, платіжні повідомлення, системні сповіщення, автоматизації чи інтеграції. Саме на стику кількох сервісів найчастіше виникають помилки: один сервіс підписує DKIM, інший — ні; один домен узгоджений з From, інший — ні; SPF перевищує допустиму складність або містить застарілі include.

У 2026 році підхід “і так працює” вже занадто ризикований. Поштові провайдери послідовно підвищують вимоги до автентифікації, а для маркетингових і масових відправок перевірки стали помітно жорсткішими. Тому правильне впровадження SPF, DKIM і DMARC — це не лише безпека, а й нормальна комерційна ефективність email-каналу.

Що таке SPF, DKIM і DMARC простими словами

SPF показує, які сервери або сервіси мають право надсилати пошту від вашого домену. Простою мовою: ви публікуєте в DNS список дозволених відправників.

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

DMARC об’єднує SPF і DKIM у політику рівня домену. Він каже поштовим системам, що робити з листами, які не проходять перевірку, і дає вам звіти про те, хто намагається надсилати пошту від імені вашого домену.

Найважливіше тут — не просто “увімкнути три абревіатури”, а забезпечити alignment, тобто узгодженість домену у видимому полі From з доменом, який проходить SPF або DKIM. Саме тут багато компаній помиляються: SPF може формально бути, DKIM може бути, але DMARC все одно не проходить через неузгоджений домен.

Що перевірити до змін у DNS

Перед будь-яким редагуванням DNS зробіть одну просту, але дуже важливу річ: складіть карту всіх сервісів, які реально відправляють листи від вашого домену.

• корпоративна пошта — Google Workspace, Microsoft 365, Zoho або інший провайдер;
• CRM або ERP, що шле листи клієнтам;
• сервіс email-маркетингу;
• сайт, форми, повідомлення з WordPress чи CMS;
• helpdesk, чат-платформа, система тікетів;
• сервіси рахунків, оплат, доставки, бронювань;
• автоматизації на кшталт Zapier, Make, n8n, інтеграційних платформ;
• сторонні агенції або підрядники, які надсилають кампанії від вашого домену.

Далі перевірте, який саме домен стоїть у полі From у кожному сценарії. Наприклад, маркетинг може відправляти з news@yourdomain.com, а технічні листи — з no-reply@yourdomain.com. Якщо окремий сервіс надсилає через свій технічний домен або інший envelope domain, це ще не означає проблему, але це треба врахувати в SPF/DKIM/DMARC.

Окремо зафіксуйте поточні DNS-записи. Не редагуйте “наосліп”. Збережіть старі значення TXT/CNAME, щоб у разі помилки швидко відкотити зміни.

Безпечний план впровадження

Крок 1. Приведіть до ладу SPF

У домену має бути один SPF-запис, а не кілька. Це одна з найпоширеніших помилок. Якщо у вас окремо Google, окремо сервіс розсилок і окремо CRM, усе має бути зібрано в один валідний SPF TXT-запис.

Друге правило: SPF не повинен бути надто “важким”. Для SPF є технічне обмеження на кількість DNS lookup під час перевірки, тому надлишок include, redirect або складна вкладеність можуть зламати перевірку навіть тоді, коли запис виглядає логічно.

На старті краще використовувати м’яку політику на кшталт ~all, а не різко переходити на жорсткіший підхід, якщо ви не впевнені, що врахували всі джерела відправки.

Крок 2. Увімкніть DKIM для кожного реального відправника

DKIM часто виявляється надійнішим за SPF у сценаріях пересилання, тому для бізнесу це не “опція”, а майже обов’язкова база. Увімкніть DKIM у вашому поштовому провайдері, а також у кожному сторонньому сервісі, який надсилає листи від імені компанії.

Ключовий момент: недостатньо підписувати лише корпоративну пошту. Якщо CRM або маркетингова платформа шлють кампанії без DKIM, саме вони можуть тягнути вниз доставлюваність і ламати DMARC.

Після активації DKIM перевірте, чи домен у підписі узгоджується з вашим From-доменом у relaxed alignment або strict alignment — залежно від вашої політики. Для більшості SMB на старті достатньо relaxed.

Крок 3. Запустіть DMARC з політики p=none

Найбезпечніший стартовий сценарій — запустити DMARC у режимі спостереження, а не покарання. Тобто спочатку публікувати політику p=none і отримувати звіти, а не одразу карантинити чи відхиляти повідомлення.

Це дозволяє побачити реальну картину: які сервіси проходять перевірку, які ні, чи є спроби підміни домену, чи працює alignment, і де саме виникає проблема — у SPF, DKIM чи обох механізмах одночасно.

Для SMB це критично, бо часто виявляється, що про один з відправників ніхто вже не пам’ятає: стара форма сайту, забутий SMTP-плагін, helpdesk або зовнішній підрядник. Якщо одразу ввімкнути p=reject, можна заблокувати цілком легітимні листи.

Крок 4. Розберіть звіти та вирівняйте джерела відправки

Після запуску DMARC не зупиняйтеся на самому записі. Найцінніше — це аналіз звітів і виправлення реальної інфраструктури. Вам потрібно зрозуміти:

• які IP або сервіси відправляють від вашого домену;
• які з них проходять SPF;
• які підписуються DKIM;
• де не збігається домен у From;
• де залишилися старі або неавторизовані канали відправки.

На цьому етапі часто доводиться або додавати відправника в SPF, або вмикати DKIM у конкретному сервісі, або змінювати домен/піддомен для відправки маркетингових листів. Іноді найкраще рішення — розвести ролі: наприклад, основний домен залишити для корпоративної пошти, а піддомен віддати під масові кампанії.

Крок 5. Лише потім переходьте до quarantine або reject

Коли ви вже впевнені, що всі легітимні відправники проходять DMARC, політику можна посилювати. Зазвичай рухаються сходинками: спершу p=none, далі p=quarantine, а вже потім p=reject. Такий підхід значно безпечніший, ніж різкий перехід до жорсткої політики.

Для компаній із кількома сервісами відправки це особливо важливо. Навіть якщо корпоративна пошта налаштована ідеально, саме сторонній маркетинговий або сервісний інструмент може стати слабкою ланкою.

Типові помилки, які ламають доставку

• Кілька SPF-записів для одного домену. SPF має бути один.
• Незареєстрований сервіс відправки. CRM або сайт шлють листи, але в SPF їх немає.
• DKIM увімкнений не скрізь. Корпоративна пошта підписується, а розсилочник — ні.
• Немає alignment. Формально SPF/DKIM працюють, але не для того домену, який бачить одержувач у From.
• Надто ранній p=reject. Політика стала жорсткою ще до аналізу звітів.
• Забутий старий інструмент. Якийсь плагін, SMTP-модуль або зовнішній сервіс продовжує слати листи від вашого домену.
• Зміни без тестів. DNS оновили, але не перевірили ключові сценарії: форма сайту, CRM, маркетинг, відповіді менеджерів, системні сповіщення.

Ще одна часта проблема — спроба вирішити доставлюваність лише через SPF. Насправді сучасна практика така: SPF важливий, але стабільно покладатися краще на комбінацію SPF + DKIM + DMARC, а також на репутацію домену, чистоту бази та якість контенту листів.

Як виглядають записи та що в них важливо

Зміст записів залежить від вашого провайдера, але логіка така:

• SPF: TXT-запис на корені домену з дозволеними джерелами відправки, наприклад v=spf1 include:... і завершенням ~all або -all після стабілізації.
• DKIM: TXT або CNAME-записи, які публікує ваш поштовий сервіс чи платформа розсилок. Вони прив’язані до selector.
• DMARC: TXT-запис на _dmarc.yourdomain.com із політикою, адресою для агрегованих звітів і параметрами alignment.

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

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

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

Після кожної зміни не обмежуйтеся лише тим, що запис “зберігся у DNS”. Перевіряти треба бізнес-сценарії.

• Надішліть тест з корпоративної пошти на Gmail, Outlook і кілька реальних адрес.
• Перевірте окремо маркетинговий сервіс, CRM, форму сайту та системні повідомлення.
• Подивіться заголовки листа: чи пройшли SPF, DKIM і DMARC.
• Переконайтеся, що домен у From відповідає тому, що очікуєте.
• Протягом кількох днів або тижнів переглядайте DMARC-звіти перед підсиленням політики.

Важливо перевіряти не один лист, а кілька типів листів. Дуже часто “звичайний ручний лист менеджера” проходить чудово, а автоматичне повідомлення з форми або CRM — ні. Саме тому тести мають повторювати реальні бізнес-процеси.

Чеклист для SMB

Зона	Що зробити	Навіщо це потрібно
Інвентаризація відправників	Зібрати всі сервіси, що шлють листи від вашого домену	Щоб не забути легітимного відправника і не зламати доставку
SPF	Зробити один валідний SPF-запис без дублювання	Щоб поштові системи бачили дозволені джерела відправки
DKIM	Увімкнути підпис у кожному сервісі відправки	Щоб листи проходили перевірку навіть у складніших сценаріях
DMARC	Стартувати з p=none і збирати звіти	Щоб бачити проблеми без блокування легітимних листів
Alignment	Переконатися, що From узгоджується з SPF або DKIM	Щоб DMARC реально проходив, а не існував лише “на папері”
Тестування	Перевірити корпоративні, маркетингові, CRM і системні листи	Щоб не пропустити поломку в окремому сценарії
Посилення політики	Переходити до quarantine/reject лише після аналізу	Щоб не заблокувати свої ж листи

Висновок

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

FAQ

Чи можна обійтися лише SPF без DKIM і DMARC?

Технічно інколи листи будуть доходити і так, але для сучасної доставлюваності цього вже недостатньо. SPF без DKIM і DMARC дає слабший захист і не вирішує проблему alignment на рівні видимого From-домену.

Чи безпечно одразу ставити DMARC p=reject?

У більшості випадків — ні. Якщо ви не впевнені, що врахували всі джерела відправки, можна заблокувати легітимні листи. Безпечніше стартувати з p=none, переглянути звіти і вже потім рухатися до жорсткішої політики.

Що важливіше для бізнесу: SPF чи DKIM?

Не варто обирати щось одне. Для стабільної практики потрібні обидва механізми. Але якщо дивитися на стійкість у реальних сценаріях, DKIM часто відіграє дуже важливу роль, особливо коли SPF може ламатися через пересилання або складні маршрутизації.

Навіщо DMARC-звіти, якщо листи й так надсилаються?

Бо “лист надсилається” не означає “інфраструктура налаштована правильно”. DMARC-звіти показують, хто реально відправляє від вашого домену, які потоки проходять перевірку, а які ні. Саме це допомагає навести лад без ризику для бізнесу.

Чи варто виділяти окремий піддомен для маркетингових розсилок?

У багатьох випадках так. Це спрощує контроль репутації й політик для різних типів пошти. Але рішення залежить від ваших обсягів, інфраструктури і того, скільки різних сервісів відправляють листи.