Без правильно налаштованих DKIM, SPF і DMARC пошта з вашого домену масово летить у спам або відхиляється серверами Gmail та Outlook. Усі три записи вирішують одне завдання — підтверджують отримувачу, що лист справді надіслано від імені вашого домену, а не підроблено шахраєм.

Навіщо потрібні DKIM, SPF, DMARC

Запис	Що робить
SPF	Вказує, які сервери можуть надсилати пошту від імені домену
DKIM	Цифровий підпис кожного листа
DMARC	Політика дій при невідповідності SPF/DKIM

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

Увімкнення DKIM у cPanel

cPanel → Email → Email Deliverability → натисніть Repair навпроти домену. cPanel автоматично створить DKIM-запис у DNS і покаже статус «Valid», якщо запис успішно опубліковано і він пройшов перевірку. Якщо статус залишається «Not Valid» після Repair довше доби, найімовірніше домен використовує зовнішні NS-сервери (наприклад, Cloudflare), а не вбудований DNS хостингу — тоді cPanel не може сам прописати TXT-запис, і його потрібно скопіювати з cPanel → Email Deliverability вручну в панель керування DNS-провайдера.

SPF запис

# Додайте TXT запис для домену:
v=spf1 +a +mx +ip4:YOUR_SERVER_IP include:spf.protection.outlook.com ~all

# Якщо надсилаєте лише через свій сервер:
v=spf1 +a +mx ~all

Типова помилка: два SPF-записи одночасно

Якщо додати новий SPF-запис, не видаливши старий (наприклад, той, що лишився від попереднього email-провайдера), перевірка поштового сервера покаже помилку:

$ dig TXT example.com +short
"v=spf1 +a +mx ~all"
"v=spf1 include:_spf.google.com ~all"

# Результат перевірки:
permerror: Two or more SPF records found

Стандарт SPF прямо забороняє кілька TXT-записів типу v=spf1 для одного домену — при виявленні другого запису поштові сервери отримувача вважають перевірку неуспішною (permerror) і часто відправляють лист у спам саме через це, а не через вміст листа. Рішення — об'єднати всі потрібні джерела надсилання в один рядок через include: і видалити дублюючі TXT-записи в Zone Editor.

DMARC запис

# TXT запис для _dmarc.yourdomain.com
# Почніть з моніторингу (p=none):
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

# Після аналізу звітів перейдіть на quarantine:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com

# Фінальна сувора політика:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com

Перехід одразу на p=reject без періоду моніторингу — часта причина того, що легітимні листи (наприклад, надіслані через стороннє CRM чи розсилку) починають відхилятися: якщо їхні SPF/DKIM не вирівняні з доменом у полі From, DMARC із суворою політикою блокує їх нарівні з підробленими.

Як читати результати перевірки

Результат	Що означає
SPF: pass	IP відправника є в дозволеному списку домену
SPF: softfail	IP не в списку, але політика м'яка (~all) — лист позначається, не блокується
DKIM: pass	Підпис листа збігається з публічним ключем у DNS
DMARC: pass	Хоча б одна з SPF/DKIM пройшла І збігається з доменом у From

Коли записи не врятують від спам-фільтра

IP сервера вже в чорному списку (Spamhaus, Barracuda) — ідеальні SPF/DKIM/DMARC не допоможуть, поки IP не буде виключено з блеклиста
Листи надсилаються через сторонній сервіс розсилок (Mailchimp, SendGrid) без додавання його в SPF — потрібно прописати конкретний include: провайдера, інакше його листи від вашого імені провалять перевірку
Вміст листа схожий на спам за формальними ознаками — надлишок великих літер, посилання на підозрілі домени, вкладення з макросами — це оцінюється окремо від автентичності відправника
Отримувач використовує агресивний корпоративний фільтр (наприклад, вимагає повний збіг DMARC alignment у strict-режимі) — тоді навіть валідні, але не ідеально вирівняні записи можуть блокуватися

Перевірка

# Через командний рядок
dig TXT yourdomain.com
dig TXT _dmarc.yourdomain.com
# Через онлайн-сервіс:
# mxtoolbox.com → SuperTool → DKIM Lookup

Перевіряти варто після кожної зміни записів, а не лише один раз під час першого налаштування — DNS-кеш у різних резолверів оновлюється не миттєво, і результат може відрізнятися залежно від того, звідки йде перевірка. Найнадійніший спосіб перевірити все одразу — надіслати лист на тестову адресу сервісу mail-tester.com: він надішле звіт з оцінкою від 0 до 10 і вкаже, який саме із трьох записів не пройшов перевірку. Детальніше про захист пошти від спаму на вхідному боці — у статті SpamAssassin у cPanel.