Blog

SPF, DKIM e DMARC, o e-mail de verificação que chega à caixa de entrada

UNIFOKAL5 min de leituraProduto e integração

Código por e-mail que cai em spam mata a conversão do onboarding. Como SPF, DKIM e DMARC autenticam o domínio remetente, e por que a política DMARC também protege o seu cliente de phishing em seu nome.

De todos os e-mails que uma empresa envia, o código de verificação é o mais impaciente. O usuário está com o cadastro aberto, olhando para a caixa de entrada, esperando seis dígitos para continuar. Se a mensagem demora, ele reenvia; se cai em spam, ele não procura, abandona. Entregabilidade de e-mail transacional não é tema de marketing: é taxa de conversão do onboarding, e a base técnica dela cabe em três siglas de padrões abertos, SPF, DKIM e DMARC.

Como o provedor decide o destino da mensagem

Quem decide se o seu e-mail chega à caixa de entrada é o provedor do destinatário, com base em dois grandes grupos de sinal: reputação, o histórico do domínio e dos servidores remetentes, e autenticação, a prova de que a mensagem veio mesmo de quem diz ter vindo. Sem autenticação, nem a melhor reputação se sustenta, porque o provedor não sabe a quem atribuí-la. Os três padrões dividem o trabalho assim:

  • SPF, definido na RFC 7208: um registro TXT no DNS do domínio lista quais servidores estão autorizados a enviar e-mail em nome dele. O receptor consulta o DNS e confere se o servidor que entregou a mensagem está na lista.
  • DKIM, definido na RFC 6376: o remetente assina criptograficamente cabeçalhos e corpo da mensagem, e a chave pública fica no DNS. A assinatura prova que a mensagem passou pelo domínio assinante e não foi alterada no caminho.
  • DMARC, definido na RFC 7489: amarra os dois anteriores ao domínio que o usuário vê no campo do remetente, o chamado alinhamento, e publica uma política que diz ao receptor o que fazer quando a verificação falha: nada (none), quarentena (quarantine) ou rejeição (reject). E fecha o ciclo com relatórios agregados que os provedores enviam ao dono do domínio contando o que observaram na prática.

Os grandes provedores de caixa de entrada passaram a exigir de remetentes de volume exatamente essa tríade. Na prática, e-mail sem autenticação alinhada virou cidadão de segunda classe na fila de entrega, e e-mail transacional de verificação não pode se dar a esse luxo.

As sutilezas que derrubam a entrega

A configuração inicial é simples; os detalhes é que carregam o risco.

  • Subdomínio dedicado para o transacional. Enviar o código de verificação de um subdomínio próprio, separado do domínio que dispara campanhas, isola a reputação: uma campanha mal recebida não arrasta o código de verificação para o spam junto.
  • Política DMARC por etapas. Começar em política nenhuma (p=none) coletando relatórios, mapear quem envia legitimamente em nome do domínio, e só então subir para quarentena e rejeição. Pular direto para a rejeição sem esse mapa derruba e-mail legítimo seu, o efeito oposto do desejado.
  • O limite de consultas do SPF. A RFC 7208 limita a avaliação a dez consultas de DNS; acumular inclusões de vários fornecedores ao longo dos anos estoura o limite e o SPF passa a falhar em silêncio.
  • Encaminhamento quebra SPF, não quebra DKIM. Mensagem encaminhada chega ao destino a partir de um servidor fora da sua lista, mas a assinatura DKIM sobrevive ao trajeto. É por isso que o DMARC aceita qualquer um dos dois alinhado, e é por isso que depender só de SPF é frágil.

O que o DMARC protege além da entrega

Há um segundo efeito, menos falado e mais valioso. Com política de rejeição publicada, ninguém consegue entregar e-mail forjado com o seu domínio exato no campo do remetente: os provedores que respeitam o padrão descartam a mensagem. O golpe de phishing que diz confirme sua identidade em nome da sua marca perde a arma mais convincente, o remetente idêntico ao verdadeiro. A política não impede domínios parecidos, o golpista ainda pode registrar a marca com uma letra trocada, mas o obriga a sair do seu domínio, onde os filtros e os olhos do usuário têm mais chance de pegá-lo. Autenticar o domínio é, também, um dever de proteção ao seu cliente, não só uma otimização de funil.

E vale manter o realismo sobre o que o e-mail entregue prova. Como já discutimos em detalhe, o código digitado prova posse da caixa de e-mail naquele momento, não identidade. Entregabilidade resolve o funil; o papel do código no fluxo continua sendo o de um fator entre vários, ao lado de documento e biometria.

Operação: medir como parte do funil

O time que trata o e-mail de verificação como infraestrutura de conversão monitora três coisas. A taxa de entrega e de queda em spam, pelos relatórios DMARC e pelas métricas do provedor de envio. O tempo entre o pedido e a chegada do código, porque atraso de minutos mata a conversão tanto quanto o spam. E a taxa de conclusão da etapa no funil, que é onde qualquer degradação aparece primeiro, antes de qualquer alerta técnico. Esses números pertencem ao mesmo painel dos webhooks e da API, pelo argumento que já defendemos ao tratar do monitoramento da integração de KYC: integração sem medição só avisa que quebrou pelo cliente reclamando.

Na UNIFOKAL, o código por e-mail é um módulo do fluxo de verificação, ao lado do SMS, do documento e da biometria, e a entregabilidade é tratada como requisito de produto, porque um fator que não chega não é um fator. O que nenhuma configuração garante, e desconfie de quem garantir, é entrega de cem por cento: caixa lotada, filtro agressivo do destinatário e endereço digitado errado continuam existindo. O que a tríade garante é outra coisa: que a sua mensagem não seja descartada por não autenticada, e que ninguém entregue mensagem se passando pelo seu domínio. É o chão da operação; sem ele, o resto do funil está construído sobre areia.

Fontes citadas