Як налаштувати SPF, DKIM і DMARC у Cloudflare

Якщо ви намагаєтеся розібратися, як налаштувати SPF DKIM DMARC у Cloudflare, почніть із простої істини: Cloudflare зберігає DNS-записи, але значення для них надає ваш поштовий провайдер. Звучить незначно. Але це не дрібниця.

Cloudflare — це місце, де ці записи «живуть», тож ви редагуєте TXT або CNAME-записи в його DNS-панелі. Актуальний SPF include-рядок, DKIM-селектор, відкритий ключ і DMARC-політика надходять від сервісу, який відправляє вашу пошту — чи то Google Workspace, Microsoft 365, SendGrid, Mailgun, чи інша платформа. Без цих значень ви дієте навмання.

1. З’ясуйте, що Cloudflare може і не може робити для автентифікації пошти

Cloudflare не вигадує значення SPF, DKIM чи DMARC. Воно лише публікує їх. Якщо ваш провайдер просить додати TXT-запис для SPF, Cloudflare може його розмістити. Якщо провайдер дає DKIM-селектор і CNAME-ціль, Cloudflare теж це підтримає. Але він не може вирішити, які сервери мають право надсилати пошту від вашого імені.

Це важливо, бо люди часто спершу відкривають Cloudflare й шукають чарівну кнопку. Такої немає. Вам потрібен точний вміст запису від вашого поштового сервісу ще до того, як ви торкнетеся DNS, інакше можна опублікувати запис, який проходить перевірку в панелі, але провалюється в реальній поштовій скриньці.

2. Зберіть DNS-значення з платформи, яка відправляє вашу пошту

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

Запишіть ці значення в одному місці. Використовуйте точні назви селекторів. Якщо провайдер дає вам два селектори, не перейменовуйте їх лише тому, що вони виглядають незграбно. Якщо в документації сказано, що запис має бути `_spf.example.net`, залиште саме так. Дрібні помилки у форматуванні можуть зіпсувати цілий день.

Тут корисна проста звичка: до входу в Cloudflare зведіть в одну таблицю назву відправника, hostname, тип запису та рядок призначення. Це прискорює редагування і допомагає уникнути поширеної помилки, коли правильне значення вставляють не в те поле імені.

3. Додайте SPF-запис у DNS Cloudflare

У Cloudflare відкрийте DNS і створіть або відредагуйте TXT-запис на корені домену, якщо ваш провайдер надсилає пошту з основного домену. Деякі сервіси використовують піддомен, наприклад `mail.example.com`, тож беріть саме той hostname, який вказує провайдер, а не той, який ви припускаєте. Один hostname. Один запис.

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

Типове SPF-значення містить механізми на кшталт `include:` або `ip4:`. Якщо ваш сервіс згодом додає ще одного відправника, оновіть наявний запис, а не додавайте новий. Дубльований SPF-запис може спричинити permerror, тобто системи-отримувачі можуть вважати перевірку такою, що не пройшла, навіть якщо окремі частини виглядають правильно.

Використовуйте ім’я запису, яке дає провайдер. Для кореневого домену Cloudflare часто показує `@` у полі імені. Для піддомену введіть точну мітку. Не ставте лапки навколо значення, якщо провайдер прямо не просить це зробити. Cloudflare зберігає текст як звичайний DNS-вміст.

4. Опублікуйте DKIM TXT або CNAME-записи в Cloudflare

У DKIM важливий селектор. Провайдер може дати вам TXT-запис на кшталт `selector1._domainkey` із довгим відкритим ключем, або може надати CNAME-запис, який вказує на інший hostname. Cloudflare підтримує обидва варіанти, але тип має відповідати тому, що вказав провайдер. TXT-значення в полі CNAME не допоможе.

Багато сервісів використовують два селектори. Це нормально. Google Workspace часто застосовує два ключі під час ротації, і інші провайдери роблять щось подібне, щоб один ключ можна було замінити без переривання доставки. Якщо відправник дає вам `s1` і `s2`, опублікуйте обидва записи. Якщо інший відправник використовує іншу сім’ю селекторів, тримайте ці записи окремо. Назви можуть здаватися повторюваними; записи — ні.

Вводьте DKIM hostname точно так, як його вказано. Якщо провайдер просить створити `selector1._domainkey.example.com`, використовуйте саме цю повну мітку в Cloudflare. Якщо провайдер дає CNAME-ціль, вставте призначення без змін. Cloudflare не потрібен переклад. Йому потрібна точність.

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

5. Створіть DMARC-запис у _dmarc

DMARC має розміщуватися в `_dmarc.yourdomain.com`. У Cloudflare створіть TXT-запис із точно такою назвою. Значення починається з `v=DMARC1`, а потім додається політика й необов’язкові теги. Поширений стартовий варіант — `p=none`, тому що він дає змогу збирати звіти, перш ніж ви щось блокуватимете. Це найменш агресивний початок.

