Понимание ограничений SPF в аутентификации электронной почты

Система политики отправителя или SPF недостаточно, когда речь идет о защите корпоративной электронной почты от фишинговых и спамерских атак. SPF - это протокол аутентификации электронной почты, который защищает получателя электронной почты от поддельных писем, проверяя, авторизован ли IP-адрес отправителя в DNS-записи домена. Однако ограничение SPF на максимальное количество DNS-записей и несовпадение адреса From и домена приводят к ошибкам в реализации, что приводит к проблемам с доставкой электронной почты. DMARC опирается на SPF (и DKIM) для обеспечения повышенной безопасности и отчетности. В этом блоге обсуждаются эти проблемы SPF и то, как DMARC помогает преодолеть эти ограничения SPF.

Каковы ограничения записи SPF?

Существует 3 основных ограничения SPF, которые делают его немного сложным в реализации и поддержке.

1. Предел поиска SPF 10

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

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

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

Более того, согласно RFC, DNS-запрос имени хоста, найденного в записи запись MX не должен генерировать более 10 A-записей или AAAA-записей. Если DNS PTR-запрос выдает более 10 результатов, отображаются и используются только первые 10 результатов.

2. Читаемый человеком адрес From

Второе ограничение SPF заключается в том, что записи SPF применяются к определенным доменам Return-Path (также известным как отправитель конверта или MFrom), а не к адресу From (отправитель заголовка или адрес From), который получатели видят в своих почтовых клиентах. Получатели обычно не обращают особого внимания на скрытый адрес Return-Path и при открытии письма ориентируются только на видимый адрес From. Хакеры используют эту лазейку для фишинговых атак, используя поддельный домен в адресе обратного пути (который проходит SPF) и подделывая адрес From с легитимным или похожим на легитимный. Поскольку большинство людей не знают об адресе Return Path и не проверяют его, этот трюк позволяет злоумышленникам легко обойти защиту SPF.

3. Проблемы с переадресацией электронной почты

У SPF есть еще одна критическая точка отказа, которая может навредить доставке электронной почты. Когда вы внедрили SPF на своем домене и кто-то пересылает ваше письмо, переадресованное письмо может быть отклонено из-за политики SPF. Это происходит потому, что в процессе пересылки меняется сервер, отправляющий сообщение (и его IP-адрес), но оригинальный адрес From отправителя часто остается прежним. Получающий сервер видит оригинальный адрес From, но проверяет IP-адрес *пересылающего* сервера по SPF-записи оригинального отправителя. Поскольку IP-адрес пересылающего сервера обычно не включен в SPF-запись оригинального отправителя, проверка не удается, что может привести к отклонению пересылаемого письма или пометке его как спама.

Упростите безопасность с помощью PowerDMARC!

Влияние размера записи SPF на доставку электронной почты

Когда получатель превышает лимит SPF-записей, он не проходит проверку SPF и возникает ошибка Permerror. Вы можете наблюдать эту ошибку при использовании мониторинга DMARC. Получатель может выбирать, как поступать с письмами, получившими ошибку Permerror. Он может выбрать отклонение записи, что означает, что письмо вернется обратно. Некоторые получатели настраивают его на отображение "нейтрального" результата SPF (как будто SPF не используется). Они также могут выбрать "отказ" или "мягкий отказ", что означает, что письма, не прошедшие проверку подлинности SPF, не будут отклонены, а попадут в папку спама. 

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

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

Как сократить количество необходимых поисков?

Некоторым владельцам доменов трудно удержаться в рамках ограничения SPF в 10 поисков, поскольку привычки обмена электронной почтой значительно изменились по сравнению с 2006 годом (когда был внедрен RFC4408). Теперь компании используют множество облачных программ и сервисов с одним доменом. Итак, ниже приведены некоторые способы преодоления этого распространенного ограничения SPF.

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

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

• Удалить значения SPF по умолчанию

Политика SPF по умолчанию обычно устанавливается на 'v=spf1 a mx'. Поскольку большинство записей A и AAAA используются для веб-серверов, которые не могут отправлять электронную почту, следовательно, 'a' и 'mx' не требуются.

• Избегайте использования ptr Механизм

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

• Избегайте использования mx Механизм

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

• Использовать IPv6 или IPv4 

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

• Рассмотрите возможность сглаживания записей SPF

