SPF Softfail и SPF Hardfail: В чем разница?
Время чтения: 5 мин
С SPF (Sender Policy Framework) вы можете настроить свою систему так, чтобы она реагировала на сбои аутентификации одним из двух способов: Hardfail или SoftfailВ этом блоге мы обсудим различия между SPF hardfail и softfail, синтаксис для настройки обоих способов, а также их применение. Итак, давайте погрузимся в тему!
Ключевые выводы
- SPF hardfail указывает на то, что отправитель электронной почты не авторизован, что часто приводит к отклонению письма.
- SPF softfail предполагает, что письмо все еще может быть от неавторизованного отправителя, но не отвергает его полностью, позволяя провести дальнейшую проверку.
- Применение строгих политик SPF необходимо для предотвращения несанкционированного подражания электронной почте и защиты репутации бренда.
- Сочетание SPF с DMARC добавляет важный уровень безопасности, позволяя лучше справляться с отказами в проверке подлинности электронной почты.
- Регулярный контроль результатов проверки подлинности SPF поможет поддерживать оптимальный уровень безопасности электронной почты и предотвратить потенциальные уязвимости.
Разница между SPF Softfail и Hardfail
В таблице, представленной ниже, объясняется основная разница между SPF hardfail и softfail.
| Синтаксис SPF | Тип неудачи | Статус | Соответствующее действие, предпринятое получателем |
|---|---|---|---|
| v=spf1 include:domain1.com -all | Hardfail | Отправитель неавторизован | Электронное письмо может быть отклонено |
| v=spf1 include:domain1.com ~all | Softfail | Отправитель может быть неавторизованным | Электронное письмо доставлено, но помечено как подозрительное или потенциально мошенническое |
SPF Hardfail и Softfail: Как определено в RFC
Согласно RFC 7208 Г.:
- Результат "Fail" для SPF напрямую указывает на то, что отправитель электронной почты не авторизован доменом-отправителем. "Fail" является синонимом результата Hardfail (-all), который явно указывает на несанкционированное использование домена.
- Однако гораздо более спокойным подходом является настройка SPF Softfail, которая указывает на "вероятный" признак несанкционированного использования домена.
Упростите SPF с помощью PowerDMARC!
Обработка отказов получателя для 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 Softfail и Hardfail: Что мы рекомендуем?
В случае ретрансляции электронной почты через 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 Softfail выигрывает у механизма Hardfail. Это значительно менее рискованный подход, который оставляет возможность для проверки, просто отмечая авторизованные письма, а не отклоняя их.
Как работают записи 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 для аутентификации доменов и создания отчетов предоставляет комплексные решения SPF и DMARC для предприятий любого размера. Зарегистрируйтесь сегодня для бесплатной пробной версии!
Эксперт по безопасности доменов и электронной почты в PowerDMARC
Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.
Последние сообщения Юнеса Тарады (см. все)
- Нейтральный механизм SPF (?all) объясняется: Когда и как его использовать - 23 июня 2025 г.
- Сбои в выравнивании доменов DKIM - исправления в RFC 5322 - 5 июня 2025 г.
- DMARCbis - что меняется и как подготовиться - 19 мая 2025 г.