Якщо ваша організація готова приймати звіти, додайте тег `rua` з адресою для зведених звітів і, за потреби, тег `ruf` для форензичних звітів. Використовуйте адресу, яку реально хтось перевіряє. Порожня скринька — не стратегія. Це пастка.

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

Cloudflare зберігає DMARC TXT-запис так само, як і будь-який інший текстовий запис, але деталі мають значення. Ім’я запису має бути `_dmarc`, а не `dmarc`, не `_dmarc1` і не кореневий домен. Рядок політики має відповідати синтаксису, який очікує ваш провайдер. Якщо пошта-платформа радить теги на кшталт `sp`, `adkim` або `aspf`, додавайте їх лише тоді, коли розумієте їхній ефект.

6. Перевірте DNS-налаштування Cloudflare, які можуть блокувати валідацію

У Cloudflare є один параметр, який створює більше плутанини, ніж мав би: проксування. Записи автентифікації пошти не повинні проксуватися. SPF, DKIM і DMARC живуть у DNS, а не за помаранчевою хмарою. Якщо ви випадково проксуватимете hostname, пов’язаний із поштою, ви змішаєте правила вебтрафіку з DNS-записами для email.

Назви записів — ще одна поширена проблема. DKIM-селектор, який має бути `selector1._domainkey`, можуть ввести як `selector1._domainkey.` із випадковою крапкою в кінці або як `selector1 domainkey` зі пробілом, скопійованим зі сторінки провайдера. Cloudflare приймає багато DNS-записів, але поштові системи менш поблажливі, ніж інтерфейс.

Старі записи теж можуть заважати. Якщо старий SPF TXT-запис лишився поруч із новим або застарілий DKIM CNAME усе ще веде до вже відключеного сервісу, валідація може зламатися так, ніби це випадковість. Видаляйте старий запис лише після того, як переконаєтеся, що він більше не потрібен. Так ви збережете роботу активного відправника.

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

7. Перевірте поширення записів і автентифікацію пошти з DNS, керованого Cloudflare

Після збереження записів дочекайтеся поширення DNS. Точний час залежить від TTL і кешу резолвера перед вами, тож не варто вважати, що запис уже видимий всюди в ту ж мить, коли Cloudflare показує, що його збережено. Перевірте зовні за допомогою DNS-інструмента і переконайтеся, що кожен запис повертає очікуване значення.

Потім надішліть реальний тестовий лист із сервісу, який використовує ці записи. Не тестуйте з випадкової скриньки, яка обходить ваш звичайний поштовий потік. Відкрийте заголовки повідомлення в поштовій скриньці отримувача й подивіться, чи SPF пройшов, DKIM пройшов, а DMARC показує pass для alignment. Лист усе одно може потрапити до спаму з інших причин, але результат автентифікації має показати, чи правильно налаштований DNS.

Однієї швидкої перевірки достатньо для першого проходу, але друга перевірка з іншої поштової скриньки дає кращий сигнал. Тест у Gmail і тест у Microsoft 365 можуть поводитися по-різному, якщо один резолвер ще короткий час бачить старий запис, а інший уже новий. Це не рідкість. Таке трапляється.

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

8. Оновлюйте записи, коли змінюється ваш поштовий провайдер

Поштові налаштування змінюються. Провайдер ротує DKIM-ключі, додається маркетингова платформа або транзакційний сервіс переноситься після міграції. Коли це стається, оновіть DNS-записи в Cloudflare до перемикання трафіку, а не після. Такий порядок рятує від дня зламаних підписів.

Ротація DKIM зазвичай є найчистішою зміною. Провайдер дає новий селектор і ключ, ви публікуєте їх у Cloudflare і чекаєте, поки новий селектор пройде валідацію, перш ніж прибрати старий. Під час переходу залишайте обидва активними, якщо це підтримує провайдер. Два селектори кращі, ніж одна зупинка.

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

Для команд, що відправляють пошту через кілька сервісів, обслуговування стає простішим, якщо одна людина відповідає за список дозволених відправників. У цьому списку мають бути сервіс, hostname, DKIM-селектор і дата останньої зміни. Проста таблиця підтримує послідовність змін у Cloudflare, а послідовність важливіша за хитромудрість.

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

Cloudflare робить публікацію простою, але записи все одно потребують дисципліни. Один відправник. Один SPF-запис. Кожен DKIM-селектор на своєму місці. Один DMARC-запис у `_dmarc`. Якщо тримати ці чотири пункти в порядку, решта — це переважно терпіння, кілька перевірок заголовків і готовність оновити DNS до наступної зміни платформи.

Якщо вам потрібно коротке практичне запитання, воно звучить так: як додати DMARC запис у Cloudflare так, щоб він одразу працював у поштових системах? Відповідь проста — дотримуйтеся точного імені `_dmarc`, використовуйте синтаксис `v=DMARC1` і зберігайте політику в одному TXT-записі.

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