SPF, DKIM e DMARC: o guia completo de autenticação de e-mail

O e-mail foi criado numa época em que ninguém esperava que o endereço do remetente pudesse ser mentira. Nada no protocolo original impede que uma máquina qualquer da internet se conecte a um servidor de e-mail e afirme ser você. É essa falha que faz o phishing funcionar, e é por isso que hoje três padrões baseados em DNS, SPF, DKIM e DMARC, decidem se a sua mensagem chega à caixa de entrada ou à pasta de spam.

Os três vivem nos registros DNS do seu domínio, então você pode inspecionar a configuração de autenticação de qualquer domínio, inclusive o seu, com nada além de uma consulta DNS. Este guia explica o que cada registro faz, como lê-lo e como chegar a uma política DMARC rígida sem bloquear por acidente as suas próprias faturas.

Para verificar os três registros de uma vez, incluindo a contagem de consultas SPF e o tamanho da sua chave DKIM, use nosso verificador de SPF, DKIM e DMARC.

Por que a autenticação de e-mail importa

Duas coisas mudaram nos últimos anos. Os atacantes ficaram muito melhores em imitar marcas confiáveis, e os grandes provedores de caixa postal responderam tornando a autenticação praticamente obrigatória. Gmail e Yahoo já exigem SPF, DKIM e DMARC de quem envia em volume, e a Microsoft seguiu o mesmo caminho. Se os seus registros estiverem ausentes ou quebrados, as consequências são imediatas e bem práticas:

• Suas mensagens são filtradas. Mensagens não autenticadas vão para a quarentena com muito mais frequência e às vezes são rejeitadas antes de chegar a qualquer caixa.
• Qualquer um pode falsificar o seu domínio. Sem uma política DMARC, o servidor que recebe não tem instrução alguma para rejeitar mensagens forjadas com o seu nome.
• Você fica cego para abusos. Os relatórios DMARC são a única forma de descobrir que alguém está enviando phishing em seu nome.
• Negócios travam. Questionários de segurança e avaliações de fornecedores pedem uma política DMARC, e «none» é cada vez mais tratado como uma falha.

Os três registros em resumo

São camadas, não alternativas. O SPF verifica o servidor que envia, o DKIM verifica a mensagem, e o DMARC liga os dois ao domínio que a pessoa realmente vê no cabeçalho From e diz o que fazer quando algo falha. Você precisa dos três.

SPF: quem pode enviar pelo seu domínio

O Sender Policy Framework é uma lista pública dos servidores autorizados a enviar e-mail pelo seu domínio. O servidor que recebe pega o endereço IP que se conectou, consulta o seu registro SPF e verifica se esse endereço está na lista.

Como ler um registro SPF

Um registro típico se parece com isto:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Leia da esquerda para a direita. v=spf1 é a versão e tem de vir primeiro. Cada include: puxa o registro SPF de outro domínio, que é como se autoriza um provedor como o Google Workspace ou um serviço de e-mail transacional. ip4: e ip6: autorizam endereços ou faixas específicas, em geral o seu próprio servidor. O último mecanismo é o curinga, e é o que mais gente erra:

• -all é falha rígida. Tudo o que não está listado não está autorizado, e espera-se que o destinatário rejeite.
• ~all é falha suave. Remetentes não listados são suspeitos, mas aceitos, normalmente com penalidade de spam.
• ?all é neutro e não diz nada ao destinatário, o que anula o sentido de publicar o registro.

Comece com ~all enquanto confirma que todos os remetentes legítimos estão listados e aperte para -all quando os seus relatórios DMARC estiverem limpos.

O limite de dez consultas

O SPF permite no máximo dez consultas DNS ao avaliar um registro. Cada include:, a, mx e redirect conta, inclusive os aninhados. Passar do limite resulta em erro permanente, que a maioria dos destinatários trata como ausência total de SPF. Três ou quatro provedores de e-mail já costumam estourar o limite, então audite o registro sempre que adicionar um serviço de envio e remova provedores que deixou de usar.

Há outra regra que surpreende: um domínio pode publicar apenas um registro SPF. Dois registros TXT com v=spf1 no mesmo nome são erro permanente, não uma fusão.

DKIM: assinar as suas mensagens

O DomainKeys Identified Mail acrescenta uma assinatura criptográfica a cada mensagem que sai. O seu servidor guarda uma chave privada e assina determinados cabeçalhos mais o corpo; a chave pública correspondente é publicada no DNS. O destinatário busca a chave pública, verifica a assinatura e aprende duas coisas: a mensagem realmente foi assinada pelo seu domínio e nada do que ela cobria foi modificado no caminho.

A chave pública fica num nome construído a partir de um seletor, por exemplo google._domainkey.example.com ou s1._domainkey.example.com. Os seletores existem para que você possa manter várias chaves ao mesmo tempo, e é isso que torna a rotação indolor: publique um seletor novo, mude a assinatura para ele e aposente o antigo mais tarde.

Como a assinatura viaja com a mensagem, o DKIM sobrevive a encaminhamentos nos quais o SPF falha. Se uma lista de discussão repassa a sua mensagem, o IP que conecta muda e o SPF falha, mas a assinatura DKIM continua válida desde que a lista não reescreva os cabeçalhos assinados nem o corpo. Essa resistência é o principal motivo pelo qual o DKIM importa mesmo quando o SPF já existe.

