Autenticação SPF: Uma Visão Geral e Melhores Práticas
Pássaro
19 de dez. de 2016
1 min read
Principais Conclusões
SPF (Sender Policy Framework) é um protocolo de autenticação de e-mail baseado em caminho que verifica se o servidor de envio está autorizado a enviar e-mails em nome de um domínio.
As políticas SPF vivem como registros TXT DNS, formatadas com mecanismos que definem quais servidores, IPs ou redes estão autorizados a enviar em nome de um domínio.
A validação SPF está relacionada ao domínio Return-Path (domínio de retorno) ou ao nome do host HELO—não ao endereço From visível.
Como o SPF verifica o caminho de envio apenas, ele pode ser validado no início da transação SMTP, tornando-o útil para rejeitar rapidamente e-mails não autorizados.
O SPF é eficaz, mas não perfeito—é suscetível a falsos negativos, especialmente com encaminhamentos de e-mail e listas de distribuição.
Os registros SPF dependem de mecanismos como
mx,a,ipv4,ipv6,include,redirect,exists, e devem terminar com um modificadorall(-all,~all,?all,+all).Limites de consulta DNS se aplicam: a avaliação SPF não pode exceder 10 consultas DNS, tornando o planejamento de registros importante.
O mecanismo
ptragora é considerado “não usar”, mas os validadores ainda precisam aceitá-lo. Alguns remetentes ainda o utilizam devido a lacunas de compatibilidade.O SPF sozinho não garante que um e-mail seja legítimo—apenas que foi enviado de um servidor autorizado. Ele funciona melhor quando combinado com DKIM, DMARC e outras técnicas antifraude.
Destaques de Perguntas e Respostas
O que é SPF em termos simples?
SPF permite que um domínio declare quais servidores estão autorizados a enviar e-mails em seu nome. Servidores que recebem verificam isso para detectar remetentes não autorizados.
Por que o SPF é chamado de "baseado em caminho"?
Porque o SPF valida o caminho que a mensagem percorreu—especificamente, o IP do servidor de envio—em vez de qualquer coisa no conteúdo da mensagem.
Onde é armazenada uma política SPF?
A: Como um registro TXT de DNS, começando com
v=spf1, seguido de mecanismos que definem os remetentes permitidos.Qual domínio o SPF valida?
O Return-Path (também chamado de domínio de retorno).
Se o Return-Path estiver vazio (remetente NULL), o SPF verifica o domínio HELO em vez disso.
O SPF pode ser verificado no início da transação SMTP?
Sim. Porque depende apenas do IP e domínio do servidor de envio, o SPF pode ser validado antes de receber o corpo da mensagem—tornando-o eficiente para filtragem.
Por que o SPF às vezes falha mesmo para e-mails legítimos?
Causas comuns incluem:
Encaminhamento de e-mail (o encaminhador não está no registro SPF do domínio original)
Listas de distribuição (as mensagens são reenviadas por um servidor diferente)
Isso leva a falsos negativos, que são inerentes à autenticação baseada em caminho.
Qual é o papel de mecanismos como incluir, redirecionar e existir?
include— autorizar o registro SPF de outro domínio (por exemplo, seu ESP)redirect— reutilizar a política SPF de outro domínioexists— autorizar dinamicamente com base em uma consulta DNS (útil para infraestrutura complexa)
Como funcionam os modificadores "todos"?
-all→ rejeitar qualquer coisa que não esteja listada (estrito)~all→ falha suave (aceitar mas marcar)?all→ neutro+all→ permitir tudo (desativa efetivamente o SPF)
Por que o mecanismo ptr é desencorajado?
É lento, não confiável e obsoleto na especificação moderna—mas os validadores SPF ainda devem suportá-lo.
O SPF é suficiente por si só para autenticação de e-mail?
Não. O SPF verifica a infraestrutura de envio, mas:
Não protege a integridade da mensagem
Não se alinha com os domínios visíveis do remetente
Quebra com o encaminhamento
O SPF é mais forte quando combinado com DKIM e DMARC.
Antes de mergulhar na implementação técnica, vale a pena entender a evolução e a variedade de técnicas de validação de e-mail disponíveis. Desde a verificação de sintaxe simples até abordagens modernas baseadas em dados, diferentes métodos de validação oferecem níveis variados de precisão e confiabilidade.
Quando falamos de “Autenticação de E-mail”, estamos nos referindo a uma técnica que tem como objetivo fornecer ao destinatário de uma mensagem algum nível de certeza de que a mensagem realmente se originou na fonte reivindicada. A ideia é alcançar algum nível de defesa contra e-mails fraudulentos, como phishing e spoofing, que poderiam erodir a confiança de um destinatário em receber e-mails. Para organizações que exigem criptografia em nível de mensagem além da autenticação, o S/MIME oferece segurança de ponta a ponta, com a coleta automatizada de chaves públicas de destinatários tornando a implementação mais escalável. Dito isso, o ato de enviar e-mails autenticados não afirma, por si só, que o e-mail é bom ou desejado; significa apenas que a mensagem é tal que uma reputação para a parte autenticada pode ser estabelecida de forma confiável e usada nas decisões de aceitação e colocação de e-mails.
Existem duas formas principais de autenticação de e-mail em uso hoje—Sender Policy Framework (SPF) e DomainKeys Identifed Mail (DKIM). Neste post do blog, explicarei o que é SPF e como funciona.
Antes de mergulhar na implementação técnica, vale a pena entender a evolução e a variedade de técnicas de validação de e-mail disponíveis. Desde a verificação de sintaxe simples até abordagens modernas baseadas em dados, diferentes métodos de validação oferecem níveis variados de precisão e confiabilidade.
Quando falamos de “Autenticação de E-mail”, estamos nos referindo a uma técnica que tem como objetivo fornecer ao destinatário de uma mensagem algum nível de certeza de que a mensagem realmente se originou na fonte reivindicada. A ideia é alcançar algum nível de defesa contra e-mails fraudulentos, como phishing e spoofing, que poderiam erodir a confiança de um destinatário em receber e-mails. Para organizações que exigem criptografia em nível de mensagem além da autenticação, o S/MIME oferece segurança de ponta a ponta, com a coleta automatizada de chaves públicas de destinatários tornando a implementação mais escalável. Dito isso, o ato de enviar e-mails autenticados não afirma, por si só, que o e-mail é bom ou desejado; significa apenas que a mensagem é tal que uma reputação para a parte autenticada pode ser estabelecida de forma confiável e usada nas decisões de aceitação e colocação de e-mails.
Existem duas formas principais de autenticação de e-mail em uso hoje—Sender Policy Framework (SPF) e DomainKeys Identifed Mail (DKIM). Neste post do blog, explicarei o que é SPF e como funciona.
Antes de mergulhar na implementação técnica, vale a pena entender a evolução e a variedade de técnicas de validação de e-mail disponíveis. Desde a verificação de sintaxe simples até abordagens modernas baseadas em dados, diferentes métodos de validação oferecem níveis variados de precisão e confiabilidade.
Quando falamos de “Autenticação de E-mail”, estamos nos referindo a uma técnica que tem como objetivo fornecer ao destinatário de uma mensagem algum nível de certeza de que a mensagem realmente se originou na fonte reivindicada. A ideia é alcançar algum nível de defesa contra e-mails fraudulentos, como phishing e spoofing, que poderiam erodir a confiança de um destinatário em receber e-mails. Para organizações que exigem criptografia em nível de mensagem além da autenticação, o S/MIME oferece segurança de ponta a ponta, com a coleta automatizada de chaves públicas de destinatários tornando a implementação mais escalável. Dito isso, o ato de enviar e-mails autenticados não afirma, por si só, que o e-mail é bom ou desejado; significa apenas que a mensagem é tal que uma reputação para a parte autenticada pode ser estabelecida de forma confiável e usada nas decisões de aceitação e colocação de e-mails.
Existem duas formas principais de autenticação de e-mail em uso hoje—Sender Policy Framework (SPF) e DomainKeys Identifed Mail (DKIM). Neste post do blog, explicarei o que é SPF e como funciona.
O FPS Não É À Prova de Falhas
Embora pareça um modo relativamente simples de autenticar e-mail, o SPF é vulnerável a falhas na forma de falsos negativos. Essas falhas podem ocorrer com mais frequência do que muitos estão confortáveis.
Aqui estão dois cenários comuns onde e-mails perfeitamente legítimos podem falhar na validação SPF e, assim, parecer fraudulentos:
Encaminhamento automatizado, onde uma mensagem enviada para jsmith@alumni.university.edu, uma caixa de correio configurada para encaminhar automaticamente todos os e-mails para jsmith@isp.com
Listas de discussão, onde os e-mails enviados para talk-about-stuff@listserv.foo.com são “explodidos” e enviados para cada assinante
Em ambos os casos, se o Return-Path não for alterado de sua forma original, o e-mail pode falhar nas verificações SPF (dependendo do modificador usado com o mecanismo ‘all’). Isso acontece porque chega ao seu destino final de um servidor intermediário, não do original, e esse servidor intermediário provavelmente não estará no registro SPF do domínio. Uma técnica chamada “Sender Rewriting Scheme” ou “SRS” pode mitigar esse risco, e alguns sites maiores a adotaram, mas não é universal.
Embora pareça um modo relativamente simples de autenticar e-mail, o SPF é vulnerável a falhas na forma de falsos negativos. Essas falhas podem ocorrer com mais frequência do que muitos estão confortáveis.
Aqui estão dois cenários comuns onde e-mails perfeitamente legítimos podem falhar na validação SPF e, assim, parecer fraudulentos:
Encaminhamento automatizado, onde uma mensagem enviada para jsmith@alumni.university.edu, uma caixa de correio configurada para encaminhar automaticamente todos os e-mails para jsmith@isp.com
Listas de discussão, onde os e-mails enviados para talk-about-stuff@listserv.foo.com são “explodidos” e enviados para cada assinante
Em ambos os casos, se o Return-Path não for alterado de sua forma original, o e-mail pode falhar nas verificações SPF (dependendo do modificador usado com o mecanismo ‘all’). Isso acontece porque chega ao seu destino final de um servidor intermediário, não do original, e esse servidor intermediário provavelmente não estará no registro SPF do domínio. Uma técnica chamada “Sender Rewriting Scheme” ou “SRS” pode mitigar esse risco, e alguns sites maiores a adotaram, mas não é universal.
Embora pareça um modo relativamente simples de autenticar e-mail, o SPF é vulnerável a falhas na forma de falsos negativos. Essas falhas podem ocorrer com mais frequência do que muitos estão confortáveis.
Aqui estão dois cenários comuns onde e-mails perfeitamente legítimos podem falhar na validação SPF e, assim, parecer fraudulentos:
Encaminhamento automatizado, onde uma mensagem enviada para jsmith@alumni.university.edu, uma caixa de correio configurada para encaminhar automaticamente todos os e-mails para jsmith@isp.com
Listas de discussão, onde os e-mails enviados para talk-about-stuff@listserv.foo.com são “explodidos” e enviados para cada assinante
Em ambos os casos, se o Return-Path não for alterado de sua forma original, o e-mail pode falhar nas verificações SPF (dependendo do modificador usado com o mecanismo ‘all’). Isso acontece porque chega ao seu destino final de um servidor intermediário, não do original, e esse servidor intermediário provavelmente não estará no registro SPF do domínio. Uma técnica chamada “Sender Rewriting Scheme” ou “SRS” pode mitigar esse risco, e alguns sites maiores a adotaram, mas não é universal.
Visão Geral do FPS
O Sender Policy Framework (SPF), para parafrasear RFC 7208, é um protocolo que não apenas permite que uma organização autorize hosts e redes a usarem seus nomes de domínio ao enviar e-mails, mas também fornece uma maneira para que um host receptor possa verificar essa autorização.
Quando você terminar de ler este post, espero que você tenha aprendido o seguinte:
SPF é um sistema de autenticação “baseado em caminho”.
As políticas de SPF são declaradas em registros DNS TXT.
A validação é referenciada ao domínio Return-Path (o que aqui na SparkPost chamamos de “domínio de retorno”) ou ao domínio HELO.
A validação pode ser feita no início da transação SMTP, portanto, é uma boa verificação a ser usada para rejeitar rapidamente e-mails não autenticados.
É propenso a uma porcentagem relativamente alta de falsos negativos.
O Sender Policy Framework (SPF), para parafrasear RFC 7208, é um protocolo que não apenas permite que uma organização autorize hosts e redes a usarem seus nomes de domínio ao enviar e-mails, mas também fornece uma maneira para que um host receptor possa verificar essa autorização.
Quando você terminar de ler este post, espero que você tenha aprendido o seguinte:
SPF é um sistema de autenticação “baseado em caminho”.
As políticas de SPF são declaradas em registros DNS TXT.
A validação é referenciada ao domínio Return-Path (o que aqui na SparkPost chamamos de “domínio de retorno”) ou ao domínio HELO.
A validação pode ser feita no início da transação SMTP, portanto, é uma boa verificação a ser usada para rejeitar rapidamente e-mails não autenticados.
É propenso a uma porcentagem relativamente alta de falsos negativos.
O Sender Policy Framework (SPF), para parafrasear RFC 7208, é um protocolo que não apenas permite que uma organização autorize hosts e redes a usarem seus nomes de domínio ao enviar e-mails, mas também fornece uma maneira para que um host receptor possa verificar essa autorização.
Quando você terminar de ler este post, espero que você tenha aprendido o seguinte:
SPF é um sistema de autenticação “baseado em caminho”.
As políticas de SPF são declaradas em registros DNS TXT.
A validação é referenciada ao domínio Return-Path (o que aqui na SparkPost chamamos de “domínio de retorno”) ou ao domínio HELO.
A validação pode ser feita no início da transação SMTP, portanto, é uma boa verificação a ser usada para rejeitar rapidamente e-mails não autenticados.
É propenso a uma porcentagem relativamente alta de falsos negativos.
Autenticação Baseada em Caminho
SPF é considerado um sistema de autenticação baseado em caminho porque está atrelado exclusivamente ao caminho que a mensagem percorreu para ir de sua origem até seu destino. Quando um servidor de envio inicia uma transação SMTP com um servidor de recebimento, o servidor de recebimento determinará se o servidor de envio está autorizado a enviar essa mensagem com base na política SPF do domínio. É exclusivamente uma decisão baseada em de onde a mensagem está vindo, sem relação alguma com o conteúdo da mensagem.
SPF é considerado um sistema de autenticação baseado em caminho porque está atrelado exclusivamente ao caminho que a mensagem percorreu para ir de sua origem até seu destino. Quando um servidor de envio inicia uma transação SMTP com um servidor de recebimento, o servidor de recebimento determinará se o servidor de envio está autorizado a enviar essa mensagem com base na política SPF do domínio. É exclusivamente uma decisão baseada em de onde a mensagem está vindo, sem relação alguma com o conteúdo da mensagem.
SPF é considerado um sistema de autenticação baseado em caminho porque está atrelado exclusivamente ao caminho que a mensagem percorreu para ir de sua origem até seu destino. Quando um servidor de envio inicia uma transação SMTP com um servidor de recebimento, o servidor de recebimento determinará se o servidor de envio está autorizado a enviar essa mensagem com base na política SPF do domínio. É exclusivamente uma decisão baseada em de onde a mensagem está vindo, sem relação alguma com o conteúdo da mensagem.
Declarando uma Política SPF
O registro de política SPF de um domínio é apenas um registro TXT DNS formatado especificamente, contendo comumente um ou mais dos seguintes “mecanismos”:
v=spf1 – Token inicial obrigatório para indicar que o registro TXT é um registro SPF (um domínio pode ter vários registros TXT)
ipv4, ipv6 – Usado para especificar endereços IP e redes que estão autorizados a enviar e-mails para o domínio
a – Se o domínio remetente tiver um registro DNS “A” que resolve para o IP de envio, o IP é permitido
mx – Se o IP de envio também estiver em um dos registros MX para o domínio de envio, o IP é permitido
all – Token final obrigatório, sempre modificado:
-all – Apenas o que está listado aqui pode passar; rejeitar falhas.
~all – O que não está aqui deve ter falha suave; aceitar, mas anotar.
?all – Não tem certeza se o que não está aqui deve passar.
+all – Achamos que SPF é inútil; permitir tudo.
Outros mecanismos menos comuns que ainda estão em uso generalizado são:
include – Usado quando um domínio não só tem seus próprios servidores, mas também usa os servidores de outra pessoa. Deve ser usado com cautela. Cada inclusão é outra consulta DNS, e os registros SPF não podem exigir mais do que dez consultas DNS para resolver.
redirect – Quando o domínio A e o domínio B são de propriedade da mesma entidade e usam a mesma infraestrutura. Os proprietários geralmente desejam manter apenas uma cópia do registro SPF para ambos e configurar B para redirecionar consultas para A.
exists – Se um domínio tiver muitos blocos de rede pequenos e não contíguos, ele pode usar este mecanismo para especificar seu registro SPF, em vez de listar todos eles. Útil para ficar dentro do limite de tamanho (512 bytes) para a resposta DNS.
Uma nota sobre o Mecanismo “ptr”
Um mecanismo final, “ptr” existiu na especificação original para SPF, mas foi declarado “não usar” na especificação atual. O mecanismo ptr foi usado para declarar que se o endereço IP de envio tivesse um registro DNS PTR que resolvesse para o nome de domínio em questão, esse endereço IP estava autorizado a enviar e-mails para o domínio.
O status atual desse mecanismo é que ele não deve ser utilizado. No entanto, os sites que fazem validação SPF devem aceitá-lo como válido.
Mecanismo | O Que Faz | Notas / Orientações de Uso |
|---|---|---|
v=spf1 | Declara que o registro TXT é uma política SPF | Token inicial obrigatório |
ipv4 / ipv6 | Autoriza IPs específicos ou blocos CIDR | Método de autorização mais explícito e confiável |
a | Autoriza IPs que correspondem ao registro A do domínio | Bom para infraestrutura simples |
mx | Autoriza IPs listados nos registros MX do domínio | Útil quando os servidores MX também enviam e-mails |
include | Importar a política SPF de outro domínio | Conta para o limite de 10 consultas DNS; usar com moderação |
redirect | Delegar a política SPF para outro domínio | Usado quando vários domínios compartilham uma definição SPF |
exists | Autoriza via uma regra de pesquisa DNS personalizada | Útil para grandes faixas de IP fragmentadas; o validador deve suportá-lo |
ptr | Autoriza com base no mapeamento DNS reverso | Depreciado (“não usar”), mas ainda deve ser respeitado pelos validadores |
all | Define como tratar tudo que não é explicitamente permitido | Variantes: -all rejeitar, ~all falha suave, ?all neutro, +all permitir todos (não recomendado) |
O registro de política SPF de um domínio é apenas um registro TXT DNS formatado especificamente, contendo comumente um ou mais dos seguintes “mecanismos”:
v=spf1 – Token inicial obrigatório para indicar que o registro TXT é um registro SPF (um domínio pode ter vários registros TXT)
ipv4, ipv6 – Usado para especificar endereços IP e redes que estão autorizados a enviar e-mails para o domínio
a – Se o domínio remetente tiver um registro DNS “A” que resolve para o IP de envio, o IP é permitido
mx – Se o IP de envio também estiver em um dos registros MX para o domínio de envio, o IP é permitido
all – Token final obrigatório, sempre modificado:
-all – Apenas o que está listado aqui pode passar; rejeitar falhas.
~all – O que não está aqui deve ter falha suave; aceitar, mas anotar.
?all – Não tem certeza se o que não está aqui deve passar.
+all – Achamos que SPF é inútil; permitir tudo.
Outros mecanismos menos comuns que ainda estão em uso generalizado são:
include – Usado quando um domínio não só tem seus próprios servidores, mas também usa os servidores de outra pessoa. Deve ser usado com cautela. Cada inclusão é outra consulta DNS, e os registros SPF não podem exigir mais do que dez consultas DNS para resolver.
redirect – Quando o domínio A e o domínio B são de propriedade da mesma entidade e usam a mesma infraestrutura. Os proprietários geralmente desejam manter apenas uma cópia do registro SPF para ambos e configurar B para redirecionar consultas para A.
exists – Se um domínio tiver muitos blocos de rede pequenos e não contíguos, ele pode usar este mecanismo para especificar seu registro SPF, em vez de listar todos eles. Útil para ficar dentro do limite de tamanho (512 bytes) para a resposta DNS.
Uma nota sobre o Mecanismo “ptr”
Um mecanismo final, “ptr” existiu na especificação original para SPF, mas foi declarado “não usar” na especificação atual. O mecanismo ptr foi usado para declarar que se o endereço IP de envio tivesse um registro DNS PTR que resolvesse para o nome de domínio em questão, esse endereço IP estava autorizado a enviar e-mails para o domínio.
O status atual desse mecanismo é que ele não deve ser utilizado. No entanto, os sites que fazem validação SPF devem aceitá-lo como válido.
Mecanismo | O Que Faz | Notas / Orientações de Uso |
|---|---|---|
v=spf1 | Declara que o registro TXT é uma política SPF | Token inicial obrigatório |
ipv4 / ipv6 | Autoriza IPs específicos ou blocos CIDR | Método de autorização mais explícito e confiável |
a | Autoriza IPs que correspondem ao registro A do domínio | Bom para infraestrutura simples |
mx | Autoriza IPs listados nos registros MX do domínio | Útil quando os servidores MX também enviam e-mails |
include | Importar a política SPF de outro domínio | Conta para o limite de 10 consultas DNS; usar com moderação |
redirect | Delegar a política SPF para outro domínio | Usado quando vários domínios compartilham uma definição SPF |
exists | Autoriza via uma regra de pesquisa DNS personalizada | Útil para grandes faixas de IP fragmentadas; o validador deve suportá-lo |
ptr | Autoriza com base no mapeamento DNS reverso | Depreciado (“não usar”), mas ainda deve ser respeitado pelos validadores |
all | Define como tratar tudo que não é explicitamente permitido | Variantes: -all rejeitar, ~all falha suave, ?all neutro, +all permitir todos (não recomendado) |
O registro de política SPF de um domínio é apenas um registro TXT DNS formatado especificamente, contendo comumente um ou mais dos seguintes “mecanismos”:
v=spf1 – Token inicial obrigatório para indicar que o registro TXT é um registro SPF (um domínio pode ter vários registros TXT)
ipv4, ipv6 – Usado para especificar endereços IP e redes que estão autorizados a enviar e-mails para o domínio
a – Se o domínio remetente tiver um registro DNS “A” que resolve para o IP de envio, o IP é permitido
mx – Se o IP de envio também estiver em um dos registros MX para o domínio de envio, o IP é permitido
all – Token final obrigatório, sempre modificado:
-all – Apenas o que está listado aqui pode passar; rejeitar falhas.
~all – O que não está aqui deve ter falha suave; aceitar, mas anotar.
?all – Não tem certeza se o que não está aqui deve passar.
+all – Achamos que SPF é inútil; permitir tudo.
Outros mecanismos menos comuns que ainda estão em uso generalizado são:
include – Usado quando um domínio não só tem seus próprios servidores, mas também usa os servidores de outra pessoa. Deve ser usado com cautela. Cada inclusão é outra consulta DNS, e os registros SPF não podem exigir mais do que dez consultas DNS para resolver.
redirect – Quando o domínio A e o domínio B são de propriedade da mesma entidade e usam a mesma infraestrutura. Os proprietários geralmente desejam manter apenas uma cópia do registro SPF para ambos e configurar B para redirecionar consultas para A.
exists – Se um domínio tiver muitos blocos de rede pequenos e não contíguos, ele pode usar este mecanismo para especificar seu registro SPF, em vez de listar todos eles. Útil para ficar dentro do limite de tamanho (512 bytes) para a resposta DNS.
Uma nota sobre o Mecanismo “ptr”
Um mecanismo final, “ptr” existiu na especificação original para SPF, mas foi declarado “não usar” na especificação atual. O mecanismo ptr foi usado para declarar que se o endereço IP de envio tivesse um registro DNS PTR que resolvesse para o nome de domínio em questão, esse endereço IP estava autorizado a enviar e-mails para o domínio.
O status atual desse mecanismo é que ele não deve ser utilizado. No entanto, os sites que fazem validação SPF devem aceitá-lo como válido.
Mecanismo | O Que Faz | Notas / Orientações de Uso |
|---|---|---|
v=spf1 | Declara que o registro TXT é uma política SPF | Token inicial obrigatório |
ipv4 / ipv6 | Autoriza IPs específicos ou blocos CIDR | Método de autorização mais explícito e confiável |
a | Autoriza IPs que correspondem ao registro A do domínio | Bom para infraestrutura simples |
mx | Autoriza IPs listados nos registros MX do domínio | Útil quando os servidores MX também enviam e-mails |
include | Importar a política SPF de outro domínio | Conta para o limite de 10 consultas DNS; usar com moderação |
redirect | Delegar a política SPF para outro domínio | Usado quando vários domínios compartilham uma definição SPF |
exists | Autoriza via uma regra de pesquisa DNS personalizada | Útil para grandes faixas de IP fragmentadas; o validador deve suportá-lo |
ptr | Autoriza com base no mapeamento DNS reverso | Depreciado (“não usar”), mas ainda deve ser respeitado pelos validadores |
all | Define como tratar tudo que não é explicitamente permitido | Variantes: -all rejeitar, ~all falha suave, ?all neutro, +all permitir todos (não recomendado) |
Alguns Exemplos de Registros SPF
Aqui estão alguns registros de exemplo e seus significados. Este exemplo mostra endereços RFC 1918, mas reconheço que tais endereços nunca aparecerão em registros SPF reais.
Registro MX, um endereço IP, uma rede IP, softfail em todo o resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Registro A, duas redes IP, rejeitar todo o resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Não enviamos nenhum e-mail:
“v=spf1 -all”
Achamos que o SPF é estúpido:
“v=spf1 +all”
O registro SPF para o domínio sparkpostmail.com (mecanismo de redirecionamento utilizado)
“v=spf1 redirect=_spf.sparkpostmail.com”
O registro SPF para _spf.sparkpostmail.com (existe e mecanismos ptr utilizados):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
No SparkPost, atualmente estamos usando o mecanismo ptr em nosso registro SPF. Consideramos necessário devido à falta de suporte universal para validar o mecanismo exists. E até agora, não vimos falhas no SPF decorrentes do uso do mecanismo ptr.
Aqui estão alguns registros de exemplo e seus significados. Este exemplo mostra endereços RFC 1918, mas reconheço que tais endereços nunca aparecerão em registros SPF reais.
Registro MX, um endereço IP, uma rede IP, softfail em todo o resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Registro A, duas redes IP, rejeitar todo o resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Não enviamos nenhum e-mail:
“v=spf1 -all”
Achamos que o SPF é estúpido:
“v=spf1 +all”
O registro SPF para o domínio sparkpostmail.com (mecanismo de redirecionamento utilizado)
“v=spf1 redirect=_spf.sparkpostmail.com”
O registro SPF para _spf.sparkpostmail.com (existe e mecanismos ptr utilizados):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
No SparkPost, atualmente estamos usando o mecanismo ptr em nosso registro SPF. Consideramos necessário devido à falta de suporte universal para validar o mecanismo exists. E até agora, não vimos falhas no SPF decorrentes do uso do mecanismo ptr.
Aqui estão alguns registros de exemplo e seus significados. Este exemplo mostra endereços RFC 1918, mas reconheço que tais endereços nunca aparecerão em registros SPF reais.
Registro MX, um endereço IP, uma rede IP, softfail em todo o resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Registro A, duas redes IP, rejeitar todo o resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Não enviamos nenhum e-mail:
“v=spf1 -all”
Achamos que o SPF é estúpido:
“v=spf1 +all”
O registro SPF para o domínio sparkpostmail.com (mecanismo de redirecionamento utilizado)
“v=spf1 redirect=_spf.sparkpostmail.com”
O registro SPF para _spf.sparkpostmail.com (existe e mecanismos ptr utilizados):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
No SparkPost, atualmente estamos usando o mecanismo ptr em nosso registro SPF. Consideramos necessário devido à falta de suporte universal para validar o mecanismo exists. E até agora, não vimos falhas no SPF decorrentes do uso do mecanismo ptr.
Como Funciona a Autenticação SPF?
Aqui está como uma transação típica de SMTP parece quando o SPF está envolvido:
O servidor de envio (cliente) se conecta ao servidor de recebimento
O servidor de recebimento anota o endereço IP de conexão do cliente
Eles trocam cumprimentos, incluindo o nome do host HELO do cliente
O cliente emite o comando SMTP MAIL FROM
O servidor de recebimento agora pode verificar o registro SPF para o domínio MAIL FROM ou o nome do host HELO para determinar se o IP de conexão está autorizado a enviar e-mails para o domínio e decidir se aceita ou não a mensagem.
Aqui está como uma transação típica de SMTP parece quando o SPF está envolvido:
O servidor de envio (cliente) se conecta ao servidor de recebimento
O servidor de recebimento anota o endereço IP de conexão do cliente
Eles trocam cumprimentos, incluindo o nome do host HELO do cliente
O cliente emite o comando SMTP MAIL FROM
O servidor de recebimento agora pode verificar o registro SPF para o domínio MAIL FROM ou o nome do host HELO para determinar se o IP de conexão está autorizado a enviar e-mails para o domínio e decidir se aceita ou não a mensagem.
Aqui está como uma transação típica de SMTP parece quando o SPF está envolvido:
O servidor de envio (cliente) se conecta ao servidor de recebimento
O servidor de recebimento anota o endereço IP de conexão do cliente
Eles trocam cumprimentos, incluindo o nome do host HELO do cliente
O cliente emite o comando SMTP MAIL FROM
O servidor de recebimento agora pode verificar o registro SPF para o domínio MAIL FROM ou o nome do host HELO para determinar se o IP de conexão está autorizado a enviar e-mails para o domínio e decidir se aceita ou não a mensagem.
MAIL FROM ou HELO – Qual verificar?
A especificação SPF estipula que os sites receptores DEVEM verificar o SPF para o domínio MAIL FROM e RECOMENDA verificar para o nome do host HELO. Na prática, a verificação acontece apenas no domínio MAIL FROM, exceto talvez em ocasiões em que o endereço MAIL FROM é o remetente NULL (ou seja, "<>"), caso em que o nome do host HELO é a única identidade disponível.
A especificação SPF estipula que os sites receptores DEVEM verificar o SPF para o domínio MAIL FROM e RECOMENDA verificar para o nome do host HELO. Na prática, a verificação acontece apenas no domínio MAIL FROM, exceto talvez em ocasiões em que o endereço MAIL FROM é o remetente NULL (ou seja, "<>"), caso em que o nome do host HELO é a única identidade disponível.
A especificação SPF estipula que os sites receptores DEVEM verificar o SPF para o domínio MAIL FROM e RECOMENDA verificar para o nome do host HELO. Na prática, a verificação acontece apenas no domínio MAIL FROM, exceto talvez em ocasiões em que o endereço MAIL FROM é o remetente NULL (ou seja, "<>"), caso em que o nome do host HELO é a única identidade disponível.
