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

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

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

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

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

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

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

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

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

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

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

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

Влияние размера записи 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-записи, установленные для поиска. Тем не менее, уплощение не рекомендуется, так как это делает вашу запись более подверженной ошибкам и требует регулярных обновлений. 

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

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

Таким образом, если письмо проходит проверку SPF, но домен не совпадает с адресом From, DMARC отменяет эту проверку подлинности. Это означает, что письмо не прошло проверку подлинности.

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

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

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

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

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

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

SPF принудительно ограничивается не более чем 10 поисками для предотвращения DoS и DDoS атак. К сожалению, эти поиски могут очень быстро увеличиться, особенно в крупных компаниях. Ранее компании эксплуатировали собственные почтовые серверы, однако теперь они используют сторонние отправители. Это создает проблему, поскольку каждый из них может занимать до 3 или 4 серверов, и вы очень быстро достигаете предела.

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

Ахона Рудра

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

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

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

• Настройка DKIM: Пошаговое руководство по настройке DKIM для обеспечения безопасности электронной почты (2025) - 31 марта 2025 г.
• PowerDMARC признана лидером в области грид-технологий DMARC в G2 Spring Reports 2025 - 26 марта 2025 г.
• Как распознать поддельные письма с подтверждением заказа и защитить себя - 25 марта 2025 г.