Como configurar SPF?

Como configurar SPF?

SPF ou Sender Policy Framework é um método de anunciar que servidor pode enviar email para um domínio específico. Junto a publicação do servidor que é permitido, pode ser anunciado a política de envio, ou seja, sugerir que qualquer mensagem vindo de outro servidor é inválida e eventualmente descartar ou pelo menos marcar como suspeita.

SPF funciona de forma colaborativa entre o sistema de envio e de recebimento, o dono do domínio anuncia que somente o servidor X é permitido como origem e o dono do domínio destinatário decide como tratar essa informação. Ele pode configurar o sistema para rejeitar, descartar ou marcar a mensagem, ou inclusive ignorar a sugestão.

Muitos provedores de serviço de Internet ainda não usam SPF, uma falha que facilita o transito de mensagens ilícitas, SPAM, inclusive de mensagens com tentativas de invasão ou roubo de senhas. Exemplo fatal, um sujeito monta uma mensagem de email com aparência de um banco, falsifica o endereço remetente, e, no texto pede ao usuário quem recebe repetir a senha de acesso a conta dele. Por serem muito bem feitas essas mensagens, os mais ingênuos estão caindo, no dia seguinte encontram a conta vazio. Com devida proteção no provedor de serviço a mensagem falsa eventualmente não chega na caixa postal do usuário. Veja no texto a seguir como configurar corretamente o SPF para o seu domínio.

Para poder configurar SPF para seu domínio precisa acesso a configuração DNS. O SPF record, ou entrada SPF, é um linha com identificação texto (TXT), ou como SPF. Como a identificação SPF é nova, sugero usar duas entradas iguais, uma como TXT e outra como SPF. O texto deve começar com v=spf1, não existe outra versão (v) no momento. Exemplo básico da sintaxe é:

IN	TXT
IN	SPF	"v=spf1 configs ... política"

A política determinante sempre fica no final da linha e a palavra chave é all, que expressa aplicar essa política a tudo que não consta nas configs anteriores. Define-se a política com os prefixos +,?,~ ou - explicados na seguinte tabela:

+	sugestão para aceitar
?	sem sugestão, neutra
~	sugestão de falha temporária, aceitar mas marcar
-	sugestão de falha, rejeitar ou descartar

Usando então estes prefixos junto com a palavra all no final da linha significa por exemplo:

+all	aceitar tudo que não foi definido em configs antes
~all	marcar tudo que não foi definido em configs antes
-all	rejeitar ou descartar tudo que não foi definido em configs

Para realmente proteger os seus usuários poderia usar SPF no sentido de permitir o servidor que é permitido e no final sugerir a rejeição de todas as outras origens, como no exemplo:

IN	TXT	"v=spf1 permitidos -all"
IN	SPF	"v=spf1 permitidos -all"

Com este método seu servidor de email checa cada mensagem que chega descarta cada mensagem que diz de ser de seu domínio ( ...@seudominio.com.br), porém vindo de outro servidor. O mesmo e desejado é que pode ocorrer em qualquer outro servidor de email no mundo, ou seja, aceita email ...@seudominio.com.br somente quando enviado a partir do seu servidor identificado.

As configurações também são simples e existem as palavras chaves: a,mx,ptr,ip4,ip6,exists,include e redirects explicados a seguir:

a	entrada identificador no DNS
mx	entrada mx (mailtransfer) no DNS
ptr	entrada dns reverso
ip4	IP ou rede em formatação IPv4
ip6	IP ou rede em formatação IPv6
exists	verifica existência do domínio
include	pode ser definido outro domínio adicional
redirects	usar SPF de outro domínio

As primeiras quatro chaves são os mais comuns, especialmente a,mx e ip4 está sendo usado e sem dúvida os mais importantes. As outras definições são mais complexas para situações muito específicos, quem precisar deles precisa estudar os documentos SPF originais para saber se realmente são necessárias.

