SPF Softfail и SPF Hardfail: В чем разница?

Узнайте о разнице между SPF Softfail и Hardfail, лучших практиках и о том, как защитить свою рабочую электронную почту с помощью PowerDMARC. Полное руководство для ИТ-менеджеров и администраторов электронной почты.

С SPF (Sender Policy Framework) вы можете гибко настроить свою систему для реагирования на сбои аутентификации одним из двух способов: Hardfail или Softfail. В этом блоге наши эксперты из PowerDMARC расскажут вам о различиях между SPF hardfail и softfail, о том, как настроить каждый из них, а также о реальных примерах использования для ИТ- и безопасности. Итак, приступим!

Что такое сбой SPF?

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

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

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

Результаты аутентификации SPF

• Пропустить: IP-адрес отправителя авторизован в записи SPF.
• Ошибка (серьезная ошибка): IP-адрес отправителя явно не авторизован (-all)
• Мягкая ошибка: IP-адрес отправителя, вероятно, не авторизован (~все)
• Нейтральный: нет заявления о политике в отношении отправителя (?all)
• Нет: для домена не существует записи SPF.
• TempError: Временная ошибка поиска DNS
• PermError: Постоянная ошибка в синтаксисе записи SPF

Каждый результат SPF является явным заявлением о статусе авторизации отправителя. «Fail» — это явное заявление о том, что отправитель не авторизован, а «softfail» — слабое заявление, указывающее на вероятное, но не окончательное отсутствие авторизации.

Ошибка SPF возникает, когда проверка аутентификации возвращает результат «Fail» (Неудача) или «Soft Fail» (Мягкая неудача), что указывает на то, что отправляющий сервер может не иметь права отправлять электронные письма для этого домена.

SPF Hard Fail и Soft Fail: объяснение основных различий

В таблице, представленной ниже, объясняется основная разница между SPF hardfail и softfail.

Примечание: Механизм hardfail («-all») предназначен для обеспечения максимальной защиты от фишинга и поддельных электронных писем путем отклонения сообщений от неавторизованных отправителей. Однако неправильная настройка может привести к недоставке электронных писем и 100% отказу от неавторизованных источников.

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

SPF Hardfail против Softfail: как определено в RFC 

Согласно RFC 7208 Г.:

• Результат "Fail" для SPF напрямую указывает на то, что отправитель электронной почты не авторизован доменом-отправителем. "Fail" является синонимом результата Hardfail (-all), который явно указывает на несанкционированное использование домена. 
• Однако гораздо более спокойный подход заключается в настройка SPF Softfail, который указывает на «вероятное» несанкционированное использование домена.

Обработка отказов получателя для Hardfail и Softfail 

В разделе 8.4RFC определяет следующие сценарии обработки результатов для SPF hardfail и SPF softfail: 

1. SPF Hardfail / Fail 

В случае результата "Fail" или hardfail ваш сервер-получатель может решить отклонить неавторизованное письмо. Если это SMTP-транзакция, должен быть возвращен код ошибки 550 5.7.1 с соответствующим описанием ошибки. 

Если сервер получателя не отклонил письмо во время SMTP-транзакции, RFC рекомендует получателям записывать результаты SPF в заголовке Received-SPF или Authentication-Results. 

2. SPF Softfail

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

Какой режим отказа SPF следует использовать?

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

Выберите SPF Hard Fail (-all) в следующих случаях:

• Вы имеете полный контроль над всеми источниками отправки электронных писем
• Ваша инфраструктура электронной почты является зрелой и хорошо документированной.
• Безопасность является главным приоритетом по сравнению с доставкой
• Вы редко используете сторонние почтовые сервисы
• У вас налажен комплексный мониторинг DMARC

Выбрать SPF Soft Fail (~all) Когда:

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

Типичные случаи использования SPF Hard Fail и Soft Fail

Случаи использования SPF Hard Fail:

• Финансовые учреждения: Банки и кредитные союзы, требующие строгой аутентификации электронной почты
• Государственные учреждения: Организации с высокими требованиями к безопасности
• Домены для защиты бренда: Домены, используемые исключительно для защиты бренда
• Домены для транзакционных писем: Выделенные домены для автоматических писем

Примеры использования SPF Soft Fail:

• Маркетинговые домены: Домены, использующие несколько платформ для электронного маркетинга
• SaaS-компании: Организации со сложной инфраструктурой электронной почты
• Образовательные учреждения: Университеты с несколькими факультетами и системами электронной почты
• Тестовые среды: Домены на этапе внедрения SPF

Реальный сценарий: если вы являетесь ИТ-менеджером, отвечающим за безопасность электронной почты в средней по размеру SaaS-компании, использующей Google Workspace, Salesforce и Mailchimp, вы можете начать с мягкой ошибки, чтобы обеспечить доставку всех легитимных писем, одновременно контролируя и уточняя свою запись SPF.

Когда следует использовать SPF Hard Fail или Soft Fail?

В случае ретрансляции электронной почты через SMTP вы можете рассматривать SPF softfail как более безопасную ставку по сравнению с hardfail. Давайте узнаем, как это сделать: 

Ретрансляция электронной почты SMTP - это автоматическая передача сообщений с одного сервера на другой. Это означает, что электронная почта передается на сервер, IP-адрес которого не указан в SPF-записи вашего домена. Это делает его неавторизованным отправителем вашей электронной почты, хотя на практике он является легитимным. 