DMARC: dizer ao destinatário o que fazer

SPF e DKIM produzem cada um um «passou» ou um «falhou», mas nenhum diz o que o destinatário deve fazer, e nenhum olha o endereço From que a pessoa realmente lê. O DMARC preenche as duas lacunas. Um registro se parece com isto:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p= é a política: none (apenas monitorar), quarantine (tratar falhas como spam) ou reject (recusar na porta). rua= é o endereço que recebe os relatórios agregados diários, e é a parte mais valiosa do registro. pct= permite aplicar a política a uma porcentagem das mensagens durante a implantação.

O alinhamento, a parte que quase todos ignoram

O DMARC não exige apenas que SPF ou DKIM passem. Exige que o domínio que passou esteja alinhado com o domínio do cabeçalho From visível. Uma mensagem pode passar no SPF para mailer.vendor.com e ainda assim falhar no DMARC para example.com, porque os dois não coincidem. Esse é, de longe, o motivo mais comum de uma configuração aparentemente correta continuar falhando.

adkim e aspf controlam o rigor da correspondência. Relaxado (r, o padrão) aceita um subdomínio como mail.example.com; rígido (s) exige igualdade exata. Comece relaxado. O DMARC passa se qualquer um entre SPF e DKIM passar e estiver alinhado, então uma única assinatura DKIM alinhada já basta.

Como aplicar uma política com segurança

1. Publique p=none com um endereço de relatórios. Nada muda no seu fluxo de e-mail, mas os relatórios começam a chegar.
2. Leia os relatórios por duas a quatro semanas. Eles revelam serviços de envio esquecidos: o CRM, o suporte, a ferramenta de faturamento, a antiga plataforma de marketing.
3. Feche as lacunas. Acrescente cada remetente legítimo ao SPF, ative a assinatura DKIM com domínio alinhado e confirme a mudança no relatório seguinte.
4. Passe para p=quarantine. Use pct= para subir aos poucos se você envia em volume.
5. Termine em p=reject. Só quando os relatórios não mostrarem mais nenhuma mensagem legítima falhando. É essa a política que de fato impede a falsificação.

Como verificar os seus próprios registros

Os três são registros TXT públicos, então a verificação leva segundos:

1. SPF. Faça uma consulta TXT no seu domínio sem subdomínio com a ferramenta de consulta DNS e encontre a cadeia que começa com v=spf1. Confirme que existe exatamente uma e conte as consultas.
2. DMARC. Faça uma consulta TXT em _dmarc. mais o seu domínio. Se não voltar nada, você não tem política nem relatórios.
3. DKIM. Faça uma consulta TXT em seletor._domainkey. mais o seu domínio. A documentação do seu provedor indica o seletor usado.
4. Verifique ponta a ponta. Envie uma mensagem para uma conta de um grande provedor e inspecione os cabeçalhos recebidos. A visão «Mostrar original» do Gmail informa os resultados de SPF, DKIM e DMARC da mensagem que você acabou de enviar, e é o único teste que cobre a cadeia inteira.

Já que está no DNS, vale confirmar o restante da sua configuração de e-mail: veja se os seus registros MX apontam para onde você espera e se o nome no certificado do servidor corresponde, o que você pode checar com o verificador de certificados SSL.

Erros comuns a evitar

• Dois registros SPF. Junte-os em um só. Dois são erro permanente.
• Deixar o DMARC em p=none para sempre. Monitorar é ponto de partida, não destino. Só quarantine ou reject impede a falsificação.
• Não informar endereço de relatórios. Um registro DMARC sem rua= joga fora a informação necessária para endurecer a política com segurança.
• Esquecer domínios estacionados. Domínios que não enviam e-mail devem publicar v=spf1 -all e p=reject, justamente porque atacantes preferem domínios sem uso.
• Pular direto para o alinhamento rígido. adkim=s e aspf=s antes de relatórios limpos vão quebrar mensagens legítimas vindas de subdomínios.
• Ignorar o TTL. Um TTL alto num registro TXT faz uma correção demorar horas para se propagar. Baixe-o antes de uma migração e aumente-o depois.

Autentique o seu e-mail hoje

A autenticação de e-mail é uma das poucas tarefas de segurança com retorno inequívoco: melhor entregabilidade, visibilidade sobre abusos e um domínio que não se falsifica com facilidade. Além disso é totalmente legível de fora, então não há motivo para adivinhar a sua própria configuração. Comece com uma consulta TXT no seu domínio usando a ferramenta gratuita de consulta DNS, leia o que está realmente publicado e percorra a implantação acima passo a passo.

Ferramentas e guias relacionados:

• Consulta DNS – consulte registros TXT, MX, SPF e todos os outros de qualquer domínio.
• Consulta DNS: o guia completo – cada tipo de registro explicado.
• Verificador de certificados SSL – inspecione o certificado do seu servidor de e-mail ou web.
• Códigos de status HTTP – referência rápida de todos os códigos de resposta.
• Por que o seu registro SPF continua falhando (e como corrigir) - o limite de dez consultas, includes quebrados e outros motivos de falha do SPF.

Perguntas frequentes