Configurando registros SPF no servidor dedicado

Question

Eu tenho uma pergunta em relação aos registros SPF em um ambiente de hospedagem dedicado. Desejo configurar um registro SPF para meu servidor dedicado, mas não tenho certeza se meu entendimento está correto.

Primeira pergunta: Preciso configurar o registro SPF para APENAS o domínio que contém os registros NS e PTR ou preciso configurá-lo para cada domínio no servidor?

Se eu só precisar configurá-lo para o domínio NS, ele poderá ser configurado em cada domínio para substituir o domínio NS?

Além disso, se for apenas para o domínio NS, como posso garantir que meus clientes com servidores SMTP remotos não tenham problemas para enviar e-mails? ie. Google Apps ou registros MX externos.

por exemplo: Meu domínio NS é example.com e um de meus clientes é helloworld.com Preciso definir um registro SPF no helloworld.com, example.com ou em ambos? O registro SPF no example.com afetará o helloworld.com se eu não colocar um registro SPF no helloworld.com?

    

Answer 1

(Resposta editada à luz das edições da pergunta.)

Depende. Os registros SPF devem ser aplicados ao envelope From , não ao cabeçalho From: . Se o seu servidor está usando o SRS, tudo deve ficar bem; o envelope From será reescrito para example.com , e o seu registro SPF irá cobri-lo. Caso contrário, dependerá do que seus MUAs (e / ou servidores de correio internos) definem o envelope From a ser; Se for helloworld.com , sim, o registro SPF (se existir) precisará permitir que sua infra-estrutura seja enviada.

Dito isto, se eles são seus clientes, não há nenhum dano neles, incluindo você em seus registros SPF, o que eles podem fazer com um simples include: . É melhor prevenir do que remediar, e não se esqueça de ficar de olho no limite de pesquisas de DNS.

Quanto à última parte da sua pergunta, você provavelmente deve ler nossa questão canônica sobre a criação de registros SPF .

    

Answer 2

O SPF precisa ser configurado para cada domínio. Embora você possa usar curingas, isso cria efetivamente todos os subdomínios possíveis que correspondem ao curinga. É raro você querer usar curingas. O SPF não se aplica a PTR records, e seus NS domains normalmente não devem enviar e-mails.

Se você quiser proteger os domínios que não devem estar enviando e-mails para enviar spam, use um registro SPF como v=spf1 -all . Eu recomendaria fazê-lo, mas muitos domínios não têm essa cobertura. (Eu vi muitos deles sendo rejeitados pelo meu filtro de spam.) Isso deve incluir domínios da web que alguns spammers tendem a preferir.

O domínio usado no envelope do endereço, From: , Sender: e cabeçalhos semelhantes deve ter um registro SPF como v=spf1 a mx -all . Isso causará problemas aos remetentes que usam outros servidores SMTP para enviar e-mails de seu domínio. O SPF será aplicado ao envelope do endereço que, na maioria dos casos, deve corresponder a um dos cabeçalhos de endereço do remetente.

Se você quiser permitir que outros servidores SMTP enviem em nome de seu domínio, você poderá usar o mecanismo include . Há limites para o número de pesquisas de domínio que podem ser aplicadas, portanto, o aninhamento profundo com mecanismos como A ou MX pode causar falha na verificação antes que todos os mecanismos sejam concluídos. Também é provável que você importe um mecanismo ~all que irá derrotar significativamente o propósito de usar o SPF.

A configuração do seu servidor SMTP para aceitar conexões autenticadas de seus usuários na porta de submissão (587) permitirá que eles usem seu servidor de e-mail para enviar e-mails. A porta de envio deve ser configurada para ativar o StartTLS. A autenticação deve exigir TLS.

Seu servidor SMTP deve ter um registro SPF que permita enviar e-mail. Um registro como v=spf1 a -all seria apropriado.

Considere a possibilidade de consultar DMARC , que permitirá publicar uma política sobre como o e-mail SPF e o DKIM devem ser tratados. Você também pode receber feedback sobre o desempenho do seu domínio em suas políticas. Isso pode incluir indicações de que seu domínio está sendo usado para enviar spam.