Объяснение ограничения на количество запросов DNS при SPF 10 (и как это исправить)

Чтобы понять ограничения записей SPF, следует начать с ограничения на 10 запросов DNS. Если ваша запись SPF вызывает более 10 запросов DNS, принимающие почтовые серверы возвращают сообщение «SPF PermError: too many DNS lookups», а DMARC рассматривает это как критическую ошибку. В результате легитимные письма отклоняются или попадают в спам без предупреждения.

Это ограничение установлено в RFC 7208, согласно которому при проверке SPF допускается не более 10 механизмов DNS-запросов. Проблема заключается в том, что большинство доменов превышают этот лимит, даже не подозревая об этом, что часто связано с вложенными включениями и устаревшими службами.

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

SPF-проверка: проверьте количество запросов с помощью нашего бесплатного инструмента SPF-проверки

Что такое ограничение на поиск DNS SPF 10?

Согласно спецификации SPF, определенной в RFC 7208, количество механизмов отправки DNS-запросов при каждой проверке SPF ограничено максимум 10-ю.

Проще говоря, каждый раз, когда почтовый сервер-получатель проверяет вашу запись SPF и ему приходится выполнять дополнительный DNS-запрос, это учитывается в рамках данного лимита.

Эти запросы запускаются такими механизмами, как:

• включать
• a
• mx
• ptr
• существует
• перенаправить

Как только возникает необходимость в 11-м запросе, проверка SPF немедленно прекращается и возвращает:

SPF PermError: слишком много запросов DNS

Каждый запрос DNS требует времени и ресурсов, таких как вычислительная мощность процессора, пропускная способность канала и объем памяти, на принимающем сервере. Без ограничений злоумышленник может создать запись SPF с глубоко вложенными включениями, что заставит серверы выполнять сотни DNS-запросов.

Это фактически превратило бы проверку SPF в канал для организации атак типа «отказ в обслуживании» (DoS).

Благодаря введению строгого ограничения в 10 записей спецификация SPF гарантирует:

• предсказуемые сроки обработки электронных писем
• защита от злоупотреблений в системе DNS
• стабильная работа в различных почтовых системах 

Что учитывается при подсчете лимита запросов DNS SPF 10? 

Не все механизмы в вашей записи SPF вызывают запрос DNS. Понимание того, что влияет на количество запросов, а что нет, — это самый быстрый способ сократить их количество.

Механизмы SPF, которые учитываются, и те, которые не учитываются

Именно поэтому включить: и механизмы являются основными причинами сбоев SPF, особенно когда они содержат вложенные запросы.

Замена механизмов, требующих интенсивного поиска, на прямые ip4: или ip6: (где это возможно) — один из самых эффективных способов уложиться в лимит.

Типичная ситуация: MSP, управляющие записями SPF нескольких клиентов

Поставщики управляемых услуг часто сталкиваются с ограничениями SPF, когда их клиенты используют несколько почтовых платформ. Типичный клиент MSP может использовать Office 365, Mailchimp, Salesforce и HubSpot — каждая из этих платформ требует использования операторов include, количество которых может быстро приблизиться к пределу в 10 запросов.

Почему вы, скорее всего, достигаете предела SPF (вложенные включения)

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

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

На первый взгляд это выглядит как 3 запроса DNS, но проверка SPF на этом не заканчивается. Она рекурсивно прослеживает каждый элемент include.

На самом деле всё происходит так:

1. include:sendgrid.net → Запись SPF SendGrid содержит 2 дополнительных include: механизма → всего 3 запроса
2. include:_spf.google.com → Запись SPF Google содержит 3 дополнительных механизма → Всего 4 запроса
3. include:salesforce.com → Запись SPF Salesforce содержит 3 дополнительных механизма → Всего 4 запроса

Всего: 11 запросов DNS

В число включение: не является просто одним запросом. Это один запрос плюс столько запросов, сколько запись SPF . Вот почему лимит исчерпывается гораздо быстрее, чем ожидают большинство владельцев доменов, особенно при использовании нескольких почтовых провайдеров.

Почему существует ограничение на поиск SPF 10

Ограничение в 10 запросов DNS может показаться слишком строгим, особенно для организаций, использующих нескольких поставщиков услуг электронной почты, однако оно установлено по важным соображениям безопасности и производительности, которые должны понимать администраторы и специалисты по безопасности.

