Концепция
Лимит SPF в 10 DNS-запросов (RFC 7208 §4.6.4) — самая частая реальная причина отказа SPF: записи органически разрастаются по мере добавления новых сервисов, незаметно превышают лимит, и SPF начинает возвращать permerror для всех — часто незамеченным месяцами.
Распространённое заблуждение
«Чем больше include: — тем надёжнее защита». На самом деле каждый дополнительный include:, a, mx, ptr, exists, redirect стоит один запрос из лимита в 10. Превышение лимита не делает политику строже — оно полностью ломает проверку SPF.
Практическое упражнение
Лабораторное окружение не обязательно:
Для ручного разбора записи термин за термином и симуляции превышения лимита — см. Урок 8 на странице Лабораторное окружение курса.
Команды для выполнения
# Прочитайте текущую SPF-запись
dig yourdomain.com TXT +short | grep spf1
# Подсчитайте запросы вручную — каждый из этих механизмов стоит 1 запрос: include, a, mx, ptr, exists, redirect
# (единой команды dig для этого нет — разбирайте запись термин за термином)
# Проверьте реальным SPF-валидатором (инструмент /mailauth на MarinaDNS делает именно это)
# либо вручную разрешите каждую цель 'include:', подсчитывая вложенные include
# Симулируйте превышение лимита: добавьте достаточно механизмов include:, чтобы превысить 10, затем проверьте на permerror
# через реальную тестовую отправку (mail-tester.com или аналог) или специализированный инструмент подсчёта SPF-запросовИсправляйте через «уплощение» (замена include: на его разрешённые IP-диапазоны напрямую, принимая компромисс по обслуживанию) или удаление неиспользуемых include — никогда не полагайтесь на то, что количество останется под 10 по мере добавления новых сервисов.
Итоговая проверка
Вы должны уметь объяснить, не подглядывая:
v=spf1 -all.Если можете ответить на всё без подсказок — переходите к Уроку 9.