Некоторые ресурсы утверждают, что чем более плоская (или короткая) политика SPF, тем лучше репутация домена. Они предлагают этот метод для того, чтобы не превышать лимиты SPF-записей, установленные на поиск. Уплощение предполагает замену таких механизмов, как "include", на реальные IP-адреса, к которым они разрешаются, что напрямую сокращает количество DNS-поисков, необходимых при проверке. Однако сглаживание требует тщательного управления; если IP-адреса, стоящие за включенным сервисом, меняются, сглаженная запись становится устаревшей и должна обновляться вручную, чтобы предотвратить провал SPF-проверки легитимных писем. Автоматические инструменты для сглаживания SPF могут помочь в управлении этим процессом.

Роль DMARC в преодолении ограничений SPF

DMARC решает проблему ограничения SPF на человекочитаемый адрес From, требуя соответствия или выравнивания между человекочитаемым доменом поля From и доменом, аутентифицированным SPF (домен Return-Path).

Таким образом, если письмо проходит проверку SPF (что означает, что IP-адрес отправителя авторизован для домена Return-Path), но домен Return-Path не совпадает с доменом адреса From, DMARC-выравнивание для SPF не работает. Чтобы письмо прошло DMARC в целом, оно должно пройти либо SPF *с* выравниванием, либо DKIM *с* выравниванием. Это предотвращает распространенную тактику фишинга, когда адрес From подделывается, а путь Return-Path проходит SPF. DMARC также вводит возможности отчетности, предоставляя владельцам доменов информацию об электронных письмах, утверждающих, что они принадлежат их домену, включая результаты аутентификации (SPF, DKIM, DMARC, выравнивание) и информацию об источниках отправки. Такая возможность помогает выявить неправильную конфигурацию, проблемы с пересылкой и попытки злонамеренной подмены.

Как сглаживание записей SPF помогает преодолеть ограничение на 10 DNS-поисков

Сплющивание записей SPF это техника, используемая для оптимизации записей SPF (Sender Policy Framework) с целью преодоления ограничения на 10 DNS-поисков для SPF. Ограничение в 10 DNS-поисков - это ограничение, налагаемое многими DNS-резолверами, которое ограничивает количество DNS-запросов, которые могут быть выполнены при проверке SPF-записи для домена.

Когда письмо получено, почтовый сервер получателя запрашивает в DNS домен отправителя по его SPF-записи, чтобы проверить, имеет ли отправитель право отправлять письма с этого домена. В записях SPF часто используются такие механизмы, как "include", "a", "mx" и "ptr", которые требуют поиска в DNS. Если SPF-запись содержит много таких механизмов, особенно вложенных include (когда SPF-запись включаемого домена также содержит include), она может быстро превысить лимит в 10 DNS-запросов, что приведет к сбоям в проверке SPF (Permerror) и потенциальным проблемам с доставкой электронной почты.

Для преодоления этого ограничения используется сглаживание SPF-записей. Уплощение записи SPF - это техника, которая заменяет механизмы, вызывающие поиск (в основном 'include', но потенциально также 'a' и 'mx') в записи SPF на соответствующие им IP-адреса или диапазоны CIDR. Это уменьшает количество DNS-запросов, необходимых для проверки SPF-записи, поскольку IP-адреса указываются напрямую, а не требуют дополнительного поиска.

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

Проблемы внедрения SPF на крупных предприятиях

В SPF было введено ограничение на не более чем 10 поисков для предотвращения DoS- и DDoS-атак на инфраструктуру DNS во время проверки SPF. К сожалению, количество таких просмотров может быстро увеличиться, особенно в крупных компаниях. Ранее компании часто управляли собственными почтовыми серверами, однако теперь они в значительной степени зависят от многочисленных сторонних отправителей для маркетинга, транзакционных писем, CRM, систем поддержки и т. д. Каждому стороннему сервису часто требуется механизм 'include' в SPF-записи, что считается одним поиском, а их собственные SPF-записи могут содержать дополнительные поиски. Это создает проблему, поскольку добавление множества сервисов может быстро привести к тому, что домен достигнет или превысит лимит в 10 просмотров, что приведет к проблемам пермеррора, описанным выше. Управление этими многочисленными источниками и соблюдение лимита при обеспечении авторизации всей легитимной почты становится серьезной задачей.

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

Ахона Рудра

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

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

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

• Эффективна ли холодная электронная почта в 2025 году? Лучшие практики для охвата аудитории и обеспечения безопасности - 20 июня 2025 г.
• Пример из практики DMARC MSP: Как PrimaryTech упростила защиту клиентских доменов с помощью PowerDMARC - 18 июня 2025 г.
• Ложные срабатывания DMARC: Причины, способы устранения и руководство по предотвращению - 13 июня 2025 г.