SPF проти DKIM проти DMARC: у чому різниця?

Що робить SPF?

SPF відповідає на одне питання: чи дозволено серверу, який доставив це повідомлення, надсилати для домену? Власник домену публікує TXT-запис, що починається з v=spf1 і перелічує дозволені джерела, наприклад include:_spf.protonmail.ch для Proton Mail. Одержувач порівнює IP-адресу з'єднання зі списком і отримує результат: pass, fail, softfail або neutral, залежно від кваліфікатора в кінці (-all, ~all або ?all).

SPF перевіряє envelope sender (MAIL FROM) і ім'я HELO, а не адресу From, яку бачить читач. Ця прогалина — причина, чому існує DMARC. SPF також має жорсткі обмеження: домен повинен мати лише один запис SPF, а оцінка зупиняється з постійною помилкою після 10 термів, що роблять DNS-запити (include, a, mx, ptr, exists, redirect). Повний метод описано в посібнику зі створення запису SPF.

Що робить DKIM?

DKIM відповідає на інше питання: чи підписано це повідомлення доменом, який воно заявляє, і чи дійшло воно без змін? Сервер-відправник підписує вибрані заголовки і тіло приватним ключем. Одержувач зчитує домен підпису (d=) і селектор (s=) із заголовка DKIM-Signature, отримує публічний ключ за selector._domainkey.domain у DNS і перевіряє підпис.

Оскільки підпис іде разом з повідомленням, DKIM переживає переадресацію, якщо пересилач залишає повідомлення незмінним, чого SPF не робить, бо пересилач надсилає з власної IP-адреси. RFC 6376 каже, що підписувачі мають використовувати RSA-ключі щонайменше 1024 біти для довгоживучих ключів і рекомендує нові селектори при зміні ключів. Провайдери публікують ключі за вас: три CNAME-записи для Proton Mail і Fastmail, чотири для Mailbox.org. Подробиці — у посібнику зі налаштування DKIM.

Що робить DMARC?

DMARC пов'язує SPF і DKIM з видимим доменом From і каже одержувачам, що робити, коли жодна з перевірок не збігається. Повідомлення проходить DMARC, коли SPF або DKIM проходить і домен, який пройшов автентифікацію, збігається з доменом From. Вирівнювання за замовчуванням слабке (той самий організаційний домен), а строге — коли задано aspf=s або adkim=s.

Запис розташовано за адресою _dmarc.yourdomain і містить політику: p=none (лише моніторинг), p=quarantine (вважати підозрілим) або p=reject (відхиляти). Адреса rua отримує сукупні звіти, які показують, хто надсилає пошту від вашого імені. RFC 9989, опублікований у травні 2026 року, є чинною специфікацією; він замінює RFC 7489, прибирає тег pct і додає прапорець тестування t. Перехід від моніторингу до відхилення описано в посібнику з налаштування DMARC.

Чи потрібні всі три?

Так: власний домен, що надсилає пошту, має публікувати SPF, DKIM і DMARC, бо великі одержувачі їх вимагають. Google вимагає для відправників понад 5,000 листів на день до Gmail SPF, DKIM і запис DMARC (достатньо політики none). Microsoft вимагає те саме від відправників до Outlook.com понад 5,000 на день з 5 травня 2025 року, а Yahoo вимагає SPF, DKIM і DMARC і від масових відправників.

Особиста скринька надсилає значно менше, тож ці пороги на вас не діють. Записи все одно вирішують, чи дійде ваша пошта до вхідних, і не дають іншим підробляти вашу адресу. За підрахунком Postelva від 12 листопада 2026 року з довідкових сторінок провайдерів, повна установка Proton Mail займає 8 записів DNS, повна установка Mailbox.org — 11, з яких 3 і 4 — ключі DKIM. Записи MX розглянуто в що таке MX-запис.

Які помилки ламають усі три записи?

Три помилки спричиняють більшість збоїв: другий запис SPF, більше 10 пошуків і політика DMARC, встановлена занадто строго і занадто рано. Домен з двома записами SPF дає постійну помилку, тож додайте include нового провайдера до наявного запису. Коли накопичуються поштовий хост, сервіс розсилок і служба підтримки, кількість пошуків може перевищити 10, і запис тоді не проходить для жодного відправника. Mailbox.org і Proton обидва радять починати DMARC з p=none, а Mailbox.org попереджає, що надто рано застосована строга політика може відхиляти легітимну пошту.

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

Як три записи працюють разом для одного повідомлення?

Одержувач запускає SPF і DKIM, потім DMARC поєднує результати. Візьмімо лист від [email protected], надісланий через Proton Mail. SPF проходить, якщо сервер з'єднання є у списку _spf.protonmail.ch. DKIM проходить, якщо підпис, зроблений ключем під yourname.com, перевіряється. DMARC тоді перевіряє, чи пройшов принаймні один із двох з yourname.com у вирівняному ідентифікаторі. Якщо так, повідомлення проходить; якщо ні, одержувач застосовує вашу політику і записує результат у наступний сукупний звіт.

RFC 9989 зазначає, що домен з політикою p=reject не повинен покладатися лише на SPF і має підписувати з DKIM, бо SPF ламається при переадресації. ARC (RFC 8617), експериментальний стандарт, дозволяє пересилачам фіксувати початкові результати, хоча він не входить до вашого власного налаштування. Після публікації записів перевірте їх командою dig, перш ніж посилювати будь-яку політику.

Стисле визначення: SPF авторизує сервери, DKIM автентифікує повідомлення, а DMARC забезпечує збіг із доменом From і звітує про результат.