Резюме: Ограничение на количество запросов защищает инфраструктуру DNS от злоупотреблений, обеспечивая при этом своевременную обработку электронной почты, но требует тщательного управления записями SPF.

Предотвращение атак типа «отказ в обслуживании»

Ограничение в 10 дополнительных запросов введено для предотвращения необоснованной нагрузки на DNS и атак типа «отказ в обслуживании» (DoS).

Без этого ограничения злоумышленник мог бы создать запись SPF с сотнями вложенных включений, что заставило бы каждый почтовый сервер, обрабатывающий письма из этого домена, выполнять огромное количество DNS-запросов. Это может перегрузить DNS-серверы и ухудшить производительность во всем Интернете.

Обеспечение своевременной обработки электронной почты

Каждый запрос DNS во время проверки SPF увеличивает задержку в процессе доставки электронной почты. Если бы для записей SPF допускалось неограниченное количество запросов, время, необходимое для проверки SPF, могло бы значительно увеличиться, что привело бы к таймаутам DNS-запросов и временным сбоям DNS-серверов.

Ограничение на 10 запросов гарантирует, что проверки SPF могут выполняться быстро и надежно, не создавая узких мест в доставке электронной почты.

Поддержание стабильности DNS

Инфраструктура DNS является общим ресурсом. Разрешение неограниченного количества запросов во время аутентификации SPF создаст чрезмерную нагрузку на рекурсивные резолверы и авторитетные серверы имен, особенно в случае отправителей с большим объемом трафика.

Это ограничение защищает более широкую экосистему DNS, позволяя контролировать объем запросов, связанных с SPF.

Что происходит, когда вы превышаете лимит поиска SPF

Превышение лимита запросов SPF приводит не просто к небольшому предупреждению. Оно вызывает серьезный сбой, который может напрямую повлиять на то, дойдут ли ваши письма до почтовых ящиков получателей.

Оценка SPF завершается на 11-м этапе проверки

SPF-запись обрабатывается слева направо. Когда принимающий сервер обнаруживает в вашей SPF-записи 11-й механизм DNS-запроса или модификатор, он немедленно прекращает обработку записи и возвращает:

SPF PermError: слишком много запросов DNS

Это постоянная ошибка проверки SPF, а не «мягкий сбой» или нейтральный результат. Приемник считает запись SPF недействительной, поскольку не может завершить аутентификацию.

DMARC рассматривает ошибку SPF PermError как сбой SPF

Если SPF возвращает ошибку PermError, DMARC интерпретирует это как сбой SPF. Если для успешной проверки DMARC требовалось соответствие SPF, сообщение может полностью провалить аутентификацию DMARC.

В таком случае результат зависит от:

• Ваша политика DMARC (p=none, карантинили отклонить)
• Правила фильтрации принимающего сервера
• Проходит ли проверка DKIM и удается ли выполнить сопоставление

Письма могут быть отклонены, помещены в карантин или отправлены в папку «Спам»

Если SPF завершается с ошибкой из-за PermError:

• Некоторые провайдеры могут сразу же отклонить это письмо
• Другие могут отправить его в папку «Спам» или «Карантин»
• Фильтры безопасности могут пометить это сообщение как подозрительное или неаутентифицированное

Это становится особенно опасным при использовании более строгих политик DMARC, таких как p=quarantine или p=reject.

Среды Microsoft в этом плане особенно чувствительны. Outlook и Exchange Online строго контролируют аутентификацию, поэтому ошибки SPF PermErrors могут существенно повлиять на доставляемость писем для организаций, отправляющих сообщения получателям Office 365.

Поскольку SPF оценивается слева направо, некоторые службы-отправители могут пройти аутентификацию успешно до того, как будет достигнут предел количества запросов, в то время как другие потерпят неудачу на более поздних этапах цепочки.

Это означает:

• Некоторые письма, похоже, доставляются без проблем
• У других происходит непредвиденный сбой при аутентификации
• Без инструментов отчетности DMARC и анализа SPF диагностировать эту проблему становится затруднительно