Os prefixos explicados podem ser usados junto a cada palavra chave, por exemplo +mx permite todos os servidores MX do domínio ou -MX rejeitar, sem prefixo assume-se permissão, portanto não necessário adicionar o prefixo.

Uma entrada SPF fácil, prática e efetiva seria identificar e permitir o servidor MX desse domínio. O servidor deve estar configurado no DNS com identificador MX:

v=spf1 mx -all

orienta aceitar email do ou dos servidores MX e rejeitar mensagens de qualquer outra origem. Caso seu domínio de internet não possui servidor de email própio e está hospedado em servidor de terceiros pode identificar o domínio:

v=spf1 mx:outro_dominio.com.br -all

que orienta aceitar mensagens do seu domínio vindo do servidor MX de outro_dominio.com.br e rejeitar quando de qualquer outro.

Essa política SPF explicado até agora deveria ser suficiente e efetivo para qualquer domínio que tem usuários usando o serviço e oferece uma boa proteção.

Caso o seu domínio define uma série de máquinas e cada uma envia email, tipo servidores WEB pode usar mais ou outra identificação. Por exemplo pode usar a, ptr ou ip4 como neste exemplo:

v=spf1 a -all
v=spf1 a:outro_dominio.com.br -all
v=spf1 ptr -all
v=spf1 ptr:outro_dominio.com.br -all
v=spf1 ip4:200.10.20.30 -all
v=spf1 ip4:200.10.20.0/29 -all

A primeira opção permite recebimento de email de qualquer máquina que possui entrada com identificador A no DNS e rejeitar qualquer outra, ou a:outro_dominio.com.br permite todas as máquinas de outro_dominio.com.br.

Usando a palavra chave ip4 ou ip6 pode definir qualquer IP ou Rede IP como permitido para este domínio, independente da configuração DNS. Essa combinação pode ser interessante para empresas de hospedagem de domínios, para ficar despreocupado com a edição específica de cada DNS, basta manter uma entrada genérica assim em cada domínio.

As palavras chaves podem ser usados combinados, apenas manter a sequencia na sintaxe. Veja alguns exemplos:

v=spf1 a mx ip4:200.10.20.30 -all

Com essa linha permite que todos as máquinas com entrada A no DNS estão permitidos, todas as entradas MX e adicional a máquina 200.10.20.30, mensagens vindo de qualquer outra são ilícitas.

Verifique bem a sua necessidade e sua realidade, o uso de SPF pode ser positivo mas com incorreta configuração pode ou abrir brechas ou impedir o envio de email. Veja no final algumas sugestões típicas:

Provedor de Acesso Internet

v=spf1 mx -all

Permite o servidor de email (MX) e nada mais

Provedor de Acesso Internet com servidores WWW

v=spf1 a:200.10.20.10 mx -all
ou
v=spf1 ip4:200.10.20.o/29 mx -all

Permite o servidor 200.10.20.10 ou a rede 200.10.20.0/29 e o servidor de email (MX) e nada mais

Provedor de Serviços Internet

v=spf1 a mx -all

Permite os servidor com entrada identificador A no DNS, assim como o MX do domínio e nada mais

Dono de um domínio hospedado de um empresa

v=spf1 ip4:200.10.20.30 -all
ou
v=spf1 a:empr_hospedagem.com.br -all
ou
v=spf1 mx:empre_hospedagem.com.br -all

Na primeira linha permite o IP 200.10.20.30, provavelmente o servidor de email da empresa de hospedagem. Na segunda permite todas as máquinas da empresa de hospedagem com entrada A no DNS e na terceira permite somente o servidor de email MX da empresa de hospedagem.

Usando SPF corretamente obtem um ótimo resultado com a sua participação no combate anti-spam e todos os internautas vão agradecer sua força. Caso tiver dúvidas entre em contato, eventualmente conseguimos ajudar.

Fonte: InfoMatik
http://www.matik.com.br/content/view/57/9/

Como configurar DKIM e Domainkeys

