Довідник помилок / SPF PermError: too many DNS lookups
Помилка SPF PermError: забагато DNS-запитів
PermError - це результат перевірки SPF, коли запис узагалі неможливо обчислити, і найчастіша причина цього - ліміт запитів. RFC 7208 дозволяє щонайбільше 10 термів із DNS-запитом на одне обчислення SPF: include, a, mx, ptr, exists і redirect коштують по одному, а ip4, ip6 і all не коштують нічого. Перевищення 10 - це постійна помилка, і правильна поведінка сервера-отримувача - вважати весь запис недійсним, тож усі відправники, яких ви ретельно дозволили, миттєво перестають бути дозволеними. Ви стикаєтеся з цим як із відхиленими листами або листами в спамі, або бачите рядок permerror у заголовках листа, у DMARC-звіті чи в панелі доставності.
Перевірте свій сайт
Через що виникає
Майже завжди межу переходять, додаючи сервіси. Кожен include: для хелпдеска, CRM чи розсилки коштує один запит сам по собі плюс усі запити всередині політики того провайдера, бо рахунок рекурсивний: їхній include всередині include лягає у ваш бюджет із 10. Друга причина не потребує від вас жодних дій: провайдер розширює власну політику, і запис, який учора коштував 9 запитів, сьогодні коштує 11. Рідше запис напханий термами a: і mx: для серверів із постійними адресами або містить терм ptr, який теж коштує запит і давно вважається застарілим.
Як виправити
- Запустіть перевірку на цій сторінці для свого домену і подивіться на число. Інструмент розгортає ваш SPF-запис, рекурсивно проходить кожен include: і redirect= та показує загальну кількість DNS-запитів проти ліміту 10. Якщо там 10 або менше, ліміт запитів не ваша проблема і причину треба шукати в іншому: два записи v=spf1 на одному домені, синтаксична помилка або більш ніж два запити до неіснуючих імен (порожні, void, запити теж дають PermError). Якщо там 11 і більше, причина саме ця, і далі йде виправлення.
- Видаліть include: сервісів, з яких ви більше не шлете пошту. Випишіть усі include: із запису і зіставте кожен із живим відправником: пробна CRM дворічної давнини і хостинг, який ви покинули, зазвичай усе ще там, і це найдешевші запити, які можна повернути.
- Замініть терми, що коштують запити, на літеральні адреси. ip4, ip6 і all безкоштовні, тож провайдер, який публікує чотири діапазони відправки, з кількох запитів перетворюється на нуль (це називають флетенінгом), a: чи mx: для сервера з постійною адресою дешевше вписати як ip4, а терм ptr варто просто прибрати. Чесний мінус: жорстко вписані діапазони застарівають, коли провайдер міняє інфраструктуру, і вас про це ніхто не попередить, тому переглядайте їх за розкладом і розгортайте лише тих провайдерів, які публікують стабільний задокументований список.
- Зведіть відправників докупи. Дві платформи розсилок або CRM, яка вміє слати через ваш основний поштовий сервіс, коштують по цілому include кожна; перехід на одного провайдера прибирає ці запити назавжди, а не підрізає їх.
- Винесіть масові розсилки на піддомен. news.example.com чи mail.example.com має власний SPF-запис і власний бюджет у 10 запитів, тож include маркетингової платформи живе там, а не на головному домені. У налаштуваннях платформи вкажіть конвертного відправника (Return-Path) на піддомені, бо SPF перевіряють саме за ним, а не за заголовком From:, і памʼятайте, що стандартне relaxed-вирівнювання DMARC приймає піддомен вашого домену, а строге (aspf=s) - ні.
- Лише після всього цього розглядайте сервіс SPF-флетенінгу. Він сам розкриває include і підтримує згенерований запис актуальним, і це справді працює, але ваша доставка тепер залежить від чужого аптайму і від запису, який ви більше не читаєте, а безкоштовний тариф, що тихо перестав оновлюватися, виявиться у вигляді відхилених листів. Після будь-якої правки дочекайтеся закінчення TTL у DNS і запустіть перевірку ще раз, щоб побачити нове число.