Именно поэтому проблемы, связанные с превышением лимита запросов SPF, часто остаются незамеченными до тех пор, пока не снизится доставляемость или в отчетах DMARC не начнут появляться сообщения о периодических сбоях.

Другие причины ошибки SPF PermError

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

• Несколько записей SPF для одного и того же домена
• В записи SPF обнаружены синтаксические ошибки
• Используются устаревшие или неподдерживаемые механизмы
• Круговой включают: операторы создают бесконечные циклы поиска

Любая из этих проблем может привести к сбою аутентификации SPF и негативно повлиять на доставляемость электронной почты.

Проверьте свою политику DMARC, чтобы оценить степень уязвимости с помощью проверке записей DMARC

Любая из этих проблем может привести к сбоям SPF и недоставке писем, поэтому важно регулярно проверять всю конфигурацию SPF.

Ограничение на поиск пустых записей в SPF: ещё одно ограничение, с которым вы можете столкнуться

Большинство руководств по SPF ограничиваются пределом в 10 запросов DNS, однако в RFC 7208 существует еще одно ограничение, которое может привести к той же ошибке, даже если количество запросов значительно меньше 10: ограничение на недействительные запросы.

Поиск по пустому записи — это DNS-запрос, который не возвращает никаких полезных результатов.

Это происходит, когда функция поиска возвращает:

• NXDOMAIN (домен не существует)
• NOERROR при отсутствии записей (пустой ответ)

Согласно RFC 7208, при проверке SPF допускается не более двух недействительных запросов.

Если происходит третий неудачный поиск, принимающий сервер возвращает:

SPF PermError

Это означает:

Ошибка SPF PermError может возникнуть даже в том случае, если для вашей записи выполняется менее 10 запросов DNS.

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

Ошибки при проверке обычно возникают из-за устаревших или неправильно настроенных записей SPF:

• включить: указание на домен, у которого больше нет записи SPF
• а или mx механизмы, ссылающиеся на домены без действительных записей DNS
• Устаревшие или снятые с эксплуатации поставщики услуг электронной почты
• Опечатки в доменных именах в механизмах SPF

Даже одно устаревшее включение может незаметно приводить к неудачной попытке поиска при каждой проверке SPF.

Вот в чём заключается разница между ограничением на 10 запросов и ограничением на недействительные запросы:

Оба варианта приводят к одному и тому же результату: SPF PermError.

Чтобы избежать ошибок при поиске пустых значений:

• Регулярно проверяйте свою запись SPF на наличие устаревших включить: операторы
• Удалите службы, которыми вы больше не пользуетесь
• Убедитесь, что все указанные домены возвращают действительные записи DNS
• Воспользуйтесь проверку SPF , который отмечает недействительные запросы, а не только общее количество запросов

Сервис проверки SPF от PowerDMARC выявляет как полные запросы, так и недействительные запросы, что позволяет выявлять эти скрытые ошибки до того, как они повлияют на доставляемость.

Как проверить, не превышает ли ваша запись SPF установленный лимит

Определение того, превышает ли ваша запись SPF лимит в 10 запросов DNS, — это первый шаг к устранению проблем с доставкой. Существует несколько способов проверить запись SPF и текущее количество запросов.

Резюме: Регулярный мониторинг SPF с использованием диагностических инструментов и ручной проверки помогает предотвратить нарушения лимитов запросов до того, как они повлияют на доставку электронной почты.

Используйте диагностический инструмент SPF

Использование инструмента диагностики SPF поможет убедиться в том, что запись SPF действительна и работает корректно. Эти инструменты анализируют вашу запись SPF, подсчитывают количество запросов к DNS, включая вложенные, и отмечают любые ошибки или предупреждения.

Бесплатный инструмент проверки записей SPF от PowerDMARC позволяет мгновенно узнать общее количество запросов, определить, какие механизмы потребляют больше всего ресурсов, и выявить ошибки в настройках, прежде чем они приведут к проблемам с доставкой.

Вручную отслеживайте свою запись SPF

Если вы предпочитаете самостоятельно проверять запись SPF, вы можете вручную подсчитать количество DNS-запросов, проходя по каждому механизму в записи.