Como configurar DKIM e Domainkeys DKIM, conhecido como Domain Keys Identified Mail, em português Mail identificado com Chave de Domínio, é um método de identificar e autenticar a origem de uma mensagem. A implementação, o uso e interpretação é voluntário e depende dos entendimentos do dono do serviço de email, tanto do remetente quanto do destinatário. Importante, para melhor entendimento aqui, quando falamos de remetente ou destinatário NÃO referimos ao usuário mas sim ao SERVIDOR SMTP de envio e recebimento (MTA = Mail Transfer Agent).

Este meconismo é um pouco dificil de configurar porque existem muitas informações na Internet, quais eventualmente estão misturadas (domainkey e DKIM) ou os documentos originais RTF interpretados de forma errada ou baseadas em informações ou documentos antigos.

Fato é que Domainkeys é um mecanismos antigo, é o original desenvolvido pelo Yahoo, DKIM é a evolução mais nova e em constante desenvolvimento. Ocorre que, ainda estão trabalhando na forma de avaliar e usar a chave. Dificulta que poucos provedores de serviço usam esse método e ainda menos colaboram com resultados, experiências e sugestões. Esperamos que este artigo esclarece um pouco o assunto, deixa ele mais claro e ajuda a usar uma correta configuração no Brasil que, no final, ajuda a diminuir a quantidade de SPAM que enche nossas (e as suas!) caixas postais.

Resumo explicativo da operação

1. Básico - Email em transito

Sempre existe um MTA, Mail Transfer Agent, que é o servidor de envio e recebimento de mensagens. É o nome que o usuário configura no seu programa de email como servidor de envio, de praxe algo como smtp.dominio.com.br. Este servidor (máquina) está localizado nas instalações do provedor de acesso.

MTA Origem <----> MTA Destino

O pequeno diagrama de cima demonstra o que ocorre. As mensagens estão sendo enviados de um servidor para o outro, o usuário ou a máquina do dono do email nome@dominio.com.br não tem conexão direto como a caixa postal do destinatário final, por exemplo nome@outro_dominio.com.br

Dessa forma, dependendo de quem envia, qualquer MTA num provedor de acesso pode ser remetente ou destinatário.

2. Problema - Origem verdadeira ou não?

É realmente fácil configurar no programa de email um endereço de remetente qualquer. Outras formas de falsificar a origem existem e com emails falsos o interessado pode obter dados ou simplesmente provocar reações não desejados. O sistema DKIM é destinado a combate anti-spam e anti-fraude. Com o uso do mecanismo DKIM os provedores podem reduzir a qauntidade de SPAM e as tentativas de roubo ou estelionato na Internet.

3. Identificar a Origem

O dono do MTA configura o sistema dele para inserir uma chave encriptada e única em cada mensagem de email autentica que seus usuários enviam através dele. Junto a chave ele publica alguns parametros e a política de identificação o que permite ao servidor de destino verificar a chave e tomar medidas de aceitar ou não essa mensagem.

4. Efeito e Política

Caso as medidas estão corretamente implementadas uma relação de confiança pode ser estabelecida entre o montante de MTAs na Internet, onde de um lado o remetente publica uma política de assinatura rigorosa, ou seja, assina todas as mensagens suas - e - de outro lado o destinatário interpreta rigorosamente essa política e aplica-la, ou seja, rejeita ou descarta qualquer mensagem sem a correta assinatura.

5. Quem pode?

Qualquer pessoa que é detentor (dono) de um domínio internet pode usar essa prática. As vezes precisa a ajuda do provedor de serviços onde o domínio está hospedado.

Requisitos do mecanismo

1. Um domínio Internet devidamente cadastrado no registro.br

2. Um sistema DNS que publica as informações.

3. Um servidor de email (MTA)
4. Um programa de Milter/Filter para inserção e verificação da chave.
5. Opcional um programa anti-spam para classificar as mensagens

Configuração do Sistema MTA

