Як перевірити SPF, DKIM і DMARC домену перед холодною розсилкою

Один неправильний символ в SPF-записі — і поштові сервіси починають ставити під сумнів кожен лист із домену, навіть якщо адресат чекає на нього. Для холодної B2B-розсилки з малими щоденними обсягами це критично: тут немає запасу у вигляді тисяч листів, які «переживуть» частину, що впала в спам. Ця стаття — практичний spf dkim dmarc check, який варто зробити до, а не після старту кампанії.

Чому SPF-запис визначає долю холодної B2B-розсилки

SPF (Sender Policy Framework) — це TXT-запис у DNS домену, який перелічує сервери, яким дозволено відправляти пошту від його імені. Gmail, Outlook і корпоративні поштові шлюзи звіряють цей список у момент прийому листа, ще до того, як людина його побачить. Якщо сервер відправника не входить у список — це вже сигнал ризику, навіть коли текст листа бездоганний.

У масовій розсилці одна битa частина бази губиться в загальному обсязі. У цільовому B2B cold email, де щодня йдуть десятки персоналізованих листів конкретним людям у конкретних компаніях, кожен лист важливий — і кожен неправильно автентифікований лист псує репутацію всього домену, а не тільки свою долю.

Тому spf dkim dmarc check — це не разова технічна формальність під час налаштування домену, а перевірка, яку варто повторювати щоразу, коли змінюється інфраструктура відправки: додається новий ESP, підключається LDM, змінюється хостинг корпоративної пошти.

Як зробити spf dkim dmarc check: покроково

Перевірка SPF, DKIM і DMARC займає кілька хвилин і не потребує доступу до самого поштового сервера — досатньо доступу до DNS-панелі домену або будь-якого публічного spf checker.

• Запросіть TXT-записи домену командою dig TXT назва_домену або через онлайн spf dkim dmarc checker
• Переконайтесь, що запис починається з v=spf1 — без цього рядок не є валідним SPF
• Порахуйте кількість DNS-лукапів у записі (include, a, mx, redirect) — RFC 7208 дозволяє максимум 10, більше означає permerror і повне ігнорування SPF поштовим сервісом
• Звірте список джерел відправки з реальністю: власний поштовий сервер, Google Workspace чи Microsoft 365, ESP, інфраструктура LDM — усе, звідки реально йдуть листи, має бути в записі
• Перевірте механізм у кінці запису: ~all (softfail, м'який режим на час прогріву домену) чи -all (hardfail, для домену з усталеною репутацією)
• Повторіть те саме для DKIM: TXT-запис за адресою селектор._domainkey.домен має містити публічний ключ
• Перевірте DMARC: TXT-запис _dmarc.домен має існувати і містити політику p=

SPF checker: на що дивитися в результатах перевірки

Результат spf dkim dmarc check зазвичай повертає один зі статусів: pass (сервер відправника входить у список), softfail (не входить, але запис дозволяє листу пройти з позначкою), hardfail (лист має бути відхилений або позначений як підозрілий) або permerror (запис синтаксично зламаний і поштовий сервіс його просто ігнорує — це найгірший з можливих сценаріїв, бо домен фактично залишається без захисту).

Найчастіша причина permerror, яку бачить будь-який dmarcian spf аналіз, — це не одна помилка в синтаксисі, а два окремі SPF-записи на одному домені. DNS-стандарт прямо забороняє більше одного SPF TXT-запису: якщо їх два, поштові сервіси не намагаються вгадати, який правильний, вони ігнорують обидва.

DKIM і DMARC: що перевіряти паралельно зі SPF

SPF відповідає на питання «чи мав право цей сервер відправити лист від імені домену». DKIM відповідає на інше питання — «чи не змінили лист по дорозі»: кожен вихідний лист підписується приватним ключем, а поштовий сервіс звіряє підпис із публічним ключем у DNS. Домен, з якого йде холодна розсилка, має мати активний DKIM-селектор саме для того сервісу, який фактично відправляє листи — часто компанії налаштовують DKIM для Google Workspace, а листи через LDM або інший ESP йдуть без підпису.

DMARC — це рівень, який поєднує SPF і DKIM і каже поштовому сервісу, що робити, якщо обидва провалились: нічого не робити (p=none, тільки збирати звіти), відправити в спам (p=quarantine) або відхилити (p=reject). Для домену, який тільки починає холодну розсилку, правильна послідовність — кілька тижнів на p=none для збору звітів, потім перехід на p=quarantine, і лише після впевненості у всіх джерелах відправки — на p=reject.

Скільки коштує ігнорувати SPF: вплив на доставлюваність

Різниця між доменом із коректним SPF/DKIM/DMARC і доменом із помилками в них — це не кілька відсотків, а зазвичай різниця між листом у папці «Вхідні» і листом, який людина ніколи не побачить. Для агентства чи sales-команди, що вимірює результат холодної розсилки відповідями в CRM, а не відкриттями, потрапляння в inbox — перша умова, без якої решта тексту листа не має значення.

Чек-лист перед стартом розсилки і як це перевіряє LDM

Найдорожчі помилки в SPF-записі — не рідкісні і не екзотичні, вони повторюються від домену до домену: другий SPF-запис, залишений після зміни поштового провайдера; нова платформа розсилки, додана до списку відправників у настройках сервісу, але не додана в DNS; DMARC, який роками стоїть на p=none і ніхто не дивиться звіти; DKIM, налаштований для корпоративної пошти, але не для сервісу, з якого реально йде холодна розсилка.

Перед підключенням будь-якого нового домену до розсилки в LDM команда робить той самий check spf dkim dmarc for domain, який описаний вище: звіряє список джерел відправки, рахує DNS-лукапи, перевіряє відсутність дублікатів SPF і статус DMARC-політики. Домен потрапляє в активну ротацію тільки після проходження цієї перевірки і періоду прогріву — це знижує ризик того, що технічна помилка в DNS зведе нанівець якісну персоналізацію листа.

• Один SPF-запис на домен, без дублікатів
• Усі реальні джерела відправки (корпоративна пошта, ESP, LDM) перелічені в SPF
• Кількість DNS-лукапів у SPF не перевищує 10
• DKIM-селектор активний саме для сервісу, який фактично відправляє листи
• DMARC-запис існує, і його політика відповідає етапу прогріву домену
• Перевірка повторена після будь-якої зміни поштової інфраструктури

Питання й відповіді