Начните с записи SPF TXT вашего домена и подсчитайте количество механизмов «include», «a», «mx», «ptr», «redirect» и «exists». Затем для каждого «include» найдите запись SPF домена, на который есть ссылка, и подсчитайте также механизмы, вызывающие поиск, для этой записи.

Вложенные вложения быстро накапливаются, поэтому организации, которые используют несколько поставщиков услуг электронной почты, часто превышают лимит, не осознавая этого.

Мониторинг проверки SPF с течением времени

Записи SPF не являются статическими. При добавлении или удалении поставщиков услуг электронной почты, смене хостинговой среды или обновлении инфраструктуры электронной почты запись SPF также изменяется. Рекомендуется проверять записи SPF после внесения изменений, чтобы обеспечить соблюдение ограничения в 10 запросов.

Настройка постоянного мониторинга через платформу PowerDMARC обеспечивает постоянный контроль над конфигурацией SPF и предупреждает вас, когда изменения выводят вашу запись за пределы допустимого диапазона.

Как исправить и оптимизировать запись SPF

Если ваша запись SPF превышает или приближается к пределу в 10 DNS-запросов, вы можете предпринять несколько практических шагов, чтобы уменьшить количество запросов без ущерба для охвата аутентификации электронной почты.

Резюме: Оптимизация SPF включает удаление неиспользуемых служб, замену механизмов, требующих интенсивного поиска, на прямые IP-адреса, а также внедрение автоматизированного управления для сложных инфраструктур.

Проведите аудит вашей текущей записи SPF и подсчитайте количество запросов

Начните с анализа вашей записи SPF с помощью надежного инструмента проверки SPF. Это поможет вам определить общее количество запросов DNS, включая вложенные включения, и выявить такие проблемы, как пустые запросы или ошибки в настройках. Кроме того, это покажет, какие механизмы потребляют больше всего запросов.

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

Удалите неиспользуемые или ненужные службы

Самый простой способ оптимизации — проверить запись SPF и удалить все механизмы, которые ссылаются на службы, которые вы больше не используете.

Со временем организации добавляют в свою запись SPF поставщиков услуг электронной почты, маркетинговые платформы и сторонние инструменты, но забывают удалять их, когда они больше не используются.

Чтобы сократить количество необходимых запросов, организациям следует удалить неиспользуемые службы из своих SPF-записей. Это также означает удаление значений SPF по умолчанию, которые были добавлены во время первоначальной настройки, но в настоящее время не используются.

Избегайте ptr и минимизируйте ненужные mx использование

Указатель механизм механизм категорически не рекомендуется стандартами SPF. Он выполняет обратный DNS-поиск для каждого IP-адреса отправителя, что делает его медленным, ненадежным и требующим большого количества запросов. Если он присутствует, удалите его и замените прямыми ссылками на IP-адреса.

The механизм также может увеличить количество запросов. Сначала он разрешает записи MX, а затем выполняет дополнительные запросы для каждого связанного почтового сервера. Если ваша инфраструктура стабильна, замените mx на ip4: или ip6: для повышения эффективности.

Заменить механизмы, требующие интенсивного поиска, на ip4 или ip6

Каждый механизм «include», «a» и «mx» требует как минимум одного запроса DNS. По возможности замените их механизмами ip4 или ip6, которые напрямую указывают авторизованные IP-адреса. Использование механизмов ip4 или ip6 в записях SPF не требует дополнительных запросов и может помочь соблюсти ограничение на количество запросов.

Например, если запись SPF поставщика услуг электронной почты разрешается в известный набор статических IP-адресов, вы можете перечислить эти IP-адреса напрямую, а не использовать «include», который запускает несколько DNS-запросов.

Используйте сглаживание SPF (краткосрочное решение)

Сглаживание SPF заменяет включает: механизмы с их разрешенными IP-адресами, что сокращает количество запросов DNS практически до нуля. Чтобы быстро вернуть вашу запись в пределы лимита, используйте автоматическое упрощение SPF, а затем проверьте обновленную запись перед ее публикацией.

Однако это сопряжено с определенными недостатками. Если провайдер меняет свои IP-адреса, а ваша запись не обновляется, легитимные письма могут не пройти проверку SPF. Ручное упрощение требует постоянного мониторинга и обслуживания.

Используйте хостируемый SPF или макросы SPF (постоянное решение)

