У меня есть основной домен с (теперь) действительной записью SPF, но мы также программно создаем множество поддоменов для клиентов через cpanel PHPXML API. Эти поддомены не предназначены для отправки почты.
Когда мы их создаем, они получают запись A моего IP и запись TXT «v = spf1 + a + mx + ip4: [MY IP]? All». Это все записи DNS, которые у них есть
В последнее время у нас было много спуфингов электронной почты, и мы поняли, что для нашего основного домена существует недопустимый (дублированный SPF). Мы только что исправили это, но не уверены, если:
1) Могут ли спамеры по-прежнему подделывать электронную почту с поддоменов без записей MX с текущим перечисленным SPF?
2) Не лучше ли иметь SPF для поддоменов, чем тот, который я указал?
3) Есть ли способ предотвратить отправку / подделку электронной почты поддоменами через SPF моего основного домена?
Вот SPF основного домена, на который наш хост предложил переключиться: «v = spf1 a mx ptr a: dedrelay. [Webhost] .com include: dedrelay. [Webhost] .com ~ all»
На субдомены не влияет запись SPF основного домена. Если у вас есть несколько поддоменов, которые, как вы знаете, никогда не будут отправлять почту, лучше всего определить запись SPF для -all для каждого из них. Таким образом, Интернет также может узнать, что вы намереваетесь никогда не отправлять электронную почту.
редактировать: если для поддомена нет записи SPF, получатели, проверяющие SPF, не увидят никаких связанных с SPF причин для его блокировки.
Да, SPF ничего не сделает, чтобы помешать кому-либо принимать почту с поддомена без записи MX. Они могут решить не делать этого, но до тех пор, пока это разрешится - а иногда даже если это не так, - они могут решить. Это не проблема SPF.
Ваша текущая запись SPF ничего не сделает для предотвращения спуфинга на ваших поддоменах, потому что, как я уже сказал, на поддомены не влияет запись SPF основного домена.
Мне очень жаль, что у вас будет много работы, но если вы хотите использовать SPF, чтобы посоветовать получателям отклонять электронные письма с этих поддоменов, вам нужно будет определить для них записи SPF. Вот как работает протокол.
Хотя не рекомендуется в RFC 7208, вы можете использовать поддомены с подстановочными знаками для определения записей SPF. Но если какой-либо из поддоменов, для которых вы хотите запретить почту, имеет существующие записи ресурсов любого типа (что, вероятно, является единственной причиной, по которой вы захотите это сделать), вам нужно будет явно определить запись SPF для этого под- домен в любом случае.
Пример из RFC:
EXAMPLE.COM. MX 10 A.EXAMPLE.COM
EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
*.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
A.EXAMPLE.COM. A 203.0.113.1
A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
Итак, если позже будет определена запись для B.EXAMPLE.COM. вам также придется явно определить для него запись SPF.
Это определенно ограничивает полезность записи с подстановочными знаками для этой цели, но это трудно сказать из вашего вопроса.
Используйте DMARC, так как он автоматически просматривает «Организационный» домен, если в поддомене нет записи DMARC. https://www.valimail.com/blog/how-dmarc-handles-domains-and-subdomains-in-email-addresses-part-1/