O que SPF, DKIM e DMARC fazem de fato
Pense nos três como uma corrente com três elos. O SPF autoriza os servidores que podem enviar pelo seu domínio. O DKIM anexa uma assinatura criptográfica para que o destinatário saiba que a mensagem não foi alterada no caminho. O DMARC vincula os dois ao domínio que o leitor de fato vê na linha From: e publica uma política para quando a verificação falha. Em resumo: o SPF verifica o envelope, o DKIM verifica o conteúdo e o DMARC verifica se um dos dois corresponde ao nome que o destinatário lê.
SPF: quais servidores podem enviar pelo seu domínio
Um registro SPF é uma única entrada TXT no DNS que começa com v=spf1 e lista os hosts e includes autorizados a enviar pelo domínio, terminando com um mecanismo all. Duas regras pegam muita gente. Primeiro, um domínio só pode publicar um registro v=spf1; um segundo faz a avaliação retornar permerror, e a autenticação na prática falha (RFC 7208, seção 4.5). Segundo, o SPF pode executar no máximo dez mecanismos que consultam o DNS — include, a, mx, ptr, exists e o modificador redirect — durante a avaliação; passou de dez, o resultado volta a ser permerror (seção 4.6.4). O qualificador final é a política: ~all é um softfail (aceita, mas marca), -all é um hardfail (rejeita remetentes não listados) e +all aprovaria tudo, por isso você nunca o publica. Um limite estrutural que vale conhecer: o SPF autentica o domínio oculto do Return-Path, não o From: visível, e quebra no encaminhamento, porque o IP do servidor que encaminha não está no seu registro — exatamente por isso o DMARC não depende só do SPF.
DKIM: uma assinatura impossível de alterar em silêncio
O DKIM assina cada mensagem enviada com uma chave privada guardada pelo seu sistema de envio e publica a chave pública correspondente no DNS. A assinatura cobre os cabeçalhos escolhidos e o corpo, então, se algo for alterado no trânsito, a assinatura deixa de ser válida. Os destinatários encontram a chave por meio de um seletor: o cabeçalho DKIM-Signature traz s= (o seletor) e d= (seu domínio), e o verificador consulta selector._domainkey.yourdomain para obter a chave pública (RFC 6376, seção 3.6.2.1). Os seletores também permitem manter várias chaves ao mesmo tempo, e é isso que deixa a rotação limpa — publique um novo seletor, passe a assinar com ele e então aposente o antigo (um valor de chave vazio o marca como revogado). Quanto ao tamanho da chave, a RFC 6376 exige chaves RSA de pelo menos 1024 bits para uso prolongado, e os verificadores precisam aceitar chaves de até 2048 bits; 2048 bits é o padrão moderno sensato, e fazer a rotação das chaves periodicamente limita o estrago se uma delas vazar.
DMARC: a política que amarra tudo
O DMARC é o registro que dá sentido ao SPF e ao DKIM para o domínio que o destinatário lê. A ideia central é o alinhamento. Uma mensagem só passa no DMARC quando o SPF ou o DKIM produz um pass e esse pass se baseia em um identificador alinhado com o domínio From: visível (RFC 7489, seção 4.2). É por isso que uma mensagem pode passar no SPF puro e ainda falhar no DMARC: se o seu ESP (provedor de serviço de e-mail) envia com o próprio domínio de Return-Path, o SPF passa para o ESP, mas esse domínio não está alinhado com o seu From:, então o lado SPF do DMARC falha. O alinhamento tem dois modos — o relaxado, que aceita um domínio organizacional correspondente (mail.yourco.com se alinha com yourco.com), e o estrito, que exige correspondência exata. Como basta um dos mecanismos alinhado, o alinhamento DKIM costuma dar conta das mensagens que o SPF não cobre, como as encaminhadas. O registro em si é v=DMARC1; p=none; rua=mailto:reports@yourco.com; a tag p define a política (none, quarantine ou reject), rua indica para onde os relatórios agregados são enviados e sp define uma política separada para subdomínios — que assume o valor de p se você a omitir.
Por que isso virou obrigatório em 2024
A autenticação era uma boa prática opcional. Em fevereiro de 2024, virou uma barreira. O Gmail e o Yahoo agora exigem que os remetentes em massa — o Google conta qualquer remetente com mais de 5.000 mensagens por dia para o Gmail — se autentiquem com SPF e DKIM e publiquem um registro DMARC, que pode começar em p=none. E-mails de marketing e para inscritos também precisam oferecer cancelamento de inscrição com um clique: o cabeçalho List-Unsubscribe (RFC 2369) mais List-Unsubscribe-Post: List-Unsubscribe=One-Click, o mecanismo de um clique da RFC 8058, para que o cliente de e-mail do destinatário cancele a inscrição com um único POST HTTPS. Você pode ler as regras completas do Gmail e do Yahoo no panorama de entregabilidade. Duas coisas a notar: a fiscalização ficou mais rígida desde 2024, então siga a regra mesmo abaixo de 5.000 por dia, e manter as reclamações de spam baixas é um requisito ao lado da autenticação, não um extra.
Erros comuns que quebram a autenticação sem aviso
- Publicar +all no seu registro SPF, o que autoriza a internet inteira a enviar em seu nome — o oposto do objetivo.
- Manter mais de um registro v=spf1 no mesmo domínio, o que retorna permerror e anula o SPF.
- Estourar o limite de dez consultas DNS ao adicionar includes de fornecedores, o que também retorna permerror.
- Uma chave DKIM curta demais ou que nunca passa por rotação, de modo que uma chave vazada ou quebrada por força bruta continua assinando indefinidamente.
- Pular direto para p=reject antes de ler um único relatório agregado, o que bloqueia e-mail legítimo que você esqueceu que envia.
- Esquecer o sp= para subdomínios, de modo que uma política frouxa deixa marketing.yourco.com aberto ao spoofing.
- Um remetente terceiro — um ESP, uma ferramenta de faturamento, um help desk — que você nunca alinhou ao SPF e ao DKIM, e cujo e-mail por isso falha no DMARC.
Onde a autenticação entra na sua stack
A autenticação é a base sobre a qual todo o resto se apoia. Se você hospeda a ferramenta você mesmo, o DNS e as chaves de assinatura são inteiramente seus, a forma mais forte de controlar a própria identidade de remetente. Uma plataforma de engajamento do cliente deve mostrar o status de autenticação e de alinhamento de cada domínio de envio em vez de escondê-lo, para que você veja de relance quais fontes passam. Envie e-mails transacionais e de marketing por fluxos separados e, de preferência, por subdomínios separados, para que um pico de reclamações no marketing nunca ameace a entrega da redefinição de senha. E faça tudo na ordem certa: autenticação e alinhamento vêm primeiro, antes de aquecer o domínio — um aquecimento em um domínio não autenticado só ensina os provedores a desconfiar de você mais rápido.