Для обеспечения долгосрочной стабильности рекомендуем рассмотреть возможность использования хостингового решения для SPF, такого как PowerDMARC. Эти системы динамически управляют вашей записью SPF с помощью макросов или внешнего разрешения, автоматически обеспечивая соблюдение лимитов запросов.

Такой подход позволяет исключить:

• Ручное обновление при изменении IP-адресов поставщиков
• Риски, связанные с устаревшими сглаженными данными
• Текущие расходы на техническое обслуживание

Это особенно ценно для организаций, которые используют множество сторонних сервисов или управляют сложной почтовой инфраструктурой.

Избегайте механизма ptr

Использование механизма ptr категорически не рекомендуется, так как это может привести к увеличению количества необходимых запросов, что, в свою очередь, может вызвать ошибки Permerror.

Механизм ptr выполняет обратный DNS-поиск для каждого подключающегося IP-адреса, что является как медленным, так и ненадежным. В самой спецификации SPF не рекомендуется его использовать. Если ваша запись SPF в настоящее время содержит механизм ptr, удалите его и замените прямыми ссылками на IP-адреса.

Минимизировать использование механизма mx

Отказ от использования механизма MX в записях SPF может помочь уложиться в лимит из 10 запросов DNS. Механизм MX сначала разрешает запись MX домена, а затем выполняет дополнительные запросы для определения IP-адреса каждого указанного почтового сервера.

Если у вашего домена есть несколько записей MX, один запрос «mx» может потребовать нескольких поисков. Замените его записями ip4 или ip6 для ваших почтовых серверов, где это возможно.

Консолидировать включить отчеты

Если в вашей записи SPF есть несколько механизмов «include», указывающих на связанные службы, проверьте, можно ли их объединить.

Некоторые поставщики услуг электронной почты используют совместную инфраструктуру, что означает, что вы можете выполнять избыточные поиски. Просмотрите каждое включение, чтобы определить, по-прежнему ли оно необходимо и можно ли напрямую ссылаться на базовые IP-адреса.

Проверяйте после каждого изменения

Проверка записей SPF после внесения изменений необходима для обеспечения соответствия ограничению в 10 запросов.

Даже небольшое изменение, например добавление одного нового «include» для маркетинговой платформы, может привести к превышению лимита, если это вызовет вложенные запросы. Проверяйте свою запись с помощью диагностического инструмента SPF после каждого обновления, чтобы убедиться, что она остается действительной.

Сглаживание записей SPF: что это такое и когда его использовать

Упрощение записей SPF — это метод оптимизации записей SPF, позволяющий обойти ограничение на 10 запросов DNS для SPF. Это одно из наиболее обсуждаемых решений для организаций со сложной инфраструктурой электронной почты, но оно сопряжено с компромиссами, которые важно понимать.

Полное полное руководство по оптимизации по оптимизации записи SPF, ознакомьтесь с нашим блогом «Руководство по оптимизации SPF»

Как работает уплощение записей SPF

Уплощение записей SPF заменяет механизмы, вызывающие поиск в записи SPF, соответствующими IP-адресами или диапазонами CIDR, что сокращает количество DNS-запросов, необходимых для проверки записи SPF.

Вместо того, чтобы включать ссылку типа «include:emailprovider.com», которая запускает один или несколько DNS-поисков, вы преобразуете эту ссылку в базовые IP-адреса и указываете их непосредственно в своей записи, используя механизмы ip4 или ip6.

Например, если «include:emailprovider.com» разрешается в три IP-адреса, при упрощении оператор include заменяется этими тремя записями IPv4. Теперь проверка SPF возвращает тот же результат, не требуя дополнительных DNS-запросов для этого провайдера.

Когда выравнивание помогает

Упрощение записи SPF может уменьшить количество механизмов и модификаторов DNS-запросов, чтобы их количество было меньше 10. Это особенно полезно в следующих случаях:

• Ваш домен отправляет электронные письма через множество сторонних сервисов, и только количество включений превышает 10.
• Вы уже удалили неиспользуемые службы и по возможности объединили их, но все еще превышаете лимит.
• Вам нужен быстрый способ привести ваши записи в соответствие с требованиями при планировании долгосрочной стратегии оптимизации.

