O que são SPF, DKIM e DMARC
Se você já tentou enviar emails de um domínio próprio e viu suas mensagens caindo em spam, ou recebeu relatórios de que seus emails estão sendo rejeitados, provavelmente o problema e a falta de configuração de SPF, DKIM e DMARC. Esses três protocolos formam o padrão moderno de autenticação de email e são essenciais para qualquer domínio que envia emails.
Em resumo: o SPF (Sender Policy Framework) diz quais servidores tem permissão para enviar email pelo seu domínio. O DKIM (DomainKeys Identified Mail) assina digitalmente seus emails para provar que não foram alterados no caminho. E o DMARC (Domain-based Message Authentication, Reporting and Conformance) define o que fazer quando um email falha nas verificações anteriores - e te manda relatórios sobre o que esta acontecendo.
Esses protocolos existem porque o protocolo original de email (SMTP) foi criado em uma época em que ninguém se preocupava com segurança. Qualquer pessoa pode tecnicamente enviar um email dizendo que é de qualquer remetente - o que abriu espaço para spam e phishing. SPF, DKIM e DMARC foram criados para resolver esse problema sem quebrar o protocolo de email existente.
Como funciona cada protocolo
O SPF funciona através de um registro DNS do tipo TXT no seu domínio. Esse registro lista os servidores IP autorizados a enviar email pelo seu domínio. Quando um servidor de email recebe uma mensagem do seu domínio, ele consulta seu DNS e verifica se o IP de origem esta na lista. Se não estiver, o email pode ser marcado como suspeito ou rejeitado.
O DKIM usa criptografia de chave pública. Você gera um par de chaves: a chave privada fica no seu servidor de email e e usada para assinar cada mensagem. A chave pública e publicada no DNS. Quando o servidor destinatário recebe o email, ele consulta o DNS para buscar a chave pública e verifica a assinatura. Se a assinatura for valida, o email não foi alterado e veio de um servidor que tem a chave privada correta.
O DMARC depende dos dois anteriores. Ele define uma política: o que o servidor destinatário deve fazer quando um email do seu domínio falha no SPF ou DKIM. As opcoes são: não fazer nada (p=none, útil para monitoramento), mover para spam (p=quarantine) ou rejeitar completamente (p=reject). Além disso, o DMARC pode enviar relatórios XML para um email seu com detalhes de todos os emails enviados pelo seu domínio.
Por que isso importa para desenvolvedores
Como desenvolvedor, você vai encontrar esses protocolos em três situações principais:
- Lançando um SaaS ou produto: seu sistema de email transacional (cadastros, recuperação de senha, notificações) precisa de SPF e DKIM para não cair em spam. Sem isso, usuários não recebem o email de confirmação e você perde conversões.
- Configurando infraestrutura de email: se você usa Resend, SendGrid, Postmark, Amazon SES ou qualquer outro serviço de email, eles vao pedir para você adicionar registros DNS de SPF e DKIM no seu domínio para autenticar o envio.
- Diagnosticando problemas de entregabilidade: emails caindo em spam, bounces inexplicados, blacklists - em muitos casos o culpado e SPF/DKIM/DMARC mal configurado ou ausente.
Desde fevereiro de 2024, o Google e o Yahoo passaram a exigir SPF, DKIM e DMARC para remetentes que enviam mais de 5000 emails por dia. Para volumes menores, a ausência não bloqueia mas aumenta muito a chance de ir para spam.
Como configurar na prática
A configuração e feita adicionando registros no DNS do seu domínio. Os valores exatos dependem do serviço de email que você usa (o Resend, SendGrid, etc. fornecem os valores prontos), mas o formato e padrão:
# Registro SPF (tipo TXT, na raiz do domínio @)
v=spf1 include:_spf.seuservico.com ~all
# Explicação dos campos:
# v=spf1 = versão do protocolo
# include:_spf.seuservico.com = autoriza os servidores do serviço
# ~all = emails de outros servidores são "soft fail" (spam, não rejeitar)
# -all = emails de outros servidores são rejeitados (mais restritivo)
# Registro DKIM (tipo TXT, subdomínio específico)
# Nome: selector._domainkey.seudominio.com.br
# Valor: v=DKIM1; k=rsa; p=CHAVE_PUBLICA_AQUI
# Registro DMARC (tipo TXT, subdomínio _dmarc)
# Nome: _dmarc.seudominio.com.br
# Valor:
v=DMARC1; p=none; rua=mailto:[email protected]Para começar sem risco, use p=none no DMARC. Isso faz com que o protocolo apenas monitore e envie relatórios, sem bloquear ou mover para spam. Depois de analisar os relatórios por algumas semanas e confirmar que tudo esta funcionando, você pode mudar para p=quarantine e depois para p=reject.
Use a ferramenta MXToolbox (mxtoolbox.com/SuperTool.aspx) para verificar seus registros SPF, DKIM e DMARC depois de configurar. Ela mostra exatamente o que os servidores de email vao ver quando receberem seus emails.
Exemplo prático: configurando com o Resend
O Resend e um serviço de email transacional muito usado pela comunidade dev. Ao adicionar um domínio no Resend, ele gera os registros DNS que você precisa adicionar. O processo completo leva menos de 15 minutos:
1. No painel do Resend, va em Domains e clique em Add Domain. 2. Informe seu domínio (ex: meuapp.com.br). 3. O Resend vai mostrar os registros DNS que precisam ser adicionados: um TXT para SPF, um CNAME para DKIM e um TXT para o tracking opcional. 4. Adicione esses registros no painel do seu registrador de domínio (GoDaddy, Registro.br, Cloudflare, etc). 5. Volte ao Resend e clique em Verify. 6. A propagação pode levar até 48 horas, mas geralmente funciona em minutos.
# Verificar seus registros via linha de comando
# SPF
nslookup -type=TXT seudominio.com.br
# DKIM (substitua selector pelo valor do seu serviço)
nslookup -type=TXT selector._domainkey.seudominio.com.br
# DMARC
nslookup -type=TXT _dmarc.seudominio.com.brComparação entre serviços de email e suporte a autenticação
Todos os principais serviços de email transacional suportam SPF e DKIM, mas a forma de configurar varia:
- Resend: interface moderna, documentação clara, registros CNAME para DKIM (mais fácil de configurar que TXT). Muito popular na comunidade dev brasileira.
- SendGrid: muito estabelecido, suporta SPF via CNAME para delegar ao SendGrid ou via TXT próprio. DKIM configurado via painel.
- Amazon SES: mais configurável mas mais complexo. Requer configurar registros diretamente. Mais barato para volumes altos.
- Postmark: foco em entregabilidade, excelentes relatórios de bounce e spam. DKIM configurado por domínio de envio.
Independente do serviço, o processo e o mesmo: o serviço fornece os valores dos registros DNS, você os adiciona no seu DNS, e o serviço verifica e habilita o envio autenticado.
Pontos positivos e limitações
Os benefícios de ter SPF, DKIM e DMARC configurados são claros: melhor entregabilidade (emails chegam na inbox, não no spam), proteção contra uso indevido do seu domínio por spammers (phishing), e relatórios detalhados de quem esta enviando email em nome do seu domínio.
As limitações existem. O SPF tem um limite de 10 consultas DNS (lookups) - se você usa muitos serviços de email diferentes, pode exceder esse limite e causar falhas. O DKIM não protege o campo From que o usuário ve, apenas os cabeçalhos técnicos. E o DMARC com p=reject pode bloquear emails legítimos se a configuração não estiver correta, por isso a progressão gradual e importante.
Não configure DMARC com p=reject antes de monitorar com p=none por pelo menos 2 semanas. Se houver emails legítimos que não passam na autenticação (como emails encaminhados ou listas de distribuição), o p=reject vai bloqueá-los sem aviso.
Casos de uso reais
Scenarios onde SPF, DKIM e DMARC fazem diferença concreta:
- Startup SaaS lançando produto: o email de confirmação de cadastro não chega para 30% dos usuários porque vai para spam. Configura SPF e DKIM e o problema some em horas.
- E-commerce com emails de pedido: clientes reclamam que não recebem confirmação de compra. Sem DKIM, alguns provedores de email marcam como suspeito automaticamente.
- Empresa descobrindo phishing em seu nome: com DMARC e relatórios ativos, você descobre que terceiros estão enviando emails se passando pelo seu domínio e pode adicionar a política de rejeição para proteger seus clientes.
- Dev integrando envio de email em API: ao adicionar o domínio no Resend ou SendGrid, os próprios serviços te guiam pela configuração - e depois disso seus emails passam pelas verificações de autenticação automaticamente.
Dicas e boas práticas
Os relatórios DMARC chegam em formato XML quase ilegível. Serviços como DMARC Analyzer, Postmark DMARC ou o gratuito Google Postmaster Tools transformam esses dados em gráficos e alertas acionáveis.
O sufixo ~all (soft fail) e mais seguro que -all (hard fail) para começar. Com ~all, emails de servidores não autorizados vao para spam mas não são rejeitados. Isso evita perder emails legítimos enquanto você refina sua configuração.
O SPF tem limite de 10 consultas DNS. Cada include conta como uma consulta. Se você usa muitos serviços (Resend + SendGrid + HubSpot + ...), pode estourar o limite. Use spfflattening.com para simplificar registros SPF complexos.
Se você envia email de subdomínios (ex: [email protected]), cada subdomínio precisa de seus próprios registros SPF e DKIM. Um DMARC na raiz cobre todos os subdomínios para monitoramento, mas as autenticações são por subdomínio.
Vale a pena configurar SPF, DKIM e DMARC?
Sim, sem discussão. Não e mais uma opcao - e um requisito básico para qualquer domínio que envia email. Os grandes provedores de email (Google, Yahoo, Microsoft) já tratam emails sem autenticação como suspeitos por padrão, e essa tendência só vai aumentar.
A boa noticia e que a configuração e rápida. Com o serviço de email certo (Resend, SendGrid, Postmark), o processo todo leva menos de 15 minutos e a melhora na entregabilidade e imediata e mensurave.
O próximo passo: acesse o MXToolbox (mxtoolbox.com) agora, digite o seu domínio e veja o status dos seus registros SPF, DKIM e DMARC. Se algum estiver ausente ou com erro, siga a documentação do seu serviço de email para configurar hoje.
Comentários
Deixar um comentárioVocê precisa ter uma conta no CuritibaBlog para comentar.