Налаштування DKIM SPF DMARC для домену: повний посібник із поштової автентифікації
Пошта й досі залишається однією з найвразливіших точок будь-якого домену. Сайт може бути акуратно зверстаний, сервер — захищений, але якщо листи від імені компанії легко підробити, проблеми почнуться дуже швидко: фішингові розсилки, скарги користувачів, падіння довіри і, у гіршому випадку, погіршення доставлюваності ваших власних листів. Саме тому налаштування DKIM SPF DMARC для домену — не «технічна дрібниця», а базова гігієна поштової інфраструктури та важливе налаштування поштової автентифікації.
Якщо ви колись стикалися із ситуацією, коли листи потрапляють у спам без видимої причини, або клієнт пише: «Ви точно надсилали цей лист?» — отже, час зайнятися автентифікацією домену вже настав. І чим раніше, тим краще. У цьому сенсі пошта влаштована майже як сайт: без регулярної уваги навіть хороша система починає поводитися непередбачувано. Про це ми часто говоримо і в контексті безпеки сайту: захист — це не один плагін і не одне налаштування, а зв’язка рішень, які працюють разом. Саме тому так важливо розуміти, як налаштувати DKIM SPF DMARC без зайвих помилок і з урахуванням усіх джерел надсилання.
Що таке DKIM, SPF і DMARC та навіщо вони потрібні
DKIM, SPF і DMARC розв’язують схожу задачу, але роблять це різними способами. Важливо не плутати їхні ролі, якщо ви плануєте налаштування поштової автентифікації для домену.
SPF відповідає на запитання: «Які сервери взагалі мають право надсилати листи від імені цього домену?» У DNS ви вказуєте список дозволених відправників, а поштовий сервер отримувача звіряє його з фактичною IP-адресою, з якої прийшов лист.
DKIM додає до листа криптографічний підпис. Отримувач перевіряє, чи справді лист було підписано вашим доменом і чи не змінювався він у дорозі. Це вже не просто список дозволів, а підтвердження автентичності вмісту й домену-відправника.
DMARC пов’язує SPF і DKIM в єдину політику. Він каже поштовим системам: якщо лист не пройшов перевірки, що з ним робити — пропустити, відправити в карантин чи відхилити зовсім. Крім того, DMARC дозволяє отримувати звіти про те, хто і як намагається надсилати пошту від вашого домену.
Саме тому ці механізми потрібні не лише для захисту від підробки листів. Вони напряму впливають на доставлюваність. Поштові сервіси дедалі частіше дивляться не лише на зміст листа, а й на те, наскільки акуратно оформлена його автентифікація. Для корпоративного домену це критично: одна справа — втратити кілька повідомлень, і зовсім інша — регулярно потрапляти в спам у клієнтів, партнерів і сервісів.
Як працюють DKIM SPF DMARC разом
Окремо кожен протокол корисний, але разом вони дають набагато надійнішу схему перевірки.
SPF підтверджує, що лист надійшов із дозволеного сервера. Але в нього є обмеження: якщо лист пересилається далі, SPF може «зламатися», бо змінюється IP-адреса останнього відправника. DKIM у таких ситуаціях часто виручає, тому що підпис зберігається навіть під час пересилання, якщо в лист не вносилися зміни.
DMARC, своєю чергою, перевіряє не просто наявність SPF і DKIM, а їхню узгодженість із доменом у полі From. Це важливий момент. Можна мати лист, який технічно підписаний, але при цьому користувач бачить у відправнику зовсім інший домен. DMARC якраз допомагає не допустити такої плутанини й блокувати явну підробку.
Якщо спростити до побутової аналогії: SPF — це список перепусток на вході, DKIM — печатка на документі, DMARC — правило охорони, що робити з відвідувачами без перепустки і без печатки. Один захід без іншого залишає лазівку.
Тому впроваджувати їх потрібно комплексно. Це особливо важливо для компаній, які використовують кілька джерел надсилання листів: CRM, сервіси розсилок, тикетні системи, форми зворотного зв’язку, транзакційні сповіщення. Якщо не узгодити все це між собою, поштова інфраструктура починає працювати як набір непов’язаних островів.
Підготовка до налаштування: домен, DNS і поштовий сервіс
Перед тим як налаштовувати записи, потрібно зрозуміти, хто саме надсилає пошту від імені домену. Це може бути один поштовий сервіс, а може бути кілька: корпоративна пошта, сервіс розсилок, платформа для сповіщень, окремий SMTP для сайту. Без цієї картини ви ризикуєте дозволити зайве або, навпаки, випадково заблокувати потрібне джерело.
Потрібні будуть доступи до панелі DNS домену. Зазвичай це інтерфейс реєстратора, хостингу або окремого DNS-провайдера. Важливо знати, де саме редагуються записи: інколи людина шукає проблему в поштовому сервісі, а запис насправді живе в іншого провайдера.
Ще один обов’язковий крок — зібрати відомості від поштового провайдера. Зазвичай потрібні:
- SPF-дані або рекомендований SPF-запис;
- DKIM-ключ або інструкція з його генерації;
- ім’я селектора DKIM, якщо провайдер його використовує;
- рекомендації щодо DMARC;
- список доменів і піддоменів, з яких іде надсилання;
- розуміння, які сервіси надсилають листи зараз, а які підключаться пізніше.
Якщо ви працюєте не з новим доменом, корисно спочатку подивитися на поточну конфігурацію. Іноді SPF уже існує, але в ньому перелічені старі сервіси. Іноді DKIM колись було увімкнено, але потім розсилка переїхала до іншого провайдера. Буває й так, що DMARC є, але на рівні «для галочки», без звітів і без осмисленої політики. Такі речі краще виявити до правок, а не після скарг від користувачів.
Налаштування SPF для домену
SPF-запис публікується в DNS як TXT-запис. Його завдання — перелічити дозволені джерела надсилання. Базовий принцип простий: ви вказуєте, які сервіси й сервери мають право надсилати пошту від імені домену, а решта повинна вважатися неавторизованими.
Під час налаштування важливо пам’ятати: у домену має бути один SPF-запис. Не два, не три — один. Якщо додати кілька TXT-записів із SPF, багато отримувачів трактуватимуть це як помилку. Це одна з найпоширеніших проблем під час підтримки поштової інфраструктури, і налаштування поштової автентифікації тут особливо чутливе до деталей.
Типова логіка SPF будується навколо механізмів на кшталт include, ip4, ip6 і mx. На практиці це означає, що в запис можна включити сторонній сервіс розсилок, конкретні IP-адреси або поштові сервери домену. Але тут є нюанс: кожна додаткова сутність робить запис довшим і складнішим.
Ще одна часта помилка — надмірно широкий охоплення. Іноді в записі ставлять надто м’які правила, щоб «нічого не зламати». У результаті фактично дозволяється більше відправників, ніж потрібно. Це зручніше на старті, але гірше для безпеки. Якщо вам важливий захист від підробки листів, SPF має бути точним, а не «приблизно правильним».
Після публікації запису перевірте, що він справді видно в DNS і він відповідає поточним джерелам надсилання. Якщо ви надсилаєте листи через кілька платформ, перевірте кожну. Інакше легко отримати ситуацію, коли листи з CRM проходять, а сповіщення сайту — ні.
Налаштування DKIM: генерація ключа і публікація DNS-запису
DKIM працює через пару ключів: закритий зберігається у відправника, відкритий публікується в DNS. Коли лист відправляється, сервер підписує його закритим ключем. Отримувач бере публічний ключ із DNS і перевіряє підпис. Якщо все збігається, лист вважається автентичним.
Зазвичай DKIM налаштовується через поштовий сервіс. У панелі провайдера ви обираєте домен, генеруєте ключ або отримуєте вже готові параметри, а потім публікуєте TXT-запис із публічною частиною ключа. Часто в записі вказується селектор — спеціальне ім’я, яке допомагає відрізнити один ключ від іншого. Це особливо зручно, якщо в домену кілька систем надсилання або ви плануєте ротацію ключів.
Після публікації DNS-запису потрібно увімкнути підписування вихідних листів у самому сервісі. Без цього запис у DNS марний: ключ лежатиме в зоні, але листи залишаться непідписаними. З точки зору налагодження це часта пастка: «Запис додали, а DKIM не працює». Насправді просто не увімкнено підписування на боці відправника, і налаштування поштової автентифікації залишається незавершеним.
Технічно важливо перевірити:
- чи збігається селектор у DNS і в налаштуваннях сервісу;
- чи коректно опублікований TXT-запис;
- чи не обрізано ключ під час вставлення;
- чи підписуються всі потрібні типи листів, а не лише частина з них;
- чи не змінюється лист після підпису, наприклад через додаткову обробку з боку проміжного сервісу.
DKIM особливо корисний для транзакційних листів: підтвердження реєстрації, скидання пароля, сповіщення про замовлення. Такі повідомлення повинні доходити стабільно. Якщо на сайті добре організована структура і підтримка після запуску, як у випадку з підтримкою сайту після запуску, поштова автентифікація зазвичай входить до списку речей, які не відкладають «на потім». І правильно роблять.
Налаштування DMARC політики та звітів
DMARC додає керованість. Без нього ви можете бачити SPF і DKIM окремо, але не мати чіткого правила, як поводитися з підозрілими листами. DMARC-запис теж публікується в DNS як TXT-запис, зазвичай на піддомені _dmarc.
На старті часто обирають політику none. Це режим спостереження: листи не блокуються, але власник домену отримує звіти й може побачити, хто надсилає пошту, чи проходять перевірки і де є прогалини. Це розумний перший крок, особливо якщо інфраструктура складна і ви не хочете раптово відрізати законні листи.
Після періоду спостереження політику можна посилювати: quarantine надсилає сумнівні листи у спам або карантин, а reject відхиляє їх повністю. Який варіант обрати — залежить від зрілості вашої поштової схеми та впевненості в тому, що всі легітимні джерела вже враховані.
У DMARC-звітах корисно шукати не лише помилки, а й несподівані джерела надсилання. Іноді там спливають старі сервіси, тестові платформи, забуті інтеграції. І це хороший привід навести лад.
Якщо ви впроваджуєте DMARC для корпоративного домену, має сенс спочатку перевірити, чи не зав’язані важливі процеси на сторонні сервіси. Наприклад, якщо сайт активно використовує форми й email-сповіщення, а структура сайту вибудувана так, що листи йдуть через кілька модулів, корисно заздалегідь узгодити всі точки надсилання. Подібні питання ми розбираємо і в темі структури корпоративного сайту: чим ясніша архітектура, тим менше сюрпризів на рівні пошти, а налаштування поштової автентифікації проходить спокійніше.
Перевірка й налагодження після впровадження
Після налаштування не варто покладатися на відчуття, що «ніби все працює». Перевірка має бути усвідомленою й послідовною.
Спочатку переконайтеся, що SPF-запис видно в DNS і він містить лише актуальні джерела. Потім надішліть тестовий лист і перевірте заголовки на боці отримувача: там зазвичай видно, чи пройшов SPF, чи є DKIM-підпис, чи спрацював DMARC.
Якщо лист не проходить перевірку, шукайте причину по ланцюжку:
- чи правильно вказані записи в DNS;
- чи минуло достатньо часу для оновлення DNS;
- чи збігається домен у From із доменом підпису;
- чи підписує лист саме той сервіс, який ви очікуєте;
- чи не втручається в лист проміжна система, яка змінює вміст після підпису.
Дуже корисно також мати короткий чекліст і регулярно повертатися до нього після змін у поштових сервісах, доменах або інтеграціях. Саме так поштова автентифікація домену залишається стабільною навіть тоді, коли інфраструктура поступово росте й змінюється.