No site DKIM.ORG encontra detalhes e referencias específicos para o seu sistema operacional e programa MTA, assim como implemetar no seu sistema.

Para a maioria de sistemas de envio de email (MTA), os mais comuns Sendmail, Postfix, Qmail e outros, existem boas instruções e how-to que podem assistir perfeitamente na instalação e configuração do Milter. Muitas vezes a configuração padrão insere corretamente as chaves nas mensagens, um empreendimento bastante fácil.

A dificuldade encontramos sempre na correta divulgação das chaves com os devidos parametros e especialmente da política e como configurar o serviço DNS.

Configuração DNS, Publicação DKIM

Para poder publicar uma chave precisa gerar essa. A ferramenta para faze-lo é o comando openssl. Precisamos gerar uma chave RSA encriptada com algoritmo de 1024 bits. Existem documentos na Internet indicando 256 ou 512 bits mas essas chaves, a pesar de poderem estar aceitadas no destinatário, não são corretas. O comando é assim:

openssl genrsa -out rsa.private 1024

Gravamos assim a chave num arquivo rsa.private para ser usada depois. Caso quer usar ou ver na tela execute o comando sem ou abre o arquivo.

A chave privada deve estar num lugar seguro no servidor MTA. Crie um diretório, por exemplo /etc/mail/dkim. Limite o acesso a este diretório com
chown root:milter_user_group
e depois com
chmod -R 640
milter_user_group seria o grupo do usuário (GUID) que roda o dkim-milter.

Essa chave privativa está sendo usada pelo programa dkim-milter para gerar a chave de assinatura. A chave privativa nunca está sendo publicada e deve ser mantido em segredo.

Anunciamos com o serviço DNS a chave pública (RSA Pulic Key) e essa geramos da seguinte forma:

openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

Gravamos assim outro arquivo que contém a chave pública, rsa.public, e essa pode ser divulgada sem problema alguma or ser destinado exatamente ara essa finalidade.

No programa dkim-milter indicamos na configuraçao qual arquivo usar, seguindo neste exemplo, o caminho /etc/mail/dkim/rsa.private como path para a chave privativa. Veja no manual desse programa como fazer

A chave pública, no arquivo rsa.public, tem um contedo semelhante a:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwSNEaXsdi
SpUAqbuMskkYHYDGrQAMzIVxWOPLvkKWS8Dx6qCkUvY/sHD5
kctG1uNks5ui7shOoNFjrmILlfZ+u9lnhwPY9EksEiGPhVPj
Cv2zJggBQG7fdPI/kZykV35kgnn2Dm0TodNFbItV/hVQ3bX4
kSneD8kJ5YVWLZlVewIDAQAB
-----END PUBLIC KEY-----

onde a chave é entre as linhas que começam com ----

Essa chave usamos no DNS. Procure não confundir as duas, somente a chave rsa.public funciona e somente essa deve ser usada.

A entrada no seu DNS tem a seguinte sintaxe:
nome._domainkey IN TXT "p=rsa.public;"

E é aqui onde começa a confusão com diversas informações que você encontra na Internet.

Observação: As informações a seguir são corretas e baseiam-se no nosso entendimento e data base de Setembro de 2009. Depende o funcionamento ainda na correta configuração do seu programa dkim-milter e a correta interpretação no destino. Mesmo que não podemos assumir garantia, confirmamos que a configuração a seguir funciona. Em caso de dúvida consulte-nos.

nome é um nome, pode definir livremente o que quiser. Serve apenas para diferenciar caso usa chaves diferentes.
_domainkey é uma palavra chave e deve ser usada exatamente como tal.
IN TXT define a entrada e definição da linha no arquivo DNS do domínio. Deve constar exatamente como tal.
"p=rsa.public;" é o texto a ser publicado. Deve começar com aspas e no fechar com aspas e contém a chave pública que geramos antes. Não deve ser o nome do arquivo, deve conter a chave, começando com p= assim:

p=MIGfMA0GCSqGSIb3DQEBAQUA...5YVWLZlVewIDAQAB;