Почему ручное сглаживание SPF — это лишь временное решение

Упрощение записи SPF может быстро привести к тому, что количество запросов в ней не превысит допустимый предел в 10, однако ручное упрощение записи SPF не является долгосрочным решением, поскольку сопряжено с другим набором рисков, которые с такой же легкостью могут нарушить доставку электронной почты.

Риск 1: Изменение IP-адресов поставщиков

Большинство поставщиков услуг электронной почты меняют или расширяют диапазоны IP-адресов для рассылки без предварительного уведомления.

При ручном сглаживании записи SPF:

• вы вписываете эти IP-адреса в настройки DNS
• но ваш провайдер постоянно совершенствуется за кулисами

Как только их список IP-адресов изменится, ваша запись SPF устареет, и легитимные письма начнут проваливать проверку подлинности.

Риск 2: Размер записи SPF (255 символов + ограничения DNS)

При сглаживании заменяются записи «includes» с несколькими IP-адресами, что может быстро привести к раздуванию вашей записи SPF.

Это создает две проблемы:

• Длина записей TXT в системе DNS ограничена 255 символами на одну строку
• Слишком длинные записи SPF могут привести к сбоям при разборе или превысить ограничения DNS

Попытки «исправить» ограничения на поиск могут привести к появлению синтаксических ошибок или проблемам с усечением записей.

Риск 3: Отсутствие мониторинга или контроля

Ручное сглаживание является статическим. В системе нет встроенных средств для:

• обнаруживать изменения диапазонов IP-адресов
• количество запросов по треку во времени
• уведомлять вас о сбоях при аутентификации

Это означает, что проблемы часто остаются незамеченными до тех пор, пока не снизится доставляемость.

Риск 4: Постоянная нагрузка, связанная с техническим обслуживанием

Каждый раз, когда вы:

• добавить новый почтовый сервис
• изменить инфраструктуру
• или ваш провайдер обновляет IP-адреса

Вам необходимо вручную пересоздать и проверить запись SPF.

Для команд, управляющих несколькими доменами или клиентами, такая ситуация быстро становится невыносимой.

Руководство Упрощение SPF решает симптом (ограничение поиска), а не лежащую в основе сложность (динамическая инфраструктура).

Именно здесь на помощь приходят хостинговые решения SPF.

Вместо жесткого задания IP-адресов такие платформы, как PowerDMARC, динамически управляют вашей записью SPF с помощью макросов и автоматических обновлений, что позволяет вам не превышать лимит запросов без постоянного ручного вмешательства.

Другие ограничения записей SPF, о которых следует знать

Ограничение на 10 запросов DNS — самое известное ограничение SPF, но не единственное. Владельцы доменов должны знать об этих дополнительных ограничениях записей SPF, чтобы избежать неожиданных сбоев при аутентификации.

Резюме: Помимо ограничения на 10 запросов, SPF имеет ограничения на количество записей, количество символов, недействительные запросы и сценарии переадресации, которые влияют на аутентификацию электронной почты.

Только одна запись SPF на домен

Спецификация SPF требует, чтобы каждый домен публиковал только одну запись SPF TXT.

Если запись SPF содержит несколько записей SPF для одного домена, это может привести к ошибке SPF PermError, и сервер-получатель может отклонить письмо или обработать его некорректно. Если вам необходимо авторизовать дополнительных отправителей, добавьте их в существующую запись SPF, а не создавайте новую.

SPF проверяет обратный путь, а не адрес отправителя.

SPF аутентифицирует домен в адресе обратного пути, а не в поле «От», которое видит получатель. Это означает, что злоумышленник может подделать адрес «От», проходя SPF, используя другой домен обратного пути.

DMARC устраняет этот пробел, требуя совпадения или согласования между доменом поля «От», читаемым человеком, и доменом, аутентифицированным SPF.

Ограничение длины строки в 255 символов

Хотя запись SPF может содержать в общей сложности более 255 символов, одна запись DNS типа TXT ограничена 255 символами. Более длинные записи SPF необходимо разбивать на несколько строк в пределах одной записи TXT.

Большинство провайдеров DNS обрабатывают это автоматически, но неправильно настроенные разделения могут вызвать ошибки разбора.

Лимит поиска пустых значений

