Несколько SPF записей для домена

1. Короткий ответ: вторая SPF запись не работает

По RFC 7208 домен должен публиковать не более одной SPF записи. Если DNS возвращает несколько TXT записей, начинающихся с v=spf1, получатель обязан вернуть результат permerror (permanent error). Это не предупреждение, а полный сбой проверки SPF.

Типичный сценарий: команда подключает второй сервис рассылок, поддержка сервиса пишет "добавьте нашу SPF запись", и в DNS появляется вторая строка v=spf1 рядом со старой. С этого момента SPF ломается сразу для обоих отправителей.

2. Как выглядит проблема

Ошибка "multiple SPF records found" встречается в валидаторах DNS, в логах почтовых серверов и в заголовках писем. В заголовке Authentication-Results это выглядит так:

Authentication-Results: mx.google.com; spf=permerror (multiple SPF records found) smtp.mailfrom=example.com

Проверить домен вручную можно одной командой:

dig TXT example.com +short

или на Windows:

nslookup -type=TXT example.com

Если в ответе две строки, начинающиеся с "v=spf1", проблема подтверждена. Пример такого ответа:

"v=spf1 include:_spf.google.com ~all"

"v=spf1 include:sendgrid.net ~all"

3. Дерево диагностики

Используйте эту последовательность, чтобы быстро понять, что именно сломано.

Отдельный случай: запись опубликована не только как TXT, но и как устаревший тип SPF (тип 99). RFC 7208 отменил использование типа SPF, проверяющие серверы читают только TXT, но старые записи типа SPF стоит удалить, чтобы не путать диагностику.

4. Как объединить SPF записи: пошагово

Шаг 1. Выгрузите текущие TXT записи домена и выпишите все строки v=spf1.

Шаг 2. Соберите механизмы из всех записей в один список. Обычно это include от каждого сервиса отправки, иногда ip4 для собственных серверов.

Шаг 3. Сформируйте одну запись. Для примера выше с двумя сервисами объединенная запись выглядит так:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Шаг 4. Обновите TXT запись в панели DNS: одна строка вместо двух. Удалите старые дубликаты.

Шаг 5. Дождитесь обновления DNS (смотрите TTL записи) и проверьте результат командой dig.

5. Два сервиса рассылок и один домен

Самая частая причина дубликатов: компания отправляет рассылки через два сервиса, например транзакционные письма через один ESP, а маркетинговые через другой, плюс корпоративная почта на Google Workspace или Яндекс 360. Каждый вендор в инструкции пишет "добавьте SPF запись", и без контроля записей становится три-четыре.

Правильный подход: одна запись, в которой перечислены все источники отправки. Пример для домена, который шлет через Google Workspace, ESP и собственный сервер:

v=spf1 include:_spf.google.com include:esp-vendor.example ip4:203.0.113.10 ~all

Если источников много, следите за вторым ограничением: проверка SPF допускает не более 10 DNS lookups на одну проверку (RFC 7208, раздел 4.6.4). Каждый include, a, mx, ptr и redirect расходует лимит. При объединении нескольких сервисов лимит легко превысить, и это снова даст permerror, уже по другой причине. Подробнее об этом в статье про слишком много DNS lookups в SPF.

6. Чем грозит permerror для доставки

SPF с результатом permerror означает, что аутентификация не пройдена. Для Gmail и других крупных провайдеров это минус к репутации отправителя, а при включенной политике DMARC с p=quarantine или p=reject письмо может быть отклонено или отправлено в спам, если DKIM тоже не проходит или не выровнен.

Если DKIM настроен корректно и DMARC выровнен по DKIM, письмо формально может пройти DMARC даже со сломанным SPF. Но рассчитывать на один механизм рискованно: форвардинг и списки рассылки ломают SPF штатно, а сломанная запись добавляет сбои там, где их быть не должно.

В Google Postmaster Tools доля писем, прошедших SPF, доступна в виде метрики: падение этой доли после изменений в DNS - типичный маркер того, что запись сломана.

7. Как проверить результат

После правки DNS выполните три проверки.

Первая: dig TXT example.com +short должен вернуть ровно одну строку, начинающуюся с v=spf1.

Вторая: прогоните домен через SPF валидатор. В PostmastersTool проверка DNS домена показывает состояние SPF, DKIM, DMARC и MX по каждому домену.

Третья: отправьте тестовое письмо на Gmail и посмотрите заголовок Authentication-Results. Нужный результат: spf=pass. Разобрать заголовки можно в бесплатном анализаторе заголовков письма.

Чтобы не ловить такие ошибки вручную после каждого изменения DNS, настройте мониторинг: PostmastersTool регулярно проверяет DNS записи доменов (в том числе наличие SPF) и присылает уведомление в Telegram или на почту, если запись SPF пропадет.