Почему ваши SPF-записи ломаются сами по себе

SPF, DKIM и DMARC настраиваются раз и навсегда. Но через какое-то время email-рассылки начинают пропадать без следа. Нет ошибок, нет отчётов — просто письма исчезают. Это происходит из-за жёсткого ограничения в 10 DNS-запросов, которое заложено в SPF.

Почти 5% доменов уже столкнулись с этой проблемой. Их владельцы часто не подозревают, что записи переполнены и перестают работать.

Откуда берётся лимит в 10 запросов

SPF проверяет отправителей через include:. Каждый такой механизм запускает DNS-запрос. При превышении лимита SPF возвращает PermError, и почтовые серверы отказывают в приёме писем.

Проблема особенно заметна, когда у вас несколько сервисов:

• Google Workspace
• Mailchimp
• Stripe
• SendGrid
• Zapier

Каждый добавляет по одному запросу. В итоге запись разрастается, а лимит оказывается превышен.

Почему SPF flattening — плохой выход

Многие рекомендуют заменить include: на статические IP-адреса. Это снижает количество запросов, но создаёт новую проблему: когда провайдер меняет свои IP, ваша запись устаревает. Нужно постоянно мониторить и вручную обновлять данные.

Flattening помогает на короткий срок, но не решает задачу надёжно.

Как правильно подойти к проблеме

1. Проведите аудит сервисов

Начните с того, чтобы проверить, какие сервисы реально используют вашу доменную почту. Часто в SPF остаются старые инструменты, которыми давно перестали пользоваться. Удаление лишних записей может сразу снизить число запросов на 30–40%.

2. Объедините провайдеров

По возможности замените несколько сервисов на одного. Например, AWS SES или Postmark могут закрыть сразу несколько задач: и маркетинговые рассылки, и transactional email. Это сокращает число include: до минимума.

3. Используйте unified endpoint

Некоторые крупные провайдеры позволяют заменить несколько include: на один unified endpoint, который покрывает их инфраструктуру. Это сни<|eos|>