В дополнение к ограничению в 10 DNS-запросов, спецификация SPF также ограничивает количество «недействительных запросов», то есть DNS-запросов, которые не возвращают никаких записей (либо пустой ответ, либо ответ NXDOMAIN).

Превышение этого предела, который обычно составляет два недействительных запроса, также может вызвать ошибку SPF PermError.

Отсутствие защиты для пересланных электронных писем

При пересылке письма IP-адрес отправителя заменяется на IP-адрес сервера пересылки, который, скорее всего, не указан в записи SPF исходного отправителя. Это может привести к тому, что пересланное письмо не пройдет проверку SPF, даже если исходное сообщение было легитимным.

Рекомендации по соблюдению ограничения на количество запросов SPF

Соблюдение ограничения на количество запросов DNS, установленного на уровне SPF 10, требует постоянной дисциплины. Воспользуйтесь этими рекомендациями, чтобы оптимизировать ваши записи и предотвратить непредвиденные сбои:

• Проверяйте запись SPF каждый раз, когда добавляете или удаляете платформу отправки
• Никогда не публикуйте более одной записи SPF на один домен
• Избегайте механизма ptr , удалите его, если он присутствует в вашей записи
• Использование ip4: и ip6: везде, где диапазоны IP-адресов стабильны и известны
• Настройте отчетность DMARC, чтобы своевременно выявлять периодические сбои SPF
• Используйте автоматический мониторинг (например, PowerDMARC), чтобы получать уведомления при изменении количества запросов
• Если вы используете более трёх-четырёх сторонних сервисов отправки почты, рассмотрите возможность использования услуги Hosted SPF

Как хостируемый SPF от PowerDMARC помогает предотвратить сбои при проверке SPF 

Ручное управление SPF быстро теряет свою эффективность в современных почтовых средах. Каждая новая почтовая платформа, маркетинговый инструмент, CRM-система, служба поддержки или облачный сервис может привести к появлению дополнительных записей SPF, вложенных запросов и увеличению трудозатрат на обслуживание.

Ручное упрощение списка SPF может временно снизить количество запросов, но при этом возникает другая проблема: необходимость поддерживать точность жестко заданных IP-адресов по мере того, как поставщики обновляют свою инфраструктуру рассылки.

Хостируемый SPF от PowerDMARC или PowerSPF, решает основную проблему управления, обновляя записи SPF по мере изменения вашей инфраструктуры отправки. В отличие от статического сглаживания SPF, Hosted SPF динамически управляет вашей конфигурацией SPF в фоновом режиме, помогая организациям соблюдать требования RFC 7208 без постоянного обслуживания DNS.

С помощью PowerSPF организации могут:

• Автоматически обновлять записи SPF при изменении IP-адресов поставщиков
• Используйте макросы SPF, чтобы не превышать ограничение на 10 запросов DNS и ограничения на длину строк DNS
• Внесите однократное изменение в настройки DNS вместо того, чтобы постоянно вручную редактировать записи SPF
• Управление сложными настройками SPF с учетом различных поставщиков, вложенных включений, региональной инфраструктуры и корпоративных доменов
• Отслеживайте сбои SPF, неудачные запросы и проблемы с аутентификацией, прежде чем они повлияют на доставку

Это особенно важно для организаций, которые одновременно используют такие платформы, как Microsoft 365, Salesforce, HubSpot, SendGrid, Mailchimp и другие сторонние почтовые сервисы, поскольку вложенные включения могут незаметно привести к превышению пределов, установленных стандартом RFC, при формировании записей SPF.

С автоматической сглаживанием SPF, мониторингом запросов в реальном времени, оповещениями об ошибках и инструментами для SPF, DKIM, DMARC и BIMI, PowerDMARC помогает организациям удерживать записи SPF в пределах лимита запросов и поддерживать более чистую конфигурацию аутентификации.

Для начала проверьте количество запросов SPF с помощью SPF-проверку PowerDMARC и выявите проблемы, прежде чем они повлияют на аутентификацию электронной почты.

Часто задаваемые вопросы

1. Что такое ограничение на количество запросов DNS со SPF 10?

Согласно спецификации SPF, определенной в RFC 7208, количество механизмов отправки DNS-запросов при каждой проверке SPF ограничено максимум 10-ю.

