Проверка SPF-записи домена

Что делать после проверки SPF

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

Для регулярного наблюдения за доступными метриками рассылок посмотрите мониторинг Google Postmaster и мониторинг Mail.ru Postmaster. Эти данные дополняют разовую проверку DNS.

Что проверяет инструмент

• Есть ли у домена TXT-запись, которая начинается с v=spf1, и одна ли она. По RFC 7208 (раздел 4.5) две и более записей дают ошибку permerror у любого получателя.
• Сколько DNS-запросов нужно получателю, чтобы проверить запись целиком. Считаются include, a, mx, ptr, exists и redirect по всему дереву вложенных записей. RFC 7208 (раздел 4.6.4) разрешает не больше 10, дальше permerror.
• Нет ли include на домен без SPF: по разделу 5.2 это тоже permerror. И нет ли петель, когда вложенная запись через include ссылается на саму себя: такая запись у получателя упирается в тот же лимит запросов.
• Чем заканчивается запись: -all, ~all, ?all или +all. Нет ли механизмов после all: получатель их не читает.
• Нет ли устаревшего механизма ptr и опечаток вроде ipv4: вместо ip4:.

Как читать результат

Строка "DNS-запросов при проверке" показывает, сколько запросов потратит получатель. 7 из 10 значит, что запас есть; 9 или 10 из 10 означает, что следующий добавленный сервис рассылок выведет запись за лимит. Если одна из вложенных записей не ответила, мы пишем "не меньше N": настоящее число может быть больше.

Окончание -all говорит получателю, что письма с других серверов можно отклонять. ~all просит считать их подозрительными, но не отклонять сразу (softfail). ?all ничего не утверждает, а +all разрешает отправку от имени домена любому серверу в интернете. Статус "Не удалось проверить" значит, что DNS не ответил вовремя, а не что записи нет.

Разница между softfail, fail и permerror и то, как их видит получатель, разобрана в статье SPF fail, softfail и permerror.

Типичные ошибки и как их исправить

• Две записи v=spf1, обычно после подключения второго сервиса рассылок. Их нужно объединить в одну: как это сделать без потери отправителей, написано в статье о нескольких SPF-записях.
• Больше 10 DNS-запросов. Уберите include сервисов, которыми больше не пользуетесь, и замените вложенные записи с постоянными адресами на ip4:. Подробный порядок в статье SPF: too many DNS lookups.
• В SPF нет сервиса, который реально отправляет рассылки. Include берут из справки самого сервиса; как собрать запись для нескольких отправителей, описано в статье как настроить SPF для рассылок.
• SPF настроен на основном домене, а письма уходят с поддомена или с домена сервиса рассылок в Return-Path. SPF проверяется для домена конверта (MAIL FROM), а не для адреса в поле "От кого", и поддомен запись родителя не наследует.
• +all или запись без all в конце. Первое разрешает подделку, второе оставляет чужие серверы в статусе neutral. Заканчивайте запись на ~all, а когда уверены в списке отправителей, на -all.

Как проверить вручную

Ту же запись можно посмотреть командой в терминале. Вложенные записи из include проверяются так же, по одной.

dig +short TXT example.ru
nslookup -type=TXT example.ru

Что проверить дальше

SPF защищает только домен конверта. Чтобы получатель связал проверку с адресом в поле "От кого", нужен DMARC с выравниванием доменов: проверьте его на странице проверки DMARC, а подпись писем на странице проверки DKIM. Какой сервер и с каким Return-Path отправил конкретное письмо, видно в его заголовках: их можно разобрать в анализаторе заголовков.

Частые вопросы