Какую идентичность проверяет SPF
RFC 7208 описывает проверку использования доменных идентичностей MAIL FROM и HELO. Они относятся к SMTP-обмену и могут отличаться от видимого поля From. Поэтому фраза SPF настроен для нашего адреса требует уточнения: какой домен проверяется, какая система отправляет сообщение и какие условия наблюдал получатель. Красивое имя отправителя не отвечает на эти вопросы.
Владелец бизнеса может начать с карты потоков: рабочая почта, сайт, CRM, счета и рассылки. У каждого могут быть собственный отправляющий сервис и доменная идентичность. Разрешенный рабочий поток нельзя автоматически считать проверенным по результату другого. Для технического разбора нужны факты конкретного сообщения и доступные сведения о поддерживаемой конфигурации сервиса.
Это страница определения, а не инструкция по вставке одной универсальной записи. Случайная чужая конфигурация может разрешать ненужный источник или не учитывать нужную систему. Перед изменением требуется установить владельца домена, назначение зависимостей и приемку. Секреты и содержимое частной переписки для первого обсуждения не нужны.
Как понимать названия результатов
Результат SPF описывает конкретное вычисление, а не общий рейтинг домена или письма. Его интерпретируют вместе с проверяемой идентичностью, источником и условиями. Таблица служит ориентиром для разговора с администратором. Точный дальнейший порядок зависит от ситуации и доступных сведений принимающей стороны; один ярлык не устанавливает причину всех почтовых проблем.
| Результат | Что обсуждаем | Чего не выводим автоматически |
|---|---|---|
| pass | Источник прошел проверку для выбранной идентичности | Письмо безопасно и отправлено добросовестным человеком |
| fail или softfail | Результат соответствующего правила | Обязательно взломан настоящий ящик |
| neutral | Не получено положительное разрешение этим результатом | Определена вся причина недоставки |
| none | Подходящих данных для этого результата нет | Для всего бизнеса нет никакой защиты |
| temperror | Временную проблему вычисления | Нужно немедленно удалить рабочие зависимости |
| permerror | Постоянную ошибку политики или вычисления | Установлена причина без разбора контекста |
Запись, отправляющий сервис и реальное письмо
Политика публикуется в DNS, но наличие текста не подтверждает, что конкретное письмо ушло разрешенным маршрутом. Нужно сопоставить отправляющий сервис и фактическую идентичность. Если используются сторонние системы, у каждой должен быть владелец, который подтверждает назначение и актуальные инструкции. Неизвестный источник нельзя разрешать только потому, что он встречается в диагностике.
Для приемки полезно разделить наблюдения: конфигурация опубликована, нужная система использует ожидаемый маршрут, получен результат сообщения. Даже положительный итог последнего этапа не определяет папку у всех получателей. Такой способ записи помогает избежать ситуации, когда скриншот DNS считается доказательством законченной проверки всех потоков бизнеса.
Ограничения вычисления и изменение маршрута
SPF имеет ограничения вычисления, включая бюджет определенных элементов, обращающихся к DNS. Важны и вложенные достигнутые элементы, а не только число видимых include. Поэтому превышение лимита требует отдельного разбора. Не следует решать его случайным удалением сервиса без владельца и контрольной отправки затронутого маршрута.
Пересылка также может изменить условия, в которых выполняется проверка источника. Исходный отправитель и узел, передавший письмо дальше, не всегда являются одним объектом. Для вывода нужны сведения фактического пути, а не только начальный адрес. Если инструмент показывает потенциальную структуру политики, не называйте это измерением каждого реального сообщения.
Как SPF связан с DKIM и DMARC
SPF и DKIM проверяют разные свойства. DMARC использует согласование домена From с прошедшим механизмом: успешный согласованный SPF или DKIM может удовлетворить его условию. Текущий RFC 9989 опубликован в мае 2026 года. Не нужно превращать результат одной проверки в утверждение о прохождении другой без учета этой связи.
Даже согласованная аутентификация не подтверждает полномочие человека запросить оплату и не устраняет похожие чужие домены. При признаках доступа постороннего нужен отдельный разбор учетной записи и приложений. Доменная конфигурация и доступ к ящику являются связанными, но самостоятельными задачами, с разными подтверждениями и владельцами.
Как использовать понятие в работе с подрядчиком
Попросите назвать проверяемую идентичность, разрешенные системы, источник актуальной конфигурации и критерий приемки. В результате должны остаться проверенные маршруты и исключения, а для изменения нужны полномочия и возврат. Это полезнее обещания высокий балл SPF. Для отдельных ошибок и подготовки политики используйте соответствующие практические руководства.
CyberFixCrew является израильской компанией по кибербезопасности и помогает русскоязычному бизнесу по всему миру работать с почтой, сайтами и цифровой инфраструктурой. Практические израильские знания применяются к фактической среде и согласованному объему. В запросе укажите домен и отправляющие сервисы без паролей и полного архива сообщений.
- Назвать отправляющие системы и их владельцев.
- Установить фактическую SMTP-идентичность.
- Отделить запись DNS от результата сообщения.
- Учесть ограничения и связь с другими механизмами.
- Записать приемку, исключения и следующий шаг.