Есть ли у вас какой-либо контроль над этой деятельностью? Ответ - нет, поскольку электронная почта передается автоматически на стороне получателя. При таких обстоятельствах SPF не будет работать для переданных писем. 

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

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

Как указано в RFC 7489 Раздел-10.1 если проверки SPF выполняются до операций DMARC, наличие префикса "-" в механизме SPF отправителя, например "-all", может привести к немедленному отклонению писем. Такое отклонение происходит на ранних этапах процесса обработки электронной почты, еще до того, как будет произведена обработка DMARC.

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

Следовательно, в этих условиях механизм SPF Soft fail превосходит механизм Hard fail. Это значительно менее рискованный подход, который оставляет возможность для пересмотра, просто помечая авторизованные электронные письма, а не отклоняя их. 

Уязвимости обхода SPF и ретрансляции

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

Распространенные сценарии обхода SPF:

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

Лучшие практики по смягчению последствий:

• Внедрите DKIM вместе с SPF для дополнительной аутентификации
• Используйте DMARC для корректной обработки сбоев SPF
• Регулярно проводить аудит и обновлять записи SPF
• Отслеживайте отчеты об аутентификации электронной почты на предмет аномалий

Как работают записи SPF?

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

v=spf1 include:_spf.google.com ~all

В этой SPF-записи вы разрешаете все электронные письма, исходящие с IP-адресов, перечисленных в SPF-записи Google. Механизм отказа определен в самом конце записи (~all), т. е. Softfail. 

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

Стратегии внедрения безопасного SPF

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

1. Используйте инструмент для создания SPF-записей

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

2. Используйте соответствующие механизмы SPF

Используйте такие механизмы SPF, как "include", "a" и "IP4", чтобы указать разрешенные источники отправки. Подходите к выбору механизмов с учетом особенностей вашей инфраструктуры электронной почты и убедитесь, что они точно отражают ваши методы отправки электронной почты.

3. Поддерживайте и оптимизируйте запись SPF

Ваша запись Sender Policy Framework должна поддерживаться и оптимизироваться, чтобы предотвратить ее неисправность. SPF имеет тенденцию выходить из строя, когда количество авторизованных отправителей превышает лимит в 10 DNS-запросов на стороне получателя. Для поддержания оптимального лимита запросов наш хостинг SPF — лучший выбор! Мы помогаем владельцам доменов оптимизировать SPF одним щелчком мыши, чтобы не превышать лимиты поиска и аннулирования и поддерживать безошибочную работу SPF. 

4. Сочетание SPF с DMARC

Развертывание DMARC (Domain-based Message Authentication, Reporting, and Conformance) наряду с SPF обеспечивает дополнительный (но важный) уровень безопасности. DMARC позволяет владельцам доменов определять политики обработки электронной почты, включая действия, которые следует предпринять в отношении писем, не прошедших проверку SPF.

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

5. Реализация строгих политик обработки отказов SPF

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

6. Мониторинг результатов проверки подлинности SPF

Внедрить отчеты DMARC для отслеживания результатов SPF-аутентификации, таких как SPF pass и fail, а также ошибок выравнивания. A DMARC-анализатор поможет вам разобрать и проанализировать данные SPF-аутентификации в упорядоченном и понятном для человека виде.

Заключительные слова

Прямого ответа на вопрос "Что лучше? SPF hardfail или softfail". Хотя тег hardfail может обеспечить вам лучшую безопасность, выбор правильного решения для контроля источников отправки становится решающим. 

Расширенная платформа PowerDMARC и отчетности DMARC обеспечивает комплексную SPF и DMARC для предприятий любого размера. 

Попробуйте платформу с сертификатом SOC2, которой доверяют тысячи организаций по всему миру. Начните бесплатную пробную версию сегодня!

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

1. В чем причина мягкой ошибки SPF?

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

2. Что такое 550 5.7.0 SPF hard fail?

Ошибка «550 5.7.0 SPF hard fail» возникает, когда почтовый сервер отклоняет сообщение, потому что IP-адрес отправителя не авторизован в записи SPF домена, которая заканчивается на «-all». Это постоянная ошибка, которая препятствует доставке электронной почты и указывает на то, что сервер-получатель имеет строгие правила применения SPF.

3. Когда вы получите жесткую ошибку SPF?

Вы получаете жесткую ошибку SPF, когда: 1) IP-адрес отправителя не указан в записи SPF домена, 2) запись SPF заканчивается на «-all» (политика жесткой ошибки), 3) электронное письмо отправлено с неавторизованного сервера или службы, 4) в записи SPF есть ошибки конфигурации или 5) домен реализовал строгие политики аутентификации электронной почты.

4. Что означает символ «hard fail» в SPF?

Символом жесткого отказа в SPF является знак минус «-», за которым следует «all» (записывается как «-all»). Этот механизм указывает получающим почтовым серверам отклонять все электронные письма, которые не соответствуют авторизованным IP-адресам или доменам, указанным в записи SPF. Это самая строгая политика SPF, обеспечивающая наивысший уровень безопасности аутентификации электронной почты.

5. Должен ли я использовать жесткий или мягкий отказ SPF для своего бизнеса?

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

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

Юнес Тарада

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

Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.

Последние сообщения Юнеса Тарады (см. все)

• Объяснение DMARCbis — что меняется и как подготовиться - 16 апреля 2026 г.
• Неверный формат серийного номера SOA: причины и способы устранения - 13 апреля 2026 г.
• Как отправлять защищенные письма в Gmail: пошаговое руководство - 7 апреля 2026 г.