Посібник із налаштування SPF і DKIM для пошти

Посібник із налаштування автентифікації електронної пошти: пояснення SPF і DKIM

Якщо ви надсилаєте листи з домену, який для вас важливий, автентифікація — не опція, а необхідність. Саме вона повідомляє поштовим серверам, що отримують листи: «Так, це повідомлення справді надійшло від нас». Без неї ваша пошта може виглядати підозрілою, навіть якщо її вміст цілком законний. З нею ж ви даєте провайдерам поштових скриньок чіткіший сигнал, зменшуєте ризик підробки та ускладнюєте життя фішерам, які намагаються позичити назву вашого бренду для власних схем.

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

Це коротка версія. А довша — більш практична: вам потрібно знати, що саме публікувати в DNS, що потрібно вашому поштовому провайдеру та як переконатися, що після запуску все працює як слід.

Що таке автентифікація електронної пошти і чому це важливо

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

Чому це настільки важливо? Тому що електронну пошту й досі дуже легко підробити. Фальшиве повідомлення з вашим доменом у полі From може заплутати клієнтів, підірвати довіру та створити навантаження для служби підтримки. Автентифікація не зупиняє кожну спробу зловживання, але дає поштовим сервісам і фільтрам безпеки набагато кращі докази. У результаті зазвичай менше шансів на підробку та кращі перспективи потрапляння до вхідних.

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

Корисно мислити про автентифікацію так: це не лише про безпеку і не лише про доставлення. Це і те, і інше. Коли технічні докази чіткі, поштові сервери можуть швидше вам довіряти, а зловмисникам важче прикидатися вами.

Як працює автентифікація електронної пошти через SPF, DKIM і DMARC

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

SPF, або Sender Policy Framework, перевіряє, чи дозволено IP-адресі відправника надсилати пошту для домену. Це працює через публікацію в DNS списку дозволених джерел надсилання. Коли сервер-отримувач отримує повідомлення, він порівнює IP відправника з цим списком.

DKIM, або DomainKeys Identified Mail, підписує повідомлення приватним ключем. Сервер-отримувач отримує відкритий ключ із DNS і використовує його для перевірки підпису. Якщо підпис збігається, це означає, що повідомлення було підписано доменом, який контролює цей ключ, і що підписані частини листа не змінювалися під час передачі.

DMARC, або Domain-based Message Authentication, Reporting, and Conformance, об’єднує SPF і DKIM. Він перевіряє, чи домен, видимий користувачу, узгоджується з доменами, які пройшли SPF або DKIM. Потім він повідомляє отримувача, що робити, якщо щось не збігається: лише спостерігати, помістити в карантин або відхилити.

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

У більшості налаштувань саме SPF і DKIM — це перші записи, які потрібно привести до ладу. Коли вони стабільні, DMARC стає значно кориснішим, бо має надійні сигнали для оцінки. Якщо ви тільки починаєте, важливо спершу зрозуміти що таке DMARC, а вже потім налаштовувати політики поверх SPF і DKIM.

Налаштування SPF: додайте дозволені джерела надсилання в DNS

Налаштування SPF починається з одного запитання: хто саме має право надсилати пошту від імені вашого домену? Звучить очевидно, але на практиці це часто означає більше ніж одну систему. Ваш сайт може надсилати скидання пароля через одного провайдера, маркетингова команда — користуватися іншою платформою, а helpdesk-система — відправляти відповіді служби підтримки через третій сервіс.

Спочатку складіть список усіх легітимних відправників. Додайте основного поштового хостера, транзакційного провайдера, CRM-платформу та будь-яку інфраструктуру, що надсилає листи від імені вашого домену. Будьте тут уважні. Якщо ви забудете про одне джерело, пошта з цієї системи може не пройти SPF. Якщо ж додасте джерело, яке вже не використовуєте, ви відкриєте непотрібні двері.

Далі створіть один SPF-запис для домену. SPF публікується в DNS як TXT-запис. Його вміст — це політика, яка зазвичай починається з v=spf1, а далі містить дозволені механізми, такі як ip4, ip6, include або a, і завершується кваліфікатором політики на кшталт -all або ~all. Точний синтаксис залежить від вашого середовища, але суть завжди одна: визначити, хто може надсилати, а потім указати, що робити з усім іншим.

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

