Як налаштувати SPF, DKIM і DMARC - покроково + перевірка

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

Перш ніж почати, підготуйте дві речі:

Доступ до DNS-зони вашого домену (де ви додаєте записи TXT) — зазвичай це ваш реєстратор або DNS-хостинг.
Записаний список усіх сервісів, що надсилають пошту від імені вашого домену: провайдер поштових скриньок (Google Workspace, Microsoft 365…), ваш власний поштовий сервер і будь-які сторонні сервіси — інструмент розсилок, CRM, білінг/виставлення рахунків, служба підтримки. Пропустите один — і його пошта не пройде автентифікацію.

Крок 1 — Опублікуйте один запис SPF

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

Типовий запис для домену, що надсилає через Google Workspace плюс один маркетинговий інструмент:

example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Частина	Значення
`include:_spf.google.com`	Дозволяє весь відправний діапазон провайдера за посиланням. Точний токен беріть із документації кожного відправника.
`ip4:` / `ip6:`	Дозволяє ваш власний поштовий сервер за його публічною IP, напр. `ip4:203.0.113.10`.
`~all` проти `-all`	`~all` = softfail (починайте з цього під час тестування); `-all` = hardfail (перемикайтеся на нього, коли список повний).

Ліміт у 10 запитів. SPF дозволяє щонайбільше 10 DNS-запитів під час його оцінювання; кожен механізм include: та a/mx може коштувати один або більше. Перевищите його — і SPF поверне permerror, що трактується як помилка. Якщо ви нагромаджуєте багато провайдерів, приберіть невикористані include або скористайтеся сервісом SPF-flattening замість того, щоб додавати ще більше.

Починайте м'яко, потім посилюйте. Опублікуйте з ~all на тиждень-два, переконайтеся, що жоден легітимний відправник не провалюється, а потім змініть кінцевий механізм на -all.

Крок 2 — Увімкніть DKIM у кожного відправника

DKIM додає криптографічний підпис до кожного повідомлення. Ви рідко створюєте ключ вручну — кожна відправна платформа генерує його й дає вам запис TXT (або CNAME), який треба опублікувати під селектором. Робіть це для кожного відправника: Google, Microsoft, ваш ESP і ваш власний сервер — кожен отримує свій селектор і ключ.

В адмінпанелі відправника увімкніть DKIM / “автентифікацію email”. Вона покаже вам селектор (напр. google, s1) і публічний ключ.
Опублікуйте його в DNS за адресою <selector>._domainkey.example.com. Провайдери, що використовують CNAME, дають змогу ротувати ключ за вас — надавайте перевагу цьому варіанту, коли він доступний.
Повернувшись у панель, натисніть Почати автентифікацію, щоб відправник почав додавати заголовок DKIM-Signature:. Надавайте перевагу 2048-бітному ключу, коли є вибір.

Оскільки підпис подорожує всередині повідомлення, DKIM переживає пересилання (на відміну від SPF) — саме тому наступний крок спирається на нього.

Крок 3 — Розгортайте DMARC поступово

DMARC пов'язує SPF і DKIM з видимою адресою From: і вказує одержувачам, що робити в разі провалу. Ніколи не починайте з p=reject — ви відбиватимете власну легітимну пошту від відправника, про якого забули. Розгортайте його у три етапи, спостерігаючи за звітами між кожним.

Етап	Запис на `_dmarc.example.com`	Призначення
1. Моніторинг	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`	Нічого не змінює для одержувачів; лише збирає агреговані звіти про те, хто надсилає від вашого імені.
2. Карантин	`v=DMARC1; p=quarantine; pct=25; rua=…`	Надсилає частку невдалої пошти до спаму. Підвищуйте `pct` у міру зростання впевненості.
3. Примус	`v=DMARC1; p=reject; rua=…; sp=reject`	Відхиляє підроблену пошту повністю. `sp=` задає політику для субдоменів.

Адреса rua= отримує щоденні XML агреговані звіти від одержувачів. Читайте їх (безкоштовного переглядача DMARC-звітів спершу достатньо): кожен перелічує відправні IP, що використовують ваш домен, і чи пройшли вони SPF і DKIM з вирівнюванням. Вирівнювання — ось у чому пастка: повідомлення має не просто пройти SPF або DKIM — домен, що пройшов, має збігатися з доменом From:. Якщо легітимний сервіс проходить DKIM для власного домену, але не для вашого, виправте це, опублікувавши DKIM цього сервісу під вашим доменом (Крок 2), перш ніж переходити до примусу.

Крок 4 — Тримайте свої відправні IP поза RBL

SPF/DKIM/DMARC доводять особистість; блоклисти RBL (DNSBL) оцінюють репутацію відправної IP. Ідеально автентифіковане повідомлення все одно потрапить у спам, якщо його IP у списку. Для RBL ви нічого не публікуєте — ви тримаєтеся від них подалі:

Надсилайте лише бажану пошту. Скарги на спам і влучання у spam-пастки — найшвидший шлях до списку.
Прогрівайте нові IP поступово, а не завалюйте обсягом у перший же день.
Захистіть кожен акаунт і скрипт, що може надсилати пошту — одна скомпрометована форма чи пароль заносить у список цілу IP.
Налаштуйте коректний зворотний DNS (PTR) для вашої відправної IP, що збігається з її ім'ям HELO.

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

Крок 5 — Переконайтеся, що це справді працює

Публікація записів — це ще не доказ. Підтвердіть кожен рівень:

Перевірте, що записи існують. Запитуйте DNS напряму: dig TXT example.com, dig TXT google._domainkey.example.com, dig TXT _dmarc.example.com (або nslookup -type=TXT у Windows).
Підтвердіть поштові сервери, які ви авторизували. Скористайтеся нашим інструментом MX Lookup, щоб побачити MX-хости, які домен насправді публікує — зручно для виявлення застарілого чи неправильного поштового хоста.
Прочитайте результати на реальному повідомленні. Надішліть собі тестове повідомлення, відкрийте його сире джерело й вставте у декодер MIME. Погляньте на заголовок Authentication-Results: — він зазначає spf=pass, dkim=pass і dmarc=pass (або точну помилку) так, як це побачив одержувач. Це і є істина в останній інстанції.
Спостерігайте за звітами DMARC протягом кількох тижнів, перш ніж переходити від p=none до примусу.

Поширені помилки налаштування

Симптом	Звична причина та виправлення
SPF `permerror`	Два записи SPF або понад 10 DNS-запитів. Об'єднайте в один запис; приберіть невикористані `include:`.
Легітимна пошта провалює SPF	Відправник, якого ви забули авторизувати, або пошту переслали. Додайте відправника; для пересилання покладайтеся на вирівнювання DKIM+DMARC.
DKIM `fail` (хеш тіла)	Щось переписало повідомлення в дорозі (футер списку розсилки, поштовий пристрій). Підписуйте з relaxed-канонізацією; виключайте нестабільні заголовки.
DMARC провалюється попри прохід SPF/DKIM	Немає вирівнювання — домен, що пройшов, не є вашим доменом `From:`. Опублікуйте DKIM цього відправника під вашим власним доменом.
Субдомени підробляють	Немає політики для субдоменів. Додайте `sp=reject` до запису DMARC.

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