e observe que termina com ; antes de fechar as aspas. Observe também que deve ser UMA ÚNICA linha e não pode ter quebra de linha na chave. Caso queira usar mais de uma linha consulte o manual do seu servidor DNS para faze-lo corretamente.

A confusão que falei em cima ocorre devido a instruções incorretas de usar outros parâmetros entre as aspas. É confuso, mesmo para administradores experientes, porque existem aqui pequenas diferenças entre DK e DKIM mas o importante é que os parâmetros adicionais estão sendo inseridos pelo seu programa dkim-milter no cabeçalho da mensagem. O sistema DNS serve somente para divulgar a chave pública.

Existem apenas dois parâmetros adicionais que podem ser usados aqui. O parâmetro k= pode ser usado para indicar um algoritmo diferente, quando não usa RSA, enquanto usa RSA que é o padrão atualmente, não precisa inserir. O segundo parâmetro seria t= e a única opção que pode ser usada é t=y e significa que este domínio está testando o sistema, sugerindo assim ao destinatário de tomar nenhuma ação de filtragem rejeição ou descarte. É uma opção válida durante os primeiros dias de uso do sistema para conferir e testar mesmo. A entrada completa de exemplo poderia ser assim:

nome._domainkey IN TXT "t=y; p=MIGfMA0GCSqG...;"

Configurado assim, seu servidor DNS divulga corretamente a chave para outros MTAs poderem consulta-la.

Dentro das configurações do seu programa dkim-milter deve definir o nome, chama-se SELECTOR (selecionador) e é necessário. Este nome pode ser qualquer, por exemplo dkim ou nome do seu cachorrinho, tanto faz, apenas deve existir e deve ter um ponto assim nome._domainkey. Lembre, _domainkey é uma palavra chave e deve ser escrita exatamente assim.

Lembre! Não oriente-se e não use qualquer outra opção nessa linha do DNS sob o perigo que a consulta feita por outro MTA falha ou produz resultados incorretos ou não desejados.

Opcional
Caso quer usar DK e DKIM junto, que é válido, publique a mesma linha duas vezes. Use apenas u, SELECTOR (nome) diferente. Mais tarde verá o porque, use por exemplo dk._domainkey .... e dkim._domainkey ....

Agora temos um programa, por exemplo dkim-milter que faz a inserção na mensagem de email e o sistema DNS que publica a nossa chave para consulta. Com estes dados o sistema remoto, aquele que recebe uma mensagem desse domínio e pode marcar ela como suspeita caso a chave está incorreta, não coincide com a publicação pelo DNS ou falta. Fica depois por critério do destinatário, o usuário final, o que fazer com essa mensagem.

Essa política requer que o usuário abre o código fonte de mensagem ou visualiza todos os cabeçalhos dela, portanto um pouco fora da realidade. Por isso divulgamos ainda a nossa política de identificação.

As informações na Internet novamente são confusas ou incompletas. Existem aparentemente três políticas a serem aplicadas. Princípio delas é indicar como ocorre a assinatura dos emails e uma sugestão como proceder no destino com essas mensagens. Definem-se as seguintes opções:

Em SSP e ADSP

< >

A. unknown - o domínio eventualmente assina ou não a sua mensagens.
B. all - o domínio assina todas as mensagens, mas deixa por conta do MTA destinatário como proceder.
C. discardable - o domínio assina todas as mensagens e orienta o MTA destinatário para descartar ou rejeitar todas sem ou com incorreta assinatura.

Os nomes das políticas SSP e ADSP aparentemente definem o mesmo, tanto que possuem as mesmas opções, mas SSP é relacionado ao sistema DK e ADSP ao sistema DKIM. São porém palavras chaves e devem ser usadas exatamente assim, _ssp ou _adsp como prefixo para _domainkey. A configuração dessas políticas no DNS deve ser feito assim:

_ssp._domainkey IN TXT "dkim=all"
e ou
_adsp._domainkey IN TXT "dkim=discardable"

