Em primeiro lugar, apenas para esclarecer sobre include , s5.2 do RFC 4408 diz :
Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first.
Quanto a saber se o MX RR em um registro include d se refere ao seu MX ou MX do domínio include d, concedo com alegria que A página de protocolo do OpenSPF é incrivelmente inútil sobre o assunto, porque o exemplo usa o mesmo domínio para o registro de origem e incluído . Mas o RFC é (muito ligeiramente) mais claro, quando escreve (novamente no s5.2):
The "include" mechanism triggers a recursive evaluation of check_host(). The domain-spec is expanded as per Section 8. Then check_host() is evaluated with the resulting string as the <domain>. The <ip> and <sender> arguments remain the same as in the current evaluation of check_host().
Eu destaquei o bit que interpreto como significando que mx e registros semelhantes são avaliados no contexto do domínio include d. Mas como nada é tão bom quanto o Real Data, defini os seguintes subdomínios em um dos domínios da minha família ( waide.me.uk e obrigado pelo empréstimo temporário!):
foo IN TXT "v=spf1 include:bar.waide.me.uk -all"
foo IN A 10.5.5.5
bar IN TXT "v=spf1 mx -all"
bar IN MX 5 baz.bar
baz.bar IN A 78.46.204.154
Quando eu uso o testador de Beveridge (que openspf.org recomenda), ele diz que o e-mail de [email protected] que chega de 78.46.204.154 é um passe de SPF. Note que nenhuma referência é feita para esse endereço em qualquer lugar em foo.waide.me.uk . Há uma referência MX no registro bar.waide.me.uk do included , mas foo.waide.me.uk não tem MX . Se o MX no registro include d não fosse avaliado no contexto do domínio include d ( bar.waide.me.uk ), ele não poderia resolver nada.
E apenas para completar, quando eu removo o registro SPF de include de foo.waide.me.uk , então, como seria de esperar agora, Beveridge relata uma falha.