O SPF registra detalhes de quais servidores têm permissão para enviar email para o seu domínio.
As perguntas 1 a 3 resumem realmente todo o objetivo do SPF: você deve listar os endereços de todos os servidores autorizados a enviar e-mails provenientes do seu domínio.
Se você não tiver uma lista exaustiva no momento, geralmente não é uma boa ideia configurar um registro SPF. Além disso, um domínio pode ter apenas um registro SPF, portanto, você precisará combinar todas as informações em um único registro.
As perguntas individuais realmente ajudam a dividir a lista para você.
- solicita outros domínios cujos servidores de email podem retransmitir mensagens de você; se você tem, por exemplo, um servidor MX secundário em mail-relay.example.org, e esse é o servidor de correio principal (registro MX) do domínio
example.org
, insira mx:example.org
. Seu registro SPF deve incluir o registro MX do seu próprio domínio em quase todas as circunstâncias ( mx
).
- pede seus netblocks ip. Se você tiver servidores colocados em 1.2.3.0/28 e o espaço de endereço do escritório for 6.7.8.0/22, digite
ip4:1.2.3.0/28 ip4:6.7.8.0/22
. O espaço IPv6 deve ser adicionado como, por exemplo ip6:2a01:9900:0:4::/64
.
- se (por exemplo) você também tiver uma máquina desligada no escritório de outra pessoa que precise enviar e-mails do seu domínio, insira-a também, por exemplo
a:mail.remote.example.com
.
Os usuários do seu celular são problemáticos. Se eles enviarem e-mail conectando-se ao seu servidor de correio usando, por exemplo, SMTP AUTH, e enviando através desse servidor, você terá que lidar com eles, listando o endereço do servidor de correio em (2). Se eles enviam e-mail por apenas conectar a qualquer servidor de correio oferta do provedor de 3G / HSDPA, então você não pode fazer SPF significativamente até que você tenha rearchitected sua infra-estrutura de e-mail para que você faça controlar cada ponto do qual supostamente email para ser de você atinge o Internet.
A pergunta 4 é um pouco diferente e pergunta o que os destinatários devem fazer com o e-mail que afirma ser do seu domínio e que não vem de um dos sistemas listados acima. Existem várias respostas legais, mas as únicas interessantes são ~all
(falha leve) e -all
(falha grave). ?all
(sem resposta) é tão inútil quanto ~all
(qv) e +all
é uma abominação.
~all
é a escolha simples; ele informa às pessoas que você listou vários sistemas que estão autorizados a enviar mensagens suas, mas que não está se comprometendo a que essa lista seja exaustiva; portanto, as mensagens do seu domínio provenientes de outros sistemas ainda podem ser legais. Peço que você não faça isso. Não apenas torna o SPF completamente inútil, mas alguns administradores de email do SF configuram deliberadamente seus receptores SPF para serem tratados ~all
como o emblema de um remetente de spam. Se você não vai fazer -all
, não se preocupe com o SPF .
-all
é a escolha útil; ele informa às pessoas que você listou os sistemas que têm permissão para enviar e-mails e que nenhum outro sistema está autorizado a fazê-lo; portanto, eles podem rejeitar e-mails de sistemas não listados no seu registro SPF. Esse é o objetivo do SPF, mas você deve ter certeza de que listou todos os hosts autorizados a originar ou retransmitir mensagens antes de ativá-las .
O Google é conhecido por aconselhar que
A publicação de um registro SPF que usa -all em vez de ~ all pode resultar em problemas de entrega.
bem, sim, pode; esse é o objetivo do SPF . Não sabemos ao certo por que o Google dá esse conselho, mas suspeito fortemente que isso evite administradores de sistemas que não sabem exatamente de onde o email se origina causem problemas de entrega. Se você não souber de onde vêm todos os seus emails, não use o SPF . Se você for usar o SPF, liste todos os lugares de onde vem e diga ao mundo com o qual você está confiante nessa lista -all
.
Observe que nada disso é obrigatório no servidor de um destinatário; o fato de você anunciar um registro SPF de maneira alguma obriga alguém a honrá-lo. Cabe aos administradores de qualquer servidor de email que email eles escolhem aceitar ou rejeitar. O que eu acho que o SPF faz é permitir que você se exime de qualquer responsabilidade adicional por e-mail que alegou ser do seu domínio, mas não era. Qualquer administrador de e-mail que esteja reclamando que seu domínio está enviando spam a eles quando não se preocupou em verificar o registro SPF que você anuncia que teria dito a eles que o e-mail deveria ser rejeitado pode ser enviado com uma pulga no ouvido.
Como essa resposta foi canônica, é melhor dizer algumas palavras sobre include
e redirect
. O último é mais simples; se o seu registro SPF, digamos example.com
, diz redirect=example.org
, então example.org
, o registro SPF substitui o seu. example.org
também é substituído pelo seu domínio nessas pesquisas (por exemplo, se example.org
o registro incluir o mx
mecanismo, a MX
pesquisa deverá ser feita example.org
, e não no seu próprio domínio).
include
é amplamente mal compreendido e, como observam os autores do padrão " o nome 'incluir' foi mal escolhido ". Se o seu SPF registro include
s example.org
'record s, em seguida, example.org
' s registro deve ser examinado por um destinatário para ver se ele dá qualquer motivo (incluindo +all
) a aceitar o seu e-mail . Se isso acontecer, seu e-mail deve passar. Caso contrário, o destinatário deve continuar processando seu registro SPF até pousar no seu all
mecanismo. Portanto, -all
ou mesmo qualquer outro uso de , all
exceto +all
em um include
registro d, não afeta o resultado do processamento.
Para obter mais informações sobre registros SPF, http://www.openspf.org é um excelente recurso.
Por favor, não tome isso da maneira errada, mas se você errar um registro SPF, poderá impedir que uma fração significativa da Internet receba e-mails seus até corrigi-los. Suas perguntas sugerem que você pode não estar completamente satisfeito com o que está fazendo e, se for esse o caso, considere obter assistência profissional antes de fazer algo que o impeça de enviar e-mails para muitas pessoas.
Edit : obrigado por suas amáveis palavras, elas são muito apreciadas.
O SPF é primariamente uma técnica para evitar o joe-jobbing , mas algumas pessoas parecem ter começado a usá-lo para tentar detectar spam. Algumas delas podem de fato atribuir um valor negativo ao fato de você não ter nenhum registro SPF ou um registro de overbroad (por exemplo a:3.4.5.6/2 a:77.5.6.7/2 a:133.56.67.78/2 a:203.54.32.1/2
, o que equivale sorrateiramente a isso +all
), mas isso depende deles e não há muito o que fazer.
Pessoalmente, acho que o SPF é uma coisa boa, e você deve anunciar um registro se sua estrutura de correio atual permitir, mas é muito difícil fornecer uma resposta autorizada, válida para toda a Internet, sobre como as pessoas estão usando um registro DNS projetado para um finalidade específica, quando decidirem usá-la para uma finalidade diferente. Tudo o que posso dizer com certeza é que se você fazer propaganda de um registro SPF com uma política de -all
, e você errar, muitas pessoas nunca vão ver o seu mail.
Edição 2 : excluída de acordo com os comentários e para manter a resposta atualizada.