Já sabemos da confusão e como são definições únicas sugiro o uso das duas com a mesma política, all ou discardable, mesmo que usa somente DK ou só DKIM. Não causa dano nenhum e não provoca consultas com erro.

Em política geral

o=~ mensagens desse domínio podem aparecer sem assinatura
o=- todas as mensagens desse domínio estão sendo assinadas
t=y política em teste
n=texto um comentário onde texto pode ser uma página na internet fornecendo informações sobre a prática em uso
r=email um endereço de email aonde enviar relatórios de erro caso houver

Estes parâmetros pode ser divulgados numa linha de política de assinatura geral que define-se somente com a palavra _domainkey numa linha DNS, sintaxe é:

_domainkey IN TXT "o=-; t=y; r= chefe@dominio.com.br;"

Bom, agora já tratamos de todo, espero que ficou compreensível. Quem tiver dúvidas pode entrar em contato e quem sabe se consigo ajudar. Veja no final mais um exemplo completo de como ficariam as linhas no DNS:

_ssp._domainkey IN TXT "dkim=discardable"
_adsp._domainkey IN TXT "dkim=discardable"
_domainkey IN TXT "o=-; t=y; r= chefe@dominio.com.br;"
dk._domainkey IN TXT "t=y; p=MIGfMA0GCSq...ewIDAQAB;"
dkim._domainkey IN TXT "t=y; p=MIGfMA0GCSq...ewIDAQAB;"


Uma vez concluídos os seus testes pode remover os parâmetros t=y; para que as suas configurações realmente conseguem sucesso. Não esqueça adaptar também no seu programa dkim-milter que aceita as políticas SSP e ADSP sugeridas.

Finalmente acrescento o seguinte, não fiquem com t=y ou com políticas moles. De certa forma então não valeu a pena de fazer todo este trabalho. Implementam o sistema, testem ele e sejam rigorosos. Só assim podemos ganhar o combate anti-spam e aos poucos acabar com a quantidade de fraudes. Lembrem desse detalhe. existe uma proposta de lei que quer responsabilizar o provedor de acesso internet onde o invasor estava conectado quando invadiu a conta de alguém. Para não pagar o prejuízo seja firma e não atende os pedidos dos spammers (sejam eles caseiros o sujeitos mesmos), feche o seu sistema e use o que tiver para proteger o seu investimento e as caixas postais do usuários honestos.

Caso gostaria ajudar na divulgação dessa práticas, linke este artigo no seu website, no seu blog ou onde quiser. Pegue o endereço completo no seu navegador.

Fonte:  InfoMatik
http://www.matik.com.br/content/view/59/9/

Links Uteis:
http://www.espcoalition.org/senderid/

DKIM Wizard
http://www.port25.com/support/domainkeysdkim-wizard/

DKIM Wizard:
Create DKIM records for your domain: http://www.port25.com/support/support_dkwz.php

Como funciona SPF, Domainkey e DKIM

Como funciona SPF, Domainkey e DKIM Email ilícito, o famoso Spam, afeta qualquer internauta e não só o provedor de serviço. Muitas pessoas encontram suas caixas postais lotadas com mensagens estranhas. Existem métodos anti-spam, quais bem aplicadas, podem melhorar a situação. Um simples bloqueio de origem não serve porque é muito fácil falsificar essa. Exigem-se métodos mais inteligentes onde entram programas anti-spam, um dos mais famosos é o spamassassin, e práticas como uso de SPF (Sender Policy Framework), Domainkey e DKIM (Domainkeys Identified Mail). Segue um breve resumo como funciona.

Os três métodos identificam a origem do email, não o remetente, mas o servidor de origem, de envio de email.

