Adicionando um registro SPF para terceiros, mas não tenho um para o meu próprio domínio

Temos um serviço de terceiros enviando alguns emails em nosso nome. Eles estão usando nosso nome de domínio nos emails de saída. Eles solicitaram que configurássemos um registro SPF para eles.

Atualmente, não temos um registro SPF definido para nosso próprio domínio, que é o mesmo que o terceiro está "falsificando".

Minha preocupação é que, se adicionarmos um registro para terceiros sem definir o nosso, também e-mails provenientes de nossos servidores poderão ser rejeitados.

Minha preocupação é válida?

email spf

— k1DBLITZ
fonte

Quão difícil será para você criar um?

— Michael Hampton

Não é difícil. O problema em potencial, a meu ver, é que existem vários serviços de terceiros que estão falsificando nosso domínio e, se eu não adicionar registros SPF para todos, que, ao adicionar apenas 1, eu poderia invalidar os outros quando os servidores de recebimento aleatório pesquisam o registro SPF do nosso domínio e veem os nomes / IPs que não correspondem.

— K1DBLITZ

Respostas:

Se você não possui um registro SPF, os receptores geralmente não são seguros e aceitam seu email (embora isso esteja começando a mudar). Assim que você fornecer um registro SPF, deverá incluir todos os remetentes legítimos de correio, pois, caso contrário, os não listados poderão ser tratados como possíveis fontes de falsificação.

A rigor, você pode incluir ~allou ?allevitar a lista de todos os remetentes de correio, mas se fizer isso, não obterá nenhum benefício com o registro SPF, exceto para testes de precisão.

Idealmente, seus terceiros já terão um registro SPF genérico e você pode simplesmente adicionar o include:spf.thirdparty.domelemento ao seu registro. Se não, você pode criar seu próprio registro para eles e encadeá-lo de qualquer maneira, para facilitar o gerenciamento administrativo.

Por exemplo, se você é contoso.com:

thirdparty1.spf.contoso.com txt 'v=spf1 ... -all' # list their mail senders for you
thirdparty2.spf.contoso.com txt 'v=spf1 ... -all' # list their mail senders for you
spf.contoso.com txt 'v=spf1 ... -all'             # list your mail senders
contoso.com txt 'v=spf1 include:spf.contoso.com include:thirdpart1.spf.contoso.com include:thirdparty2.spf.contoso.com -all'

Alguns recursos úteis:

O DMARC está subsumindo SPF e DKIM e vale a pena considerar. Ele está sendo usado ativamente pelo Google, Yahoo e outros para validar e-mails recebidos, https://dmarc.org/overview/
Uma lista de práticas recomendadas ao configurar um registro SPF, http://www.openspf.org/Best_Practices
Apesar do nome, uma receita útil para configurar um registro SPF, http://www.openspf.org/FAQ/Common_mistakes

— roaima
fonte

Você tem uma fonte sobre isso?

— Aaron Hall

@AaronHall esses links de recursos são suficientes? Se não, você pode esclarecer o que você está procurando

— roaima

Você pode colocar seu serviço de terceiros em um registro SPF com uma regra neutra para outros servidores:

?all

E inclua pelo menos seus próprios servidores de correio com:

+mx

É bom ter um registro SPF no seu domínio. Comece a adicionar uma lista branca e neutra para outras pessoas e, quando você tiver um registro SPF atualizado com todos os seus servidores, poderá alterar o padrão para falha (-todos) ou falha suave (~ todos).

Há uma boa documentação aqui e muitas outras informações úteis em openspf.org

— mick
fonte

Parte do problema que enfrento é que não tenho uma lista atualizada de todas as outras empresas que enviam email em nosso nome. Você está dizendo que, se eu usar sua abordagem, posso adicioná-los aos registros SPF à medida que são descobertos sem afetar o fluxo de mensagens de produção? Você pode fornecer uma sintaxe de exemplo específica para domínios fictícios? Estive revisando as informações que você vinculou e são muito úteis, mas não posso me dar ao luxo de entender isso errado.

— K1DBLITZ

Você pode fazer isso passo a passo: primeiro adicione seu serviço de terceiros, seu mx e neutro para todos os outros: "a: your3rppart mx? All". Atualize seu SPF com outros servidores. Achamos que todos eles alteram a política padrão para falha suave ou falha

— mick

Sério, o SPF sem -allnão é apenas completamente inútil, mas alguns administradores o usam como um sinal ativo de spammers. Não faça isso.

— MadHatter

- tudo é melhor do que tudo - se você não sabe o que está fazendo, as políticas da DMARC ainda se aplicam a - tudo como - tudo e muitos ESPs grandes não se importam com - tudo por causa da primeira declaração

— Jacob Evans

Sério, o SPF sem -all não é apenas completamente inútil, mas alguns administradores o usam como um sinal ativo de spammers. Não faça - eles devem corrigir os sistemas danificados que não estão seguindo a especificação do SPF; " Se os proprietários do domínio optarem por publicar registros SPF, é RECOMENDADO que eles terminem em" -todos " " - ietf.org/rfc/rfc4408.txt - Não é obrigatório. SoftFail é um estado distinto.

— precisa