SPF, DKIM e DMARC: Proteja o Domínio da Sua Empresa

Por que a autenticação de e-mail deixou de ser opcional

O e-mail continua sendo o principal vetor de ataques contra empresas brasileiras. Phishing, fraude do boleto, golpe do falso fornecedor e comprometimento de e-mail corporativo (BEC) têm um ponto em comum: quase sempre começam com uma mensagem que parece vir de um remetente legítimo. E aqui está o detalhe que muita gente ignora — o protocolo SMTP, criado nos anos 1980, não verifica por padrão se quem enviou a mensagem tem autorização para usar aquele domínio. Sem controles adicionais, qualquer servidor no mundo pode enviar um e-mail dizendo ser "financeiro@suaempresa.com.br", e o destinatário não tem como saber que é falso.

É exatamente essa lacuna que SPF, DKIM e DMARC fecham. Os três são registros DNS que trabalham em conjunto para provar que uma mensagem foi realmente enviada por servidores autorizados pelo dono do domínio, que ela não foi alterada no caminho e que existe uma política clara sobre o que fazer com mensagens que falham nessas verificações. Não se trata de tecnologia experimental: Google e Yahoo passaram a exigir autenticação de remetentes em massa desde 2024, e a Microsoft seguiu o mesmo caminho no Outlook. Domínio sem autenticação hoje significa e-mails caindo em spam — ou simplesmente rejeitados.

Além do risco de fraude, há um impacto direto no negócio: a entregabilidade. Propostas comerciais que não chegam, notas fiscais bloqueadas, comunicados internos marcados como suspeitos. Configurar os três registros corretamente protege sua marca contra falsificação e garante que seus e-mails legítimos cheguem à caixa de entrada.

SPF: definindo quem pode enviar em nome do seu domínio

O SPF (Sender Policy Framework) é o mais antigo e mais simples dos três mecanismos. Ele funciona como uma lista de convidados: você publica no DNS do seu domínio um registro TXT informando quais servidores estão autorizados a enviar e-mails em seu nome. Quando um servidor de destino recebe uma mensagem, ele consulta esse registro e verifica se o IP de origem está na lista. Se não estiver, a verificação falha.

Um registro SPF típico de uma empresa que usa Microsoft 365 se parece com isto: v=spf1 include:spf.protection.outlook.com -all. O trecho include autoriza os servidores da Microsoft, e o -all no final instrui os destinatários a rejeitar qualquer outra origem. Empresas que usam ferramentas de marketing, ERP que dispara notas fiscais ou sistemas de cobrança precisam incluir cada um desses serviços no registro — e é aí que a maioria dos problemas aparece.

• Limite de 10 consultas DNS: o SPF permite no máximo 10 lookups por verificação. Empresas que acumulam muitos include estouram esse limite e o registro passa a falhar silenciosamente, com resultado "permerror".
• Qualificador frouxo: terminar o registro com ~all (softfail) ou, pior, +all, na prática permite que qualquer um envie pelo seu domínio sem consequência.
• Registros duplicados: só pode existir um registro SPF por domínio. Dois registros TXT começando com v=spf1 invalidam ambos.
• Serviços esquecidos: sistemas legados, impressoras multifuncionais e aplicações internas que enviam e-mail direto costumam ficar de fora da lista e ter mensagens bloqueadas.

O SPF sozinho tem uma limitação importante: ele valida o remetente do envelope (o endereço técnico usado na transação SMTP), não o endereço que aparece no campo "De:" que o usuário enxerga. Um golpista pode passar no SPF usando o próprio domínio no envelope e exibir o seu domínio no "De:". Por isso o SPF nunca deve ser a única camada.

DKIM: a assinatura digital que garante integridade

O DKIM (DomainKeys Identified Mail) resolve um problema diferente: provar que a mensagem foi realmente autorizada pelo domínio e que não foi alterada no trajeto. Funciona com criptografia de chave pública. O servidor de envio assina digitalmente cada mensagem com uma chave privada, e a chave pública correspondente fica publicada no DNS do domínio, em um registro específico chamado seletor. O servidor de destino busca essa chave pública e valida a assinatura.

Se qualquer parte assinada da mensagem for modificada no caminho — o corpo, o assunto, o remetente — a assinatura quebra e a verificação falha. Isso é especialmente relevante contra ataques de interceptação e adulteração de mensagens, comuns em fraudes de troca de boleto e alteração de dados bancários em propostas comerciais.

Uma mensagem com DKIM válido carrega uma prova matemática: ela saiu de um servidor que possui a chave privada do domínio e chegou intacta. Nenhum cabeçalho "De:" bonito substitui essa garantia.

Na prática, a configuração envolve gerar o par de chaves no serviço de e-mail (no Microsoft 365, isso é feito no Defender/Exchange Admin Center), publicar os registros CNAME dos seletores no DNS e ativar a assinatura. Dois cuidados importantes: use chaves de no mínimo 2048 bits — chaves de 1024 bits ainda são comuns e já são consideradas fracas — e lembre-se de configurar o DKIM separadamente para cada plataforma que envia em nome do domínio, incluindo ferramentas de e-mail marketing e sistemas transacionais. Cada serviço usa seu próprio seletor, então eles convivem sem conflito.