Базовий робочий процес виглядає так:

1. Складіть перелік усіх платформ, що надсилають пошту від імені домену.
2. Зберіть SPF-інструкції від кожного провайдера.
3. Об’єднайте їх в один SPF TXT-запис.
4. Опублікуйте запис у DNS.
5. Зачекайте на поширення DNS і протестуйте результат.

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

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

Налаштування DKIM: підписуйте вихідні листи криптографічними ключами

DKIM — це частина налаштування, яка здається трохи технічнішою, але сама концепція проста. Ваша поштовa система підписує вихідні повідомлення приватним ключем. Відповідний відкритий ключ ви публікуєте в DNS. Коли повідомлення приходить, отримувач перевіряє, чи збігається підпис із опублікованим ключем і чи збережено підписані частини листа без змін.

Перший крок — генерація ключів. Багато поштових платформ створюють DKIM-ключі за вас, і це часто найпростіший шлях. Якщо ви керуєте власною поштовою інфраструктурою, можливо, доведеться створити пару ключів самостійно. Головне — щоб приватний ключ залишався на стороні відправника, а в DNS публікувався лише відкритий ключ.

Коли відкритий ключ готовий, ви створюєте DNS TXT-запис під селектором. Селектор — це мітка, яка позначає конкретний ключ, що використовується. Завдяки цьому ви зможете пізніше змінити ключі, не ламаючи все одразу. Типовий DKIM-запис містить селектор, домен і значення відкритого ключа.

Після публікації DNS-запису увімкніть DKIM-підписування у вашому поштовому провайдері або MTA. Цей крок залежить від платформи. Деякі сервіси вимагають вставити селектор і приватний ключ у панель керування. Інші дозволяють увімкнути підписування однією кнопкою після перевірки DNS. У будь-якому разі переконайтеся, що система підписує правильний домен у From або близько пов’язаний домен, залежно від вашої конфігурації.

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

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

Як тестувати й перевіряти свої записи

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

Почніть із базової перевірки DNS. Ви можете прямо запитати SPF- і DKIM-TXT-записи, щоб підтвердити їхню наявність і переконатися, що вони містять очікувані значення. Перевірте домен, селектор і сам текст запису. Дрібні помилки мають значення. Один зайвий символ у DKIM-ключі може зробити весь підпис марним.

Далі надішліть лист у власну поштову скриньку та перегляньте повні заголовки. Більшість великих поштових провайдерів показують результати автентифікації в деталях повідомлення. Зверніть увагу на SPF pass або fail, DKIM pass або fail і будь-який результат DMARC, що стосується вирівнювання.

Також можна скористатися зовнішніми інструментами тестування, щоб побачити налаштування очима отримувача. Такі інструменти часто підсумовують, чи правильно резолвляться ваші записи і чи проходить повідомлення перевірки автентифікації. Для більш структурованих сценаріїв тестування Інструменти для тестування доставлення електронної пошти можуть бути дуже корисними, якщо вам потрібна ще одна думка.

Коли ви переглядаєте результати, не зупиняйтеся на «pass» або «fail». Дивіться на причину. Успіх із попередженнями може натякати на майбутню проблему, особливо якщо ви збираєтеся змінювати провайдера або додавати нове джерело надсилання. Невдача може вказувати на поширення DNS, проблеми з вирівнюванням або неочікуваного відправника.

Якщо ви використовуєте звіти DMARC, вони особливо корисні для розуміння того, що відбувається у вашій поштовій екосистемі. Вони можуть виявити забуті сервіси, застарілі IP-адреси або неавторизований трафік, який ви ніколи не помітили б з одного тестового листа.

Поширені помилки під час налаштування і як їх виправити

Більшість проблем з автентифікацією починаються з дрібниць: пропущеного відправника, неправильного селектора, помилки в DNS або конфлікту між кількома сервісами. Саме тому корисно перевіряти не лише записи, а й увесь шлях повідомлення від відправника до скриньки.