SPF перевірка

Перевірка SPF онлайн: що показує звіт

Перевірка SPF-запису домену починається із запиту TXT-записів у DNS. Інструмент бере запис, що починається з v=spf1, розбирає його на механізми й показує оцінку від 0 до 100, сам рядок, кількість механізмів, кількість DNS-запитів і підсумкову політику. Оцінку визначає передусім кваліфікатор all:

Якщо механізмів, що потребують DNS-запиту, понад десять, від оцінки віднімається ще 30 балів. Зверніть увагу: лічильник рахує механізми самого запису. Кожен include — один запит, але в підключеному записі можуть бути власні include, і вони теж витрачають ліміт. Розгорнути ланцюжок можна командами:

dig +short TXT example.com
dig +short TXT spf.protection.outlook.com

Звіряйте й вихідний рядок: якщо механізму all у записі немає, за стандартом для неперелічених серверів результат — neutral. А all без знака дорівнює +all.

Як влаштований SPF-запис

Механізми перевіряються зліва направо до першого збігу. Перед механізмом може стояти кваліфікатор: + (pass, за замовчуванням), - (fail), ~ (softfail), ? (neutral).

Ліміт 10 DNS-запитів

RFC 7208 дозволяє одержувачу зробити не більше десяти DNS-запитів під час перевірки SPF, вкладені include теж рахуються. Перевищення дає permerror, і SPF вважається непройденим для всіх листів домену. Найчастіше ліміт вичерпується поступово: корпоративна пошта, CRM, сервіс розсилок, платформа підтримки — кожен додає свій include.

• Видаліть include сервісів, від яких відмовилися.
• Приберіть a і mx, якщо вебсервер і вхідна пошта не надсилають листи від імені домену.
• Власні сервери вказуйте через ip4/ip6 — вони не витрачають ліміт.
• Масові розсилки переносьте на піддомен із власним SPF — у нього окремий ліміт.

Типові помилки SPF

1. Два записи v=spf1. Дозволено лише один; два — це permerror. Механізми треба об'єднати в один рядок. Звіт показує перший знайдений запис, тому кількість записів перевірте через dig TXT example.com.
2. +all — дозволяє будь-кому надсилати пошту від вашого імені.
3. Синтаксичні одруки: пробіл після двокрапки (include: sendgrid.net), v=spf без одиниці, IPv6-адреса в ip4.
4. Піддомени не успадковують SPF. Для shop.example.com потрібен окремий запис, а якщо з нього не надсилають листи — v=spf1 -all.
5. Рядок понад 255 символів в одному TXT-рядку: довгий запис треба розбити на кілька рядків у лапках, DNS-панель зазвичай робить це сама.

Приклади для Google Workspace, Microsoft 365, SendGrid

Тільки Google Workspace:

v=spf1 include:_spf.google.com ~all

Microsoft 365 і транзакційні листи через SendGrid:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

Google Workspace, Mailgun і власний сервер повідомлень:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~all

Домен, з якого пошта не надсилається взагалі (лендинг, парковий домен):

v=spf1 -all

Частина сервісів розсилок перевіряє SPF не основного домену, а піддомену повернення (Return-Path), який вони просять спрямувати на себе CNAME-записом. Тож спершу читайте інструкцію сервісу, а не додавайте include навмання.

Де і як додати SPF-запис

SPF редагують там, де розміщена DNS-зона домену: у реєстратора, хостера або в Cloudflare. Визначальне не те, де куплено домен, а чиї NS-сервери в ньому прописані — їх видно у WHOIS.

1. Знайдіть наявний TXT-запис із v=spf1 на корені домену (ім'я @). Якщо він є — редагуйте його, а не додавайте другий.
2. Тип — TXT, ім'я — @ (для піддомену — лише його частина, наприклад mail), значення — увесь запис, TTL — 3600 або «авто».
3. Лапки здебільшого панель додає сама; не вкладайте одні лапки в інші.
4. У Cloudflare TXT-записи не проксуються, додатково нічого вмикати не потрібно.

Як перевірити SPF у заголовках листа

DNS показує, що опубліковано, а заголовки листа — що побачив одержувач. У Gmail відкрийте лист → «Показати оригінал»: у рядку SPF буде PASS, SOFTFAIL, FAIL, NEUTRAL або PERMERROR разом з IP відправника. У сирому заголовку шукайте Authentication-Results:

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of [email protected] does not
       designate 198.51.100.25 as permitted sender) [email protected]

Звідси зрозуміло, який домен перевірявся (smtp.mailfrom) і який IP не внесено до запису. Додайте його через ip4 або через include сервісу, якому належить ця адреса. permerror майже завжди означає два записи або перевищення ліміту запитів; temperror — тимчасову проблему з DNS-серверами домену.

~all чи -all

-all суворіший, але деякі сервери відхиляють лист за SPF ще до перевірки DKIM, і переслані листи (де SPF ламається неминуче) губляться. Тому за налаштованого DMARC часто залишають ~all, а остаточне рішення приймає DMARC. Для доменів без пошти — тільки -all.

SPF пройдено, а листи все одно в спамі

SPF лише підтверджує, що сервер має право надсилати пошту від імені домену. Репутацію він не створює. Якщо в заголовках spf=pass, а листи падають у спам, перевірте далі по ланцюжку:

• чи є в IP відправника PTR-запис і чи збігається він із прямим DNS — це покаже зворотний DNS;
• чи не потрапив IP у DNSBL-списки — перевірка IP у чорних списках;
• чи проходить DKIM і чи збігається домен підпису з доменом у From;
• чи не зламаний сайт або поштова скринька, з яких іде спам від вашого імені.

Для свіжого домену чи нового IP репутація набирається поступово: різкий старт розсилки на тисячі адрес сам по собі є сигналом для фільтрів.

SPF разом із DKIM і DMARC

SPF перевіряє адресу конверта (Return-Path), а не поле «Від», яке бачить людина. DKIM підписує лист ключем домену, DMARC вимагає, щоб SPF або DKIM збігалися з доменом у From, і каже одержувачу, що робити з рештою. Від 2024 року Gmail і Yahoo вимагають усі три механізми від масових відправників. Після SPF перевірте DKIM-ключ, DMARC-політику та MX-записи домену; решту записів покаже DNS lookup. Після зміни запису зачекайте, поки мине TTL, і повторіть перевірку.