Перевірка SPF/DKIM/DMARC

Що роблять три записи, по абзацу на кожен

SPF — це список серверів, яким дозволено надсилати пошту від імені вашого домену; його публікують у DNS. Сервер-отримувач бере домен із адреси відправника в конверті (envelope sender), завантажує список і перевіряє, чи є в ньому IP-адреса, з якої він отримав з’єднання. Це TXT-запис, що починається з v=spf1 і завершується вердиктом для всіх, кого немає в списку: -all означає відхилити, ~all — м’яку відмову (soft fail).

DKIM додає криптографічний підпис у заголовок кожного листа. У підписі вказано селектор, і отримувач бере відповідний відкритий ключ із TXT-запису за адресою selector._domainkey.вашдомен. Якщо ключ підтверджує підпис, лист підписала сторона, яка має закритий ключ, і дорогою його не змінювали. Селектор обирає той, хто підписує, тому перевірка не завжди може його вгадати.

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

Помилки, які шукає ця сторінка

Більшість збоїв дрібні, і їх знаходять, читаючи записи, а не надсилаючи тестові листи.

• Два SPF-записи. Класична випадковість: ви підключили новий поштовий сервіс і додали ще один TXT-запис. Домен може публікувати рівно один; якщо їх два, SPF повертає постійну помилку для кожного листа.
• Понад десять DNS-запитів. Кожен include, a, mx, ptr, exists і redirect рахується, так само як і кожен такий елемент усередині підключеного запису. Після десяти перевірка не проходить. Платформи розсилок, CRM і служби підтримки приносять свої include, тож ліміт вичерпується непомітно. Перевірка проходить по include, щоб оцінити кількість.
• +all або відсутність all. Запис, що закінчується на +all, дозволяє слати пошту всьому інтернету. Запис без завершального вердикту нічого не каже про сторонніх.
• DMARC застряг на p=none. З нього варто починати, але лишатися там не варто: поки він там, нічого не блокується. Читайте агрегатні звіти, виправляйте відправників, які не проходять, і переходьте до quarantine, а потім до reject.
• DKIM-ключ на 1024 біти. Він ще проходить перевірку, але вважається слабким. Перейдіть на 2048 бітів, опублікувавши новий селектор до того, як перемикати підписування.
• DMARC-запис без адреси rua. Тоді ви застосовуєте політику наосліп.

Чому DKIM іноді «не знайдено»

Ключ DKIM лежить за іменем, у якому є селектор, а DNS не вміє показати всі імена під доменом. Ця сторінка пробує селектори, які за замовчуванням використовують поширені провайдери (google; selector1 і selector2 для Microsoft 365; s1, s2, k1, default та кілька інших). Якщо ваш відправник використовує інший, відкрийте будь-який лист, отриманий від цього домену, знайдіть заголовок DKIM-Signature і скопіюйте значення після s=. Вставте його в поле селектора й запустіть перевірку ще раз.

Деякі провайдери публікують ключ як CNAME на власний запис. Це нормально й працює так само; сторінка читає остаточну TXT-відповідь.

Від разової перевірки до сповіщення

Записи автентифікації змінюються з буденних причин: новий інструмент для розсилок, перенесена поштова скринька, зміна DNS-провайдера, після якої губиться запис. Змінюються вони й через помилки. DNS-монітор у Tenium може стежити за TXT-записами SPF і DMARC та сповіщати, коли значення перестає збігатися з очікуваним, а в повідомленні буде старий і новий текст (див. моніторинг DNS). Він починається з тарифу Starter. Для докладнішого перегляду записів є сторінки SPF-запит, DMARC-запит і DKIM-запит: вони показують сирі відповіді.

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