Если при проверке записи SPF требуется более 10 запросов, принимающий сервер возвращает ошибку SPF PermError, которая рассматривается DMARC как сбой. Это может привести к тому, что легитимные письма будут отклонены или отправлены в папку «Спам».

2. Какие механизмы SPF учитываются при подсчете лимита в 10 запросов?

Следующие механизмы запускают запросы DNS и учитываются при подсчете лимита:

• включать
• a
• mx
• ptr
• существует
• перенаправление=

Следующие варианты не учитываются:

• ip4, ip6 (прямые IP-адреса)
• все (универсальный)
• v=spf1 (тег версии)
• Первоначальный DNS-запрос для получения вашей записи SPF

3. Что такое SPF PermError?

Ошибка SPF PermError (постоянная ошибка) возникает, когда принимающий сервер не может правильно обработать вашу запись SPF.

Наиболее частая причина — превышение лимита в 10 запросов DNS, но это также может произойти из-за:

• синтаксические ошибки
• несколько записей SPF
• нарушения ограничений на количество запросов
• в циркуляре указано

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

4. Каков предел поиска по пустым записям в SPF?

Помимо ограничения на 10 запросов, RFC 7208 также ограничивает количество пустых запросов — DNS-запросов, не возвращающих результатов (NXDOMAIN или пустые ответы).

Ограничение составляет 2 пустых запроса на каждую проверку SPF.

Если ваша запись SPF вызывает третье неудачное обращение к базе данных, принимающий сервер возвращает ошибку PermError, даже если общее количество обращений не превышает 10.

5. Устраняет ли функция SPF-выравнивания ограничение на 10 запросов?

Да, но только временно.

Сглаживание SPF заменяет механизмы include на прямые IP-адреса, сокращая количество запросов к DNS. Однако это требует постоянного обслуживания, поскольку провайдеры почтовых услуг часто обновляют свои диапазоны IP-адресов.

Если ваша запись в формате «flattened» устарела, даже легитимные письма могут не пройти проверку SPF.

6. Как проверить, сколько запросов DNS использует моя запись SPF?

Вы можете воспользоваться инструментом проверки SPF, чтобы проанализировать свою запись и подсчитать количество запросов DNS, включая вложенные.

Проверка SPF от PowerDMARC показывает:

• общее количество запросов
• число запросов
• какие механизмы выполняют поиск

Это поможет вам выявить проблемы до того, как они повлияют на доставку.

7. В чём разница между SPF-сглаживанием и SPF-макросами?

Функция SPF-сглаживания статически заменяет включения на IP-адреса, что сокращает количество запросов, но требует ручного обновления.

Макросы SPF (используемые в хостинговых решениях SPF) динамически преобразуют записи SPF во время проверки, что позволяет не превышать лимиты запросов и избавляет от необходимости вручную обновлять списки IP-адресов.

Макросы обладают большей масштабируемостью и лучше подходят для сложных или многопоставщицких почтовых систем.

8. Как часто следует проверять запись SPF?

Вам следует проверить запись SPF:

• при каждом добавлении или удалении почтового сервиса
• после изменения инфраструктуры
• не реже одного раза в месяц

В случае сложных конфигураций рекомендуется осуществлять постоянный мониторинг, чтобы своевременно выявлять проблемы, связанные с ограничениями на количество запросов, и обеспечивать стабильную доставляемость.

• О сайте
• Последние сообщения

Ахона Рудра

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Аона - менеджер по маркетингу в PowerDMARC, имеет более чем 5-летний опыт написания статей на темы кибербезопасности, специализируясь на безопасности доменов и электронной почты. Ахона получила диплом о высшем образовании по специальности "Журналистика и коммуникации", а с 2019 года начала работать в сфере безопасности.

Последние сообщения Ахона Рудра (см. все)

• Как MSP-провайдеры могут быстрее управлять настройками DMARC для каждого клиента с помощью сервера MCP от PowerDMARC - 25 мая 2026 г.
• Как добавить IP-адрес в запись SPF (пошаговая инструкция) - 11 мая 2026 г.
• Запись SPF Avanan: как настроить, исправить и оптимизировать SPF для почтовой системы Check Point Harmony - 7 мая 2026 г.