Todo dia, criminosos enviam bilhões de e-mails se passando por marcas que não são. Faturas falsificadas, redefinições de senha forjadas, pedidos de CEO fraudulentos — todos funcionam porque, por padrão, qualquer pessoa pode colocar qualquer endereço no campo De de um e-mail. SPF, DKIM e DMARC existem para fechar essa brecha. Juntos, eles permitem que os provedores de caixa postal verifiquem que uma mensagem realmente veio do domínio que ela alega representar, e discretamente se tornaram o preço de entrada na caixa de entrada: desde fevereiro de 2024, Gmail e Yahoo exigem autenticação de todo remetente e SPF, DKIM e DMARC completos de remetentes em massa. Este guia percorre como cada protocolo funciona, os registros DNS exatos de que você precisa, os erros que os quebram silenciosamente e um plano de implantação que você pode seguir esta semana.
Ponto-Chave
SPF, DKIM e DMARC não são mais opcionais. Gmail e Yahoo exigem autenticação de todos os remetentes e aplicam SPF, DKIM e DMARC para quem envia 5.000+ mensagens por dia. E-mails não autenticados são cada vez mais rejeitados antes mesmo de o conteúdo ser avaliado — e a autenticação só compensa totalmente quando combinada com uma lista limpa e validada.
Por Que a Autenticação de E-mail Importa
O problema central é que o SMTP, o protocolo que move e-mails pela internet, foi projetado em uma era de confiança. Ele não faz nenhuma verificação de identidade sobre o endereço De visível. Essa única brecha de design alimenta phishing e comprometimento de e-mail corporativo (BEC) em escala industrial: o Internet Crime Complaint Center do FBI atribuiu cerca de 2,9 bilhões de dólares em prejuízos reportados a BEC só em 2023. Quando criminosos falsificam seu domínio, seus clientes são enganados e sua entregabilidade sofre — os provedores de caixa postal não conseguem distinguir suas campanhas reais das falsificações.
A autenticação resolve isso com três protocolos complementares baseados em DNS:
- SPF declara quais servidores têm permissão para enviar e-mail em nome do seu domínio
- DKIM assina criptograficamente cada mensagem para que adulteração e falsificação sejam detectáveis
- DMARC conecta os dois ao endereço De visível e diz aos destinatários o que fazer quando as verificações falham
O Mandato do Gmail e do Yahoo
Em fevereiro de 2024, Google e Yahoo transformaram uma prática recomendada de longa data em exigência dura. Todo remetente precisa se autenticar com pelo menos SPF ou DKIM. Remetentes que ultrapassam cerca de 5.000 mensagens por dia para um provedor precisam ter SPF e DKIM, além de uma política DMARC (mínimo p=none), um domínio De alinhado com a autenticação, cancelamento de inscrição em um clique respeitado em até dois dias, e uma taxa de reclamação de spam abaixo de 0,3%. E-mails fora de conformidade são primeiro reduzidos com erros temporários, depois rejeitados de vez. A Microsoft anunciou exigências equivalentes para grandes remetentes do Outlook.com em 2025, então a direção do setor é inequívoca.
A adoção está crescendo, mas está longe de ser universal: a análise da EasyDMARC sobre os 1,8 milhão de domínios mais importantes do mundo encontrou 47,7% com um registro DMARC em 2025 — e estudos do setor mostram consistentemente que uma grande parcela dos registros publicados ainda está na política de apenas monitoramento p=none, sem oferecer proteção real contra spoofing. Acertar isso ainda é uma vantagem competitiva.
SPF: Sender Policy Framework
Como o SPF Funciona
SPF é um registro DNS TXT que lista todos os servidores autorizados a enviar e-mail em nome do seu domínio. Quando um servidor receptor aceita uma conexão, ele olha para o domínio do Return-Path (também chamado de envelope from ou endereço MAIL FROM — não o cabeçalho De que seus destinatários veem), busca o registro SPF desse domínio e verifica se o IP conectado está na lista. Se estiver, o SPF passa; se não, o SPF falha totalmente ou falha parcialmente, dependendo da sua política.
Passo a Passo da Sintaxe do Registro
Um registro SPF típico para uma empresa que usa Google Workspace, uma plataforma de marketing e um IP de envio dedicado se parece com isto:
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 ~all"Lendo da esquerda para a direita:
- v=spf1 — a tag de versão; todo registro SPF começa com ela
- include:_spf.google.com — autoriza os servidores de envio do Google Workspace referenciando o próprio registro SPF do Google
- include:servers.mcsv.net — autoriza uma plataforma de marketing (Mailchimp, neste exemplo)
- ip4:203.0.113.10 — autoriza um endereço IPv4 específico, por exemplo o seu próprio servidor SMTP
- ~all — o catch-all: qualquer servidor não listado deve falhar parcialmente. O qualificador importa:
-allé uma falha total (recomendado quando seu registro estiver completo),~allé uma falha parcial, e+allautoriza a internet inteira — nunca use isso
O Limite de 10 Consultas DNS
A RFC 7208 limita a avaliação de SPF a 10 consultas DNS. Todo mecanismo include, a, mx, ptr e exists conta — e includes contam recursivamente, então o include de uma única plataforma de marketing pode consumir três ou quatro consultas sozinho. Ultrapasse o limite e os destinatários retornam permerror, que muitos provedores tratam como falha de SPF. Mecanismos simples ip4 e ip6 não custam nada, então prefira-os quando possível, remova serviços que você não usa mais e considere o achatamento (flattening) de SPF se você realmente precisar de muitos provedores.
Erros Comuns de SPF
- Publicar múltiplos registros SPF. Um domínio deve ter exatamente um registro começando com
v=spf1. Dois registros geram um erro permanente, que reprova a validação. Combine todos os mecanismos em um único registro. - Usar +all. Isso diz ao mundo que qualquer servidor pode enviar como se fosse você — desativando o SPF na prática e sinalizando seu domínio como mal configurado.
- Esquecer um serviço de envio. Seu helpdesk, sistema de cobrança e CRM enviam e-mail. Se não estiverem no registro, as mensagens deles falham parcialmente.
- Deixar o registro apodrecer. Serviços desativados deixam includes pendurados que desperdiçam consultas e podem criar exposição de segurança.
- Assumir que o SPF cobre o De visível. Ele verifica apenas o Return-Path. O alinhamento com o cabeçalho De é trabalho do DMARC, e é por isso que o SPF sozinho impede muito pouco spoofing.
DKIM: DomainKeys Identified Mail
Como Funciona a Assinatura DKIM
O DKIM adiciona uma assinatura criptográfica a cada mensagem enviada. Seu servidor de envio guarda uma chave privada e assina um hash do corpo da mensagem mais cabeçalhos selecionados (De, Assunto, Data e outros). A chave pública correspondente é publicada no seu DNS, e o servidor receptor a usa para verificar a assinatura. Uma assinatura válida comprova duas coisas: a mensagem foi autorizada pelo domínio que a assinou, e o conteúdo assinado não foi modificado em trânsito. Diferente do SPF, uma assinatura DKIM sobrevive a encaminhamentos, o que a torna o mecanismo mais resiliente dos dois.
Seletores e o Registro DNS
A chave pública vive em um nome DNS construído a partir de um seletor: seletor._domainkey.seudominio.com. Seletores permitem que várias chaves coexistam — uma por serviço de envio, ou chaves antigas e novas durante a rotação. Um registro de chave publicado se parece com isto:
s1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Zx8...IDAQAB"E cada mensagem assinada carrega um cabeçalho que a referencia:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s1;
h=from:subject:date:to:mime-version; bh=Kx9c1...; b=HqTf3...
A tag d= nomeia o domínio assinante e a tag s= nomeia o seletor — juntas, elas dizem ao destinatário exatamente onde buscar a chave pública.
Tamanho de Chave e Rotação
- Use chaves RSA de 2048 bits. Chaves de 1024 bits são consideradas fracas e alguns provedores as penalizam; 2048 bits é o padrão atual e o que o Google recomenda.
- Rotacione as chaves regularmente. A melhor prática do M3AAWG é rotacionar as chaves DKIM pelo menos a cada seis meses. Publique a nova chave sob um novo seletor, mude a assinatura e só então desative o registro antigo depois de alguns dias.
- Assine com seu próprio domínio. Muitas plataformas assinam com o domínio delas por padrão (o que autentica o e-mail, mas não alinha com o seu endereço De). Complete a configuração de DKIM com domínio próprio da plataforma para que
d=corresponda ao seu domínio.
DMARC: Política, Relatórios e Alinhamento
SPF e DKIM verificam, cada um, uma coisa, mas nenhum dos dois checa o endereço que seus destinatários realmente veem. O DMARC fecha esse ciclo: uma mensagem passa no DMARC apenas se SPF ou DKIM passar e o domínio que passou estiver alinhado com o domínio De visível. O DMARC também permite que você publique uma política dizendo aos destinatários o que fazer com falhas, e oferece relatórios para que você veja quem está enviando como se fosse o seu domínio — legitimamente ou não.
O Registro DMARC e a Progressão da Política
DMARC é um registro TXT em _dmarc.seudominio.com. Um registro inicial sensato:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"
A tag p= é o coração do registro, e foi projetada para ser endurecida em etapas:
- p=none — apenas monitoramento. E-mails que falham são entregues normalmente, mas você recebe relatórios. Toda implantação começa aqui.
- p=quarantine — e-mails que falham vão para o spam. Use
pct=para aumentar gradualmente, por exemplop=quarantine; pct=25aplica a política a um quarto das mensagens que falham. - p=reject — e-mails que falham são recusados de vez. Este é o destino final: proteção total contra spoofing, e pré-requisito para o BIMI.
Um registro em enforcement acaba se parecendo com isto:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"Relatórios rua e ruf
A tag rua= solicita relatórios agregados: resumos XML diários de cada provedor receptor mostrando quais IPs enviaram como se fossem o seu domínio, o que passou e o que falhou. Eles não contêm conteúdo de mensagens e são a principal ferramenta para descobrir serviços de envio esquecidos. A tag ruf= solicita relatórios de falha (forenses) — amostras de falhas por mensagem. Poucos provedores os enviam, e eles podem conter dados pessoais, então a maioria das equipes se apoia apenas no rua, processado por uma ferramenta de relatórios DMARC em vez de lido cru.
Alinhamento: Relaxado vs Estrito
O alinhamento é onde acontecem a maioria das falhas reais de DMARC. As tags aspf= e adkim= controlam quão próximo o domínio autenticado precisa corresponder ao domínio De. No modo relaxado (r, o padrão), uma correspondência de subdomínio passa — e-mail de news.seudominio.com se alinha com seudominio.com. No modo estrito (s), os domínios precisam corresponder exatamente. Comece relaxado; migre para estrito só depois que seus relatórios mostrarem que isso não vai quebrar e-mails legítimos. Lembre-se: o alinhamento de SPF compara o domínio do Return-Path, o alinhamento de DKIM compara o domínio d=, e basta um dos dois passar com alinhamento para o DMARC passar.
Os Três Protocolos em Resumo
| Protocolo | O que comprova | Registro DNS | Quando falha |
|---|---|---|---|
| SPF | O servidor de envio está autorizado para o domínio do Return-Path | TXT na raiz do domínio, começa com v=spf1 | IP não listado, mais de 10 consultas, encaminhamento, múltiplos registros |
| DKIM | A mensagem foi assinada pelo domínio e não foi alterada em trânsito | TXT em selector._domainkey, começa com v=DKIM1 | Chave ausente ou errada, conteúdo modificado, chave fraca ou expirada |
| DMARC | O domínio De visível corresponde ao que SPF ou DKIM autenticaram | TXT em _dmarc, começa com v=DMARC1 | Nem SPF nem DKIM passam com alinhamento ao domínio De |
Plano de Implantação Passo a Passo
- Audite todo serviço de envio (semana 1). Faça um inventário de tudo que envia como se fosse o seu domínio: suíte de e-mail, plataforma de marketing, CRM, helpdesk, cobrança, alertas de monitoramento. Esqueça um e você vai quebrar o e-mail dele depois.
- Publique ou corrija o SPF (semana 1). Um único registro, todas as fontes legítimas, abaixo de 10 consultas, terminando em
~all(endureça para-alldepois). - Ative o DKIM em tudo (semanas 1-2). Ligue a assinatura DKIM com domínio próprio e chaves de 2048 bits em cada plataforma do seu inventário, e verifique cada uma com uma mensagem de teste.
- Publique o DMARC em p=none com relatórios rua (semana 2). Sem impacto na entrega — você está só coletando dados.
- Monitore por 4-6 semanas. Revise os relatórios agregados semanalmente. Corrija toda fonte legítima que falhar no alinhamento; o que continuar falhando é spoofing.
- Endureça gradualmente. Mude para
p=quarantine; pct=25, aumente atépct=100, mantenha por algumas semanas e então mude parap=reject. Continue monitorando — novas ferramentas e fornecedores vão continuar aparecendo.
Além do DMARC: Uma Palavra sobre o BIMI
Depois de alcançar o enforcement, o BIMI (Brand Indicators for Message Identification) permite que provedores de caixa postal participantes exibam sua logo verificada ao lado das suas mensagens. Ele exige DMARC em p=quarantine ou p=reject com pct=100, uma logo em SVG e — para o selo azul verificado do Gmail — um Verified Mark Certificate vinculado a uma marca registrada (o Google também aceita Common Mark Certificates para exibição de logo). O BIMI não muda diretamente a filtragem, mas o selo de confiança visível ajuda mensuravelmente no reconhecimento e no engajamento, e é uma recompensa e tanto por terminar a jornada do DMARC.
Autenticação + Validação de Lista: A Stack Completa
Aqui está a parte que muitos guias pulam: autenticação comprova quem você é, não que seu e-mail é desejado. Os provedores de caixa postal combinam os dois sinais. Um remetente perfeitamente autenticado que dispara e-mails para uma lista velha ainda gera bounces e reclamações de spam, e o limite de 0,3% de reclamações do próprio Gmail se aplica independentemente da sua política DMARC. Taxas altas de bounce prejudicam exatamente a reputação de remetente que a autenticação deveria proteger.
É por isso que autenticação e higiene de lista são as duas metades de uma única estratégia de entregabilidade. O AT Valid executa mais de 20 verificações — sintaxe, MX, SMTP, detecção de descartáveis e catch-all entre elas — com 99,5% de precisão, para que toda mensagem que você assina com DKIM tenha de fato uma caixa de entrada real esperando por ela. Valide no momento da captura pela API, ou limpe listas existentes em lote com integrações nativas para Salesforce, HubSpot, Mailchimp, RD Station, Pipedrive, Zapier e webhooks. Nosso guia completo de entregabilidade de e-mail mostra como as duas disciplinas se reforçam.
Vantagem AT Valid
Domínio autenticado mais lista validada é a combinação de entregabilidade mais forte disponível. Crie uma conta gratuita no AT Valid e ganhe 200 créditos grátis para limpar sua lista enquanto seus relatórios DMARC chegam.
Conclusão
SPF, DKIM e DMARC formam um sistema de identidade em camadas: o SPF autoriza servidores, o DKIM assina conteúdo, o DMARC alinha os dois com o endereço que seus destinatários veem e aplica o resultado. Desde o mandato do Gmail e do Yahoo, eles são exigências básicas, não opções avançadas — e o caminho está bem sinalizado: audite seus remetentes, publique o SPF, ative o DKIM de 2048 bits, monitore em p=none e depois endureça para p=reject.
Faça isso junto com a validação contínua de listas e você cobre as duas perguntas que um provedor de caixa postal faz: esse remetente é genuíno, e esse e-mail é desejado? Pronto para completar sua stack de entregabilidade? Comece com 200 créditos de validação grátis e veja a diferença que um e-mail autenticado e validado faz.