Перевірка SPF, DKIM і DMARC вашого домену

Що показує перевірка SPF, DKIM і DMARC

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

Якщо записів немає або вони надто мʼякі, будь-хто може вписати ваш домен у поле «Від» фішингового листа, а ваші власні рахунки частіше потрапляють у спам.

Це частина безкоштовної зовнішньої перевірки безпеки сайту. Ми читаємо лише публічні записи DNS і файл політики MTA-STS: до ваших поштових серверів не підключаємося і жодних листів не надсилаємо.

Що перевіряємо в кожному записі

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

Окремо позначаємо redirect= у SPF на імʼя без SPF, звіти DMARC на чужий домен, який не погодився їх приймати, мʼяке вирівнювання DMARC і адреси домену, видимі на сайті відкритим текстом.

DKIM і селектори: чому «не знайдено» - ще не висновок

Ключ DKIM лежить під імʼям, яке обирає ваш поштовий сервіс. Це імʼя називають селектором, наприклад selector1._domainkey.example.com. Сервер-отримувач дізнається його з тегу s= у підписі кожного листа (RFC 6376). Ззовні списку селекторів не прочитати.

Тому ми пробуємо поширені імена: selector1 і selector2 (Microsoft 365), google, default, k1, s1, dkim, mail та інші. Якщо на головній є форма розсилки Brevo, Mailchimp, Klaviyo чи Mailjet, пробуємо ще й типові імена цього сервісу. А також питаємо DNS про випадкове імʼя: деякі зони однаково відповідають на будь-який запит, і тоді збіг нічого не означає.

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

Розсилки й вимоги до масових відправників

Google вимагає від тих, хто надсилає близько 5000 або більше листів на добу на особисті акаунти Gmail, налаштувати SPF, DKIM і DMARC, а домен у полі «Від» має збігатися з доменом SPF або DKIM. Політики p=none для цієї вимоги достатньо. Yahoo чекає від масових відправників SPF, DKIM і DMARC щонайменше з p=none. Microsoft з 5 травня 2025 року вимагає SPF, DKIM і DMARC від доменів, що шлють понад 5000 листів на добу на Outlook.com (правила Outlook.com для відправників).

Коли перевірка бачить на головній сервіс розсилок, у звіті зʼявляється окремий рядок: чи підписує цей сервіс листи вашим доменом і чи є DMARC. Це підказка, а не аудит обсягів вашої розсилки.

Що виправити першим

• Лишіть рівно один запис SPF, завершіть його на ~all або -all і приберіть сервіси, якими вже не користуєтеся.
• Опублікуйте DMARC з p=none і адресою rua, два-чотири тижні читайте звіти, потім перейдіть на p=quarantine, а згодом на p=reject.
• Увімкніть підпис DKIM у кожному сервісі, що шле пошту від вашого імені, і опублікуйте його ключ.
• Якщо домен приймає пошту, додайте MTA-STS у режимі testing разом із TLS-RPT, а потім перемкніть на enforce.
• Якщо домен не шле пошти взагалі, опублікуйте v=spf1 -all: жоден сервер не має права слати від його імені.

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

Чого ця перевірка не робить

• Не підключається до ваших поштових серверів, не перевіряє STARTTLS і не надсилає тестових листів.
• Не бачить справжніх листів, тож не доводить, що підпис DKIM проходить, а домен у полі «Від» справді вирівняний. Це покажуть ваші звіти DMARC.
• Шукає ключі DKIM лише на поширених іменах селекторів. Поля для власного селектора поки немає.
• Кількість DNS-запитів SPF рахує приблизно: записи include розгортає на один рівень.
• Не перевіряє чорних списків, репутації відправника, BIMI і ваших звітів DMARC.
• Слабкий запис означає слабший захист, а не доказ того, що вашу пошту вже підробляли.