SPF, DKIM e DMARC ajudam a verificar o uso de domínios em uma mensagem, mas não certificam que uma cobrança seja verdadeira. Um golpista pode autenticar corretamente um domínio que controla. Também pode tentar imitar uma empresa apenas no nome que aparece na caixa de entrada.
A conferência precisa separar três perguntas: qual endereço aparece como remetente, quais domínios foram autenticados e se a solicitação faz sentido. Um resultado técnico positivo responde a parte desse percurso; não substitui a confirmação de um pagamento ou de uma mudança de conta bancária.
Neste artigo
O nome exibido e o endereço não são a mesma informação
Considere este remetente fictício:
From: "Empresa Conhecida — Financeiro" <[email protected]>
O nome antes dos sinais de menor e maior pode sugerir uma organização. O endereço, porém, usa ofertas.example. Reconhecer a marca no texto não demonstra que o domínio pertença a ela. Todos os endereços deste artigo são fictícios; .example é usado para demonstração.
Antes de abrir um anexo ou responder, expanda os detalhes do remetente no seu cliente de e-mail. Observe também o endereço de resposta, quando diferente. Não teste uma cobrança enviando dinheiro nem confirme uma troca bancária pelo telefone informado na própria mensagem suspeita.
O que cada mecanismo verifica
A explicação da Cloudflare sobre autenticação de e-mail apresenta os três mecanismos. Eles atuam sobre informações diferentes:
| Mecanismo | Pergunta técnica central | O que não demonstra sozinho |
|---|---|---|
| SPF | O servidor que enviou a mensagem está autorizado para a identidade de domínio verificada no transporte? | Que o nome exibido seja verdadeiro ou que o conteúdo seja seguro |
| DKIM | Uma assinatura de domínio é verificável para os elementos da mensagem que ela cobre? | Que a pessoa citada aprovou aquela cobrança |
| DMARC | Há autenticação aprovada com domínio alinhado ao domínio do remetente visível? | Que o domínio autenticado pertence à empresa que o leitor imaginou |
No SPF, não basta olhar o campo From. A identidade usada na verificação pode ser a do remetente do envelope SMTP. No DKIM, o domínio associado à assinatura aparece no parâmetro d=; nos resultados do receptor, costuma aparecer como header.d.
Por que dois resultados “pass” podem não bastar
O RFC 9989, que define o DMARC, relaciona a autenticação ao domínio do autor mostrado no From. Para aprovação DMARC, é necessário um caminho aprovado e alinhado: SPF ou DKIM. Não é obrigatório que os dois caminhos sejam aprovados simultaneamente.
Alinhamento não significa apenas encontrar alguma assinatura válida. O domínio autenticado precisa corresponder ao domínio de referência segundo as regras aplicáveis. Os exemplos abaixo usam coincidência exata para não depender de regras de subdomínio:
| Domínio no From | SPF aprovado para | DKIM aprovado para | Leitura do exemplo |
|---|---|---|---|
loja.example |
envios.example |
loja.example |
Há caminho DKIM aprovado e alinhado |
loja.example |
envios.example |
envios.example |
Os dois passam, mas nenhum coincide com o From |
ofertas.example |
ofertas.example |
ofertas.example |
Autenticação alinhada não prova vínculo com outra empresa |
São situações didáticas, não consultas DNS ou testes de entrega realizados pelo Ponto Nulo. A terceira linha é a razão para não transformar DMARC aprovado em selo de honestidade.
Como ler um cabeçalho de resultado
Este trecho sintético representa o primeiro caso da tabela:
From: "Loja de Exemplo" <[email protected]>
Authentication-Results: mx.destino.example;
spf=pass smtp.mailfrom=envios.example;
dkim=pass header.d=loja.example;
dmarc=pass header.from=loja.example
Leia o resultado junto da identidade: SPF passou para envios.example; DKIM passou para loja.example; o domínio visível é loja.example. A coincidência do segundo caminho explica a aprovação DMARC nesse cenário.
O RFC 8601, sobre Authentication-Results, também exige considerar quem produziu a informação. Uma linha com esse nome pode ser inserida numa mensagem; sua mera presença não torna o conteúdo confiável. Use os resultados reconhecidos pelo seu provedor receptor, em vez de escolher qualquer ocorrência de pass no cabeçalho bruto.
Uma falha também precisa de contexto
Uma mensagem encaminhada ou modificada no percurso pode apresentar problemas de autenticação sem ser uma tentativa de golpe. As orientações do Gmail para remetentes tratam, entre outros pontos, de autenticação, alinhamento e encaminhamento.
Isso não transforma uma falha em algo que deva ser ignorado. Significa que o resultado precisa acompanhar a investigação: a mensagem foi encaminhada? O domínio é conhecido? Há uma mudança inesperada de destinatário, anexo ou forma de pagamento? Para um usuário final, confirmar por outro canal costuma ser mais útil do que tentar corrigir o DNS de um remetente.
Um roteiro para uma cobrança inesperada
Primeiro, confira o endereço completo e compare o domínio com uma referência que você já conhece. Depois, consulte os detalhes de autenticação disponibilizados pelo provedor. Guarde a diferença entre domínio aprovado e organização alegada.
Se houver pedido de pagamento, troca de senha ou envio de documento, abra o serviço pelo aplicativo ou endereço habitual e procure a solicitação por lá. Quando precisar telefonar, use um contato previamente conhecido. Preserve a mensagem para a equipe responsável sem publicar cabeçalhos que contenham endereços ou dados de terceiros.
Se a confirmação independente não localizar a cobrança, interrompa a ação e encaminhe a mensagem pelo recurso de denúncia do provedor ou pelo canal de segurança da organização. A decisão deve considerar a solicitação concreta, mesmo quando todos os resultados de autenticação aparecem como aprovados.
