Registros TXT explicados: SPF, DKIM e DMARC

Um registro TXT guarda um texto arbitrário associado a um nome de domínio. Parece trivial, mas é assim que todo o sistema de confiança do e-mail é publicado — além da maior parte das verificações de propriedade de domínio que você fará na vida.

O problema central é que o SMTP, projetado em 1982, permite que qualquer servidor afirme enviar em nome de qualquer domínio. Nada no protocolo impede isso. SPF, DKIM e DMARC são três camadas acrescentadas depois para corrigir isso, e as três vivem em registros TXT.

SPF: quais servidores podem enviar em seu nome

O SPF (Sender Policy Framework) publica uma lista de servidores autorizados a enviar e-mail pelo seu domínio. Um servidor receptor compara o IP que se conecta com essa lista.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ip4:93.184.216.34 ~all"

DKIM: uma assinatura criptográfica

O DKIM (DomainKeys Identified Mail) assina cada mensagem enviada com uma chave privada. Você publica a chave pública correspondente no DNS, e os receptores verificam a assinatura.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

A parte selector1 é escolhida pelo seu provedor de e-mail e incluída em cada mensagem assinada, para que os receptores saibam qual chave buscar. O uso de seletores permite rotacionar chaves, ou operar vários provedores, sem conflito.

A vantagem do DKIM sobre o SPF é que a assinatura cobre a própria mensagem, então ela sobrevive ao encaminhamento. Sua fraqueza é que ele não diz nada sobre mensagens que chegam sem nenhuma assinatura — a lacuna que o DMARC fecha.

DMARC: o que fazer quando os dois primeiros falham

O DMARC (Domain-based Message Authentication, Reporting and Conformance) une os outros dois: exige que o SPF ou o DKIM não apenas passem, mas estejam alinhados com o endereço From visível, e diz aos receptores o que fazer em caso de falha.

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=100"

Implantando os três com segurança

A ordem importa. Ir direto para p=reject é a forma clássica de tornar suas próprias faturas impossíveis de entregar.

1. 1

   Faça um inventário de tudo o que envia em seu nome

   Seu provedor de e-mail, claro — mas também ferramentas de faturamento, CRM, plataformas de marketing, sistemas de chamados e os e-mails transacionais do seu aplicativo. Tudo o que for esquecido aqui vai quebrar depois.

2. 2

   Publique o SPF com soft fail

   Inclua todos os remetentes do primeiro passo e termine com ~all. O soft fail marca remetentes não listados como suspeitos sem destruir e-mails enquanto você verifica a lista.

3. 3

   Ative a assinatura DKIM

   Ative em cada provedor e publique os registros de seletor que eles fornecerem. Envie uma mensagem de teste e confirme que a assinatura é verificada.

4. 4

   Comece o DMARC em p=none

   Apenas monitoramento. Colete relatórios agregados por duas a quatro semanas — eles revelarão remetentes que você esqueceu.

5. 5

   Endureça gradualmente

   Quando os relatórios mostrarem apenas fontes legítimas passando, passe para p=quarantine, opcionalmente com pct=25 primeiro, e depois para p=reject quando estiver limpo.

Os registros TXT não servem só para e-mail

O mesmo tipo de registro carrega a verificação de propriedade de domínio de dezenas de serviços — Google Search Console, Microsoft 365, Facebook e outros pedem que você publique um token como registro TXT e depois o verificam.

example.com.    IN    TXT    "google-site-verification=rXsLp2..."
example.com.    IN    TXT    "MS=ms12345678"

Eles convivem bem. Um domínio pode ter vários registros TXT; a única regra é que deve haver exatamente um começando com v=spf1.

Passe qualquer domínio pela ferramenta de consulta para ver todos os seus registros TXT juntos — uma forma rápida de identificar um registro SPF duplicado ou um token de verificação que nunca foi removido.