Проверьте запись SPF или создайте новую
SPF ломается тихо. Год всё работает, кто-то подключает ещё один сервис, запись превышает лимит в десять DNS-запросов, и с этого момента каждый получатель считает её нерабочей — без единой ошибки где бы то ни было. Здесь вы видите этот счётчик.
- Работает в вашем браузере, а не на нашем сервере
- Без регистрации
- Без водяных знаков
Загружаем инструмент…
Как это работает
- Введите свой домен. Добавьте IP-адрес, если хотите узнать, разрешено ли именно этому серверу отправлять почту.
- Прочитайте результат, счётчик запросов и находки; разверните дерево, чтобы увидеть, что на самом деле содержит каждая подключённая запись.
- Соберите правильную запись в конструкторе ниже из сервисов, которыми вы реально пользуетесь.
Почему ничего не отправляется на сервер
Всё, что делает эта страница, выполняет код внутри вкладки вашего браузера — тем же движком, который рисует веб-страницы. Файл читается с диска в память вкладки, преобразуется там и записывается обратно как загружаемый файл. Он никуда не отправляется — ни нам, ни третьей стороне.
Проверьте сами
- Откройте инструменты разработчика в браузере (F12) и перейдите на вкладку «Сеть» (Network).
- Загрузите свой файл и запустите инструмент.
- Единственные запросы, которые вы увидите, — это код самого инструмента, а у нескольких тяжёлых инструментов ещё и их открытый движок из публичного CDN, плюс один небольшой сигнал о просмотре страницы на loreatec.jp (адрес и заголовок страницы, больше ничего). Ни один из них не несёт ваш файл.
Частые вопросы
В чём именно состоит лимит в десять запросов?
Каждый include, a, mx, ptr, exists и redirect стоит один DNS-запрос, причём запросы внутри подключённых записей тоже считаются. Стандарт (RFC 7208) ограничивает общее число десятью. Получатель, который упирается в этот предел, останавливается и возвращает ошибку, а большинство обрабатывает это так, будто у вас вообще нет SPF. Обычная причина — провайдеры, у которых один include прячет ещё три-четыре запроса. Решение: убрать сервисы, которыми вы больше не пользуетесь, или заменить include на обычные IP-адреса — аккуратно, потому что такие списки устаревают.
Почему +all — это так плохо?
Потому что это разрешает любому серверу в интернете отправлять почту от имени вашего домена. Это хуже, чем не публиковать запись вообще: без записи получатель опирается на другие признаки, а с +all вы прямо поручились за спамера. Обычно это появляется, когда кто-то копирует пример и меняет не тот символ.
Запись должна заканчиваться на -all или на ~all?
-all означает «отклонять всё остальное», ~all означает «относиться ко всему остальному с подозрением». Начните с ~all, пока вы ещё выясняете, что именно отправляет почту от вашего имени, а потом переходите на -all. Разница становится важна только тогда, когда настроен DMARC — это правило, которое срабатывает, когда проверка отправителя не проходит, — и политика DMARC reject при SPF ~all всё равно отклонит письмо. Не оставайтесь на ~all навсегда из осторожности: это остановка в пути, а не конечная точка.
Может ли быть две записи SPF?
Нет. Две записи v=spf1 на одном и том же имени — это постоянная ошибка, и получатели прекращают проверку вообще. Так бывает, когда сервис просит «добавить эту запись», а вы добавляете вторую TXT-запись вместо того, чтобы объединить её содержимое с уже существующей.
Что и кому это отправляет?
Доменные имена, которые нужно проверить, уходят в выбранный вами публичный DNS-сервис, из вашего браузера. Сервер этого сайта не участвует и ничего не запоминает. Конструктор записи целиком работает на вашем устройстве.