SPF
O provedor de serviço de email informa mediante o sistema SPF quais os servidores autorizados para enviar email. A publicação ocorre através do serviço DNS do domínio Internet em questão. Usuário remetente@email.com.br envia uma mensagem para destinatário@bmail.com. Quando essa mensagem chega no servidor de destino, por exemplo no smtp.bmail.com, este servidor sabe que a mensagem veio de smtp.email.com.br, consulta então o DNS pela entrada SPF para saber se smtp.email.com.br realmente é autorizado a enviar mensagens desse domínio. Caso positivo entrega a mensagem na caixa posta do destinatário, caso negativo pode agir diferente, até rejeitar ou descartar a mensagem dependendo da política de ação dele e do remetente.

Domainkey
Já um sistema um pouco mais sofisticado, porque o servidor de origem adiciona uma chave encriptada em cada mensagem, a chave do domínio (Domainkey). Quando chega essa mensagem no servidor de destino com esta chave, ele consulto o serviço DNS do domínio e confere a chave. Caso bate entrega a mensagem na caixa postal do usuário, caso não bate pode marcar a mensagem com origem suspeita, rejeitar ou descartar dependendo da sua política de segurança.

DKIM
É uma evolução do Domainkey. Funciona semelhante ao sistema Domainkey, mas DKIM permite ao dono do domínio publicar uma política e sugerir ao servidor de destino uma política de ação. Dessa forma o remetente pode declarar uma política rigorosa, sugerindo o descarte de todas as mensagens sem devida autenticação.

Veja os artigos técnicos Como configurar SPF, Como configurar DKIM e Domainkey ou Como configurar SenderID sobre como implementar estes sistemas. São métodos válidos e podem ser usados juntos, combinados para melhorar a segurança e reduzir a quantidade de SPAM na Internet.

Infelizmente a maioria dos provedores não estão preocupados com o envio e somente com o recebimento, portanto estes métodos estão pouco usados, ou somente combinados com políticas suaves. Até o próprio Yahoo que é o dono inventor do sistema Domainkey publica apenas uma política em teste, a mais mole que existe.

Os usuários de email ou donos de pequenos domínios poderiam exigir de seus provedores estes métodos que as vezes não combinam muito bem com os interesses comerciais.

Cada um, o provedor de serviços até o Internauta, fazendo sua parte a Internet poderia ficar bem mais seguro. Seguro no sentido que ficaria muito mais difícil de falsificar emails e ia acabar com as mensagens de tentativa, aquelas que fingem ser de bancos querendo as senhas dos usuários. Muitas vezes não existe muito interesse por parte do provedor e ela precisa de uma pequena cobrança por parte do usuário final.

Como saber se meu provedor usa?
Cada programa de e-mail, inclusive os Webmails, possuem em algum lugar uma opção tipo Código Fonte da mensagem, Message Source, Cabeçalhos completos, é só procurar e clicar. Observe os cabeçalhos e encontra cada detalhe da mensagem em transito e referencias de SPF, Domainkey ou DKIM quando houver. Caso não encontra fale com o seu provedor para saber se ele usa essas ferramentas.

Fonte: InfoMatik
http://www.matik.com.br/content/view/56/25/





 ----------------------------------------------------------------------------------------------------------

Site Uteis:
Teste de SPF:
http://www.kitterman.com/spf/validate.html
http://www.port25.com/support/domainkeysdkim-wizard/
http://www.openspf.org/SPF_Record_Syntax
http://landingbr.returnpath.com/eBook-50-maneiras-de-aumentar-sua-lista
http://landingbr.returnpath.com/ebook-metricas-de-reputacao-de-email-download-ty
http://landingbr.returnpath.com/ebook-metricas-de-reputacao-de-email
http://domainkeys.sourceforge.net/policycheck.html

Configurando:
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

Teste DomainKeys:
http://www.appmaildev.com/br/domainkeys/
http://domainkeys.sourceforge.net/policycheck.html
http://www.emailarchitect.net/domainkeys/doc/html/object_test.htm



E-Book:
http://landingbr.returnpath.com/ebook-metricas-de-reputacao-de-email

Cheque se seu IP de Envio é confiável:
https://www.senderscore.org/