DMARC: a política que amarra tudo e devolve visibilidade

SPF e DKIM verificam, mas não decidem. É o DMARC (Domain-based Message Authentication, Reporting and Conformance) que responde à pergunta crucial: o que o servidor de destino deve fazer quando a mensagem falha na autenticação? Além disso, o DMARC introduz o conceito de alinhamento: exige que o domínio validado pelo SPF ou pelo DKIM seja o mesmo domínio que aparece no campo "De:" visível ao usuário — fechando justamente a brecha que o SPF sozinho deixa aberta.

O registro DMARC é publicado em _dmarc.seudominio.com.br e define uma política entre três níveis:

1. p=none: modo de monitoramento. Nada é bloqueado, mas você recebe relatórios sobre quem está enviando e-mails usando seu domínio. É o ponto de partida obrigatório.
2. p=quarantine: mensagens que falham vão para a pasta de spam do destinatário. Etapa intermediária, geralmente aplicada de forma gradual com o parâmetro pct.
3. p=reject: mensagens que falham são rejeitadas na entrega. É o objetivo final e o único nível que efetivamente impede a falsificação do domínio.

Os relatórios agregados (RUA) são o grande diferencial do DMARC: diariamente, provedores como Google e Microsoft enviam arquivos XML mostrando todos os IPs que enviaram mensagens usando seu domínio, com o resultado das verificações. É comum descobrir nesses relatórios sistemas legítimos esquecidos — e também campanhas ativas de spoofing usando a marca da empresa. Muitos domínios ficam presos em p=none para sempre, o que dá visibilidade mas não protege nada. A progressão none → quarantine → reject deve ser planejada e executada, tipicamente em um ciclo de 30 a 90 dias, depois que os relatórios confirmam que todas as fontes legítimas estão autenticando corretamente.

Erros comuns e monitoramento contínuo

A configuração inicial é só metade do trabalho. Os problemas mais frequentes que encontramos em auditorias de domínio se repetem: registro SPF estourando o limite de lookups depois que o marketing contratou uma nova ferramenta; DKIM que parou de assinar após uma migração e ninguém percebeu; DMARC publicado em p=none há dois anos sem que ninguém jamais tenha aberto um relatório; e subdomínios completamente desprotegidos — golpistas adoram enviar de nota-fiscal.suaempresa.com.br quando só o domínio raiz tem política.

Alguns pontos que merecem atenção contínua:

• Domínios estacionados: domínios registrados que não enviam e-mail também precisam de proteção — SPF v=spf1 -all e DMARC p=reject impedem seu uso em fraudes.
• Mudanças de fornecedor: toda troca de ERP, CRM ou plataforma de disparo exige revisão dos três registros antes da virada.
• Relatórios DMARC: o volume de XML é inviável de ler manualmente; use uma plataforma de análise ou um parceiro que consolide e interprete os dados.
• Encaminhamentos e listas: mensagens encaminhadas quebram SPF naturalmente; é o DKIM alinhado que mantém a entrega funcionando nesses cenários.
• BIMI como bônus: com DMARC em p=quarantine ou p=reject, o domínio se qualifica para exibir o logotipo da empresa na caixa de entrada, reforçando a marca.

O sinal de maturidade não é ter os três registros publicados — é ter alguém olhando os relatórios, tratando falhas de autenticação e evoluindo a política até o reject. Autenticação de e-mail é processo, não projeto com data de fim.

Proteja seu domínio com quem faz isso todos os dias

Configurar SPF, DKIM e DMARC exige mexer em DNS, entender o fluxo de e-mail de cada sistema da empresa e interpretar relatórios técnicos — e um erro no meio do caminho pode derrubar a entrega de e-mails legítimos. Por isso, a implantação segura segue um roteiro: inventário de todas as fontes de envio, correção do SPF, ativação do DKIM em cada plataforma, DMARC em monitoramento, análise dos relatórios e só então o avanço gradual até a política de rejeição.

A Duk Informática & Cloud executa esse roteiro há anos para empresas de todos os portes. São mais de 18 anos de experiência e 550+ empresas atendidas, com a chancela de Microsoft Gold Partner — o que significa domínio profundo do ecossistema Microsoft 365 e Exchange Online, onde a maioria das empresas brasileiras opera seu e-mail. Nossa equipe faz o diagnóstico do seu domínio, implanta a autenticação completa sem interromper o fluxo de mensagens e mantém o monitoramento contínuo dos relatórios DMARC, com suporte 24/7 e SLA definido.

Se você não sabe hoje qual é a política DMARC do seu domínio — ou se acabou de descobrir que ela não existe — esse é o momento de agir. Fale com a Duk e solicite uma avaliação da autenticação de e-mail da sua empresa antes que um golpista use sua marca para atacar seus clientes e fornecedores.