Rota 53 - Devo duplicar meus registros SPF como registros TXT?

O Amazon Route 53 suporta "Registros SPF" e "Registros TXT". A maioria da documentação que li me diz para listar meu registro SPF como um registro TXT. Entendo que o registro SPF é um padrão mais recente. Portanto, é correto duplicar meus registros SPF para que eles sejam listados como registros SPF e TXT para garantir compatibilidade com versões anteriores e também seguir o novo padrão? Não estou familiarizado com o DNS, por isso não tenho certeza se isso causaria algum problema ou se eu deveria me incomodar em duplicá-lo?

Meus registros são os seguintes:

"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"

Na verdade, não é correto que o SPFtipo RR seja o padrão mais recente (no contexto do comportamento SPF desejado). A fase experimental da especificação do SPF teve um novo tipo de registro atribuído, mas o caminho da migração não era claro e foi abandonado.

A versão atual da especificação SPF afirma especificamente:

Registos SPF deve ser publicado como um DNS TXT (tipo 16) Resource Record (RR) [RFC1035] única . O conteúdo de caracteres do registro é codificado como [US-ASCII]. O uso de tipos alternativos de RR de DNS foi suportado na fase experimental do SPF, mas foi descontinuado.

Em 2003, quando o SPF foi desenvolvido pela primeira vez, os requisitos para a
atribuição de um novo tipo de DNS RR eram consideravelmente mais rigorosos do que são agora. Além disso, o suporte para fácil implantação de novos
tipos de RR de DNS não foi amplamente implantado em servidores DNS e
sistemas de provisionamento . Como resultado, os desenvolvedores do SPF acharam mais fácil e mais
prático usar o tipo TXT RR para registros SPF.

Em sua revisão do [RFC4408], o grupo de trabalho do SPFbis concluiu que seu modelo de transição do tipo RR duplo era fundamentalmente defeituoso, uma vez que
não continha nenhum tipo comum de RR que os implementadores eram obrigados a servir
e que deviam verificar. Muitas alternativas foram consideradas para resolver
esse problema, mas, em última análise, o grupo de trabalho concluiu que era muito improvável
uma migração significativa para o tipo de SPF RR no futuro próximo
e que a melhor solução para resolver esse
problema de interoperabilidade era abandonar o suporte ao tipo de SPF RR de
SPF versão 1. Consulte o Apêndice A do [RFC6686] para obter mais informações.

As circunstâncias que cercam a implantação inicial do SPF há uma década são únicas. Se uma atualização futura do SPF fosse desenvolvida e não
reutilizasse os registros SPF existentes, ela poderia usar o tipo RR do SPF. O uso
do tipo TXT RR pelo SPF para dados estruturados não deve ser tomado como
precedente para futuros projetistas de protocolo. Uma discussão mais aprofundada sobre as
considerações de design ao usar novos tipos de DNS RR pode ser encontrada em
[RFC5507].

Como nota de rodapé, também havia um registro de ID do remetente (infelizmente chamado de "spf2.0", apesar de ser uma especificação diferente) em seu exemplo, as regras para esse tipo de registro ainda são experimentais e correspondem à versão experimental do SPF spec , nenhuma atualização foi publicada.

Sim, duplique-os; Não sei de antemão qual a proporção de verificadores de SPF realmente suporta o padrão atual para o tipo de registro, mas se eu fizesse um palpite, apostaria que provavelmente 10% dos verificadores não olharão apenas para um SPFregistro TXT.