Um dia, um e-mail suspeito que parece vir do domínio da sua própria empresa cai na sua própria caixa de entrada. Primeiro — respire. Na maioria dos casos isto não é uma intrusão; é um remetente falsificado. Eis como distinguir e como impedir (sem passos de ataque).
Primeiro, tranquilidade: spoofing ≠ tomada de controle
Este é o equívoco-chave. O "remetente" no envelope de um e-mail pode ser escrito livremente por quem envia. Então um único e-mail com o nome do seu domínio escrito nele não significa que invadiram sua casa.
Dito isso, uma caixa de e-mail genuinamente comprometida não é impossível. A forma de distinguir as duas é ler os headers.
Use os headers para distinguir "invasão" de "falsificação"
Por trás do corpo, todo e-mail carrega um "header" — seu registro de entrega (no Gmail: "Mostrar original"). Cinco campos importam mais.
| Header | O que olhar | Como ler |
|---|---|---|
| Authentication-Results | os resultados de spf= / dkim= / dmarc= | dmarc=fail significa "a autenticação real não passou = provável falsificação" |
| Received (uma pilha) | a linha de baixo = a verdadeira origem | se saiu de algum lugar que não o seu próprio host, é uma falsificação externa |
| Return-Path (remetente do envelope) | bate com o From visível? | uma divergência é um sinal de falsificação |
| Reply-To (destino da resposta) | para onde uma resposta de fato vai | o From parece interno mas o Reply-To é um endereço externo sem relação → uma forma de fazer você responder ao remetente |
| X-Mailer (software de envio) | um nome sensato? | algo aleatório e ilegível = um sinal típico de uma ferramenta de spam automatizada |
O Reply-To é o que as pessoas deixam passar. O From pode parecer exatamente um colega, mas uma resposta vai para um endereço externo completamente diferente, onde vão te fazer devolver segredos ou um contato (um QR code de chat, etc.) para sequestrar seu canal de comunicação. Não confiar no From só pela aparência é sua defesa humana mais forte (→ o que é phishing).
Por que ele chega à sua caixa de entrada
Um e-mail falsificado se infiltra — nem mesmo no spam — porque o receptor não tem base para rejeitar a falsificação.
Nenhuma política DMARC
Sem política DMARC no seu domínio, o receptor consegue detectar a falsificação do From mas não pode ser forçado a rejeitá-la. Esta é a maior razão isolada de ele chegar à caixa de entrada.
O SPF está configurado para não rejeitar (~all)
Se o SPF termina em ~all (softfail = "suspeito mas não rejeite"), o receptor não tem um motivo claro para rejeitá-lo.
O encaminhamento quebra o SPF
Encaminhar uma mensagem recebida para outro endereço faz o SPF parecer "pass" contra o servidor de encaminhamento, enquanto o From continua sendo um domínio diferente. O DMARC é o que toma a decisão final sobre essa divergência.
É aqui que o DKIM importa. O SPF quebra no encaminhamento, mas uma assinatura DKIM continua válida. O DKIM é o que impede que o e-mail legítimo seja rejeitado por engano depois que você chega ao reject, e é exatamente por isso que você configura o DKIM primeiro.
A correção: SPF → DKIM → DMARC, em etapas
A mecânica está em o que são SPF / DKIM / DMARC; aqui está só a ordem segura. O ponto mais importante: nunca pule direto para reject.
Um registro SPF correto
Ative a assinatura DKIM (faça isto primeiro)
Comece o DMARC em p=none (só monitorar)
p=none mais coleta de relatórios e observe por 1–2 semanas que o e-mail legítimo não é rejeitado.Eleve em etapas até reject
p=quarantine → p=reject. Só quando "falsificações são rejeitadas no receptor" é alcançado é que um e-mail como este é rejeitado antes de chegar à caixa de entrada do alvo.O que falta varia de domínio para domínio
Verifique vários domínios e você notará que as configurações que faltam costumam ser exatamente opostas, porque, quando a configuração de envio difere, difere também a parte que o serviço configura por você.
Configuração de serviço de e-mail
- ex.: e-mail transacional enviado por um serviço de entrega externo
- DKIM / DMARC tendem a ser configurados automaticamente no onboarding
- mas o SPF precisa ser adicionado ao DNS por você → essa é a lacuna
Configuração padrão de hospedagem
- ex.: e-mail enviado diretamente de um servidor de hospedagem
- o SPF geralmente já está presente desde o início
- mas o DKIM é um botão manual e o DMARC é seu para publicar → esses dois são a lacuna
Ambos são "nem todos os três presentes"; o que falta é simplesmente o inverso. O primeiro passo é saber qual padrão é o seu domínio.
A visão deste site: configurar não basta — só funciona depois que você verifica
Neste site tratamos a autenticação de e-mail como algo que só funciona depois que você verifica, não "configurar e esquecer". Você pode checar o estado atual do seu próprio domínio de uma vez com o verificador de SPF / DKIM / DMARC ou a auditoria de segurança do site.
Até um único valor exige cuidado. Por exemplo, colocar fo num registro sem endereço de relatório de falha (ruf) não faz nada; pela especificação, é simplesmente ignorado. Esses ajustes "inofensivos mas inúteis", pegos só na revisão, são comuns.
O que mais importa são duas coisas: fazer o receptor rejeitar a falsificação (DMARC) e as pessoas não responderem à mensagem falsa. Antes da detecção ou das configurações, coloque em primeiro lugar um design que detém por mecanismo.
Leia a seguir
- Alerta: CVE-2026-124194: abrir um arquivo de mensagem no Outlook vaza o hash NTLM (explorado)
- Glossário: O que são SPF / DKIM / DMARC (a mecânica)
- Glossário: O que é phishing
- Ferramentas: Verificador de SPF / DKIM / DMARC / Auditoria de segurança do site
- Relacionado: Guia de autenticação multifator (MFA)
- Para pessoas físicas: spam saindo do seu próprio endereço — três lugares para verificar se você foi hackeado