IPv4 в SPF-записях для родительского и поддомена

Вопрос или проблема

Допустим, у меня есть домен: example.com. У меня также есть поддомен: test.example.com.

Если у меня есть значения IPv4 в записи SPF для основного домена, но нет значений IPv4 в записи SPF для поддомена, вызовет ли это какие-либо потенциальные проблемы?

SPF-записи не наследуются поддоменами, поэтому настройки, сконфигурированные в корневом домене, не влияют на поддомен.

Или, другими словами, если вы настроили SPF-запись на example.com, любое письмо, отправленное с test.example.com, будет показывать, что у него нет SPF-записи.

Если вы хотите иметь возможность отправлять электронную почту с test.example.com, вы можете либо создать там SPF-запись с теми же настройками, либо создать такую запись:

v=spf1 include:example.com -all

что, по сути, говорит любому, кто запрашивает ее, проверить SPF от example.com для перечисленных записей. Это означает, что любые обновления основной записи применяются к поддомену без необходимости редактировать обе записи.

Кроме того, если цель состоит в прекращении отправки электронных писем с поддомена, вы можете добавить там такую запись:

v=spf1 -all

что, вместо того чтобы просто иметь отсутствие SPF (следовательно, получатели могут все еще принимать это в зависимости от своих настроек), явно говорит, что нет легитимных источников электронной почты для test.example.com, поэтому любое письмо с этого поддомена должно быть отклонено.

Ответ или решение

Концепция SPF (Sender Policy Framework) является важной частью современной системы электронной почты, защищая домены от подмены и несанкционированной рассылки. На основе вашего вопроса мы разберем, что происходит с записями SPF в контексте родительского домена и субдомена, используя пример с доменами example.com и test.example.com.

Теоретическая часть:

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

Каждая запись SPF начинается с версии протокола (v=spf1) и перечисляет политики и списки IP-адресов, которым разрешено отправлять письма:

ip4 и ip6 — указывают на разрешенные IPv4 и IPv6 адреса.
include — позволяет включить правила из других SPF записей.
-all, ~all, +all и ?all — определяют политику в отношении прочих IP-адресов, не указанных в записи.

Важно подчеркнуть, что SPF-записи не наследуются субдоменами. Это значит, что даже если у вас настроена корректная SPF-запись на уровне родительского домена (example.com), она не будет автоматически применяться к его субдоменам, таким как test.example.com.

Практическая сторона:

Теперь, когда мы знаем, что SPF-записи не наследуются субдоменами, возникает следующий вопрос: есть ли потенциальные проблемы, если у субдомена (например, test.example.com) нет собственной SPF-записи?

Отправка электронной почты от субдомена: Если у вас есть сервера, которые отправляют письма от имени test.example.com, и у этого субдомена нет SPF-записи, получатели могут пометить эти письма как неавторизованные или небезопасные. Это может привести к увеличению вероятности попадания таких писем в спам.
Неправильная идентификация: Поскольку субдомены не наследуют SPF посредством родительского домена, почтовые серверы, проверяющие SPF, будут интерпретировать отсутствие SPF-записи как потенциальную угрозу.
Потенциальная незапланированная отправка: Если политики безопасности вашей организации включают использование субдоменов и предполагают отсутствие отправки писем от определенных субдоменов, то этим должно управлять путем явного задания политики SPF с v=spf1 -all. Это укажет на то, что ни один сервер не может легитимно отправлять почту от имени этого субдомена.

Рекомендации по применению:

Исходя из вышесказанного, вам необходимо сделать следующее:

Создать SPF-запись для субдомена: Если вам нужно отправлять письма от имени test.example.com, создайте для него SPF-запись. Вы можете настроить её аналогично родительскому домену или использовать директиву include, чтобы субдомен консультировался с записью родительского домена:
```
v=spf1 include:example.com -all
```
Это упростит управление записями SPF, так как изменения в основном домене автоматически применятся и к субдомену.
Запретить отправку от имени субдомена: Если вы хотите заблокировать отправку писем от имени test.example.com, добавьте для него запись:
```
v=spf1 -all
```
Это укажет на отсутствие легитимных источников отправки электронной почты для данного субдомена, что повысит защиту от злоупотреблений.

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