E‑mail “do meu próprio endereço”: entenda o spoofing e por que SPF, DKIM e DMARC nem sempre bloqueiam (Hotmail/Outlook)

Recebeu um e‑mail de extorsão dizendo que “hackearam você” e o remetente aparece como o seu próprio @hotmail.com/@outlook.com? Respire fundo: isso quase sempre é falsificação do endereço (spoofing), não invasão da conta. A seguir, explico tecnicamente o que acontece e como se proteger.

Índice

Visão geral: por que “eu me enviei um e‑mail”?

Em golpes de extorsão (“Pegasus/You’ve been hacked” e similares), criminosos falsificam o campo From para que o endereço pareça o seu. Essa falsificação explora características históricas do protocolo SMTP e diferenças entre os vários remetentes que uma mensagem carrega (o remetente “do envelope”, o Return‑Path, e o From exibido). Assim, mesmo sem acesso à sua conta, o golpista consegue fazer parecer que a mensagem veio de você.

Como alguém ainda consegue falsificar o campo “From”

O SMTP, criado nos anos 80, prioriza a entrega de mensagens e não exige, por padrão, comprovação criptográfica da identidade do From. A falsificação acontece de várias maneiras:

Servidor SMTP próprio ou comprometido: o atacante envia diretamente de um servidor que controla, preenchendo o From com o seu endereço.
Servidores mal configurados (open relay): hoje são raros, mas ainda existem; permitem enviar e‑mails arbitrários.
Bibliotecas e scripts: basta usar bibliotecas de envio (por exemplo, em Python, PHP, Node) e definir o From manualmente.
Serviços de e‑mail mal configurados: ferramentas legítimas de marketing/transacional podem permitir “From” arbitrário se o domínio não exige validação de remetente.

Importante: o cliente Outlook/Outlook.com não permite que você altere o From para um endereço que não controla. O truque acontece fora da sua conta — em outra infraestrutura — apenas declarando seu endereço no cabeçalho.

SPF, DKIM e DMARC — o trio que autentica e alinha remetentes

Para reduzir falsificações, a indústria criou três mecanismos complementares:

SPF (Sender Policy Framework): seu domínio publica no DNS a lista de IPs/hosts autorizados a enviar e‑mails. O servidor de destino checa se o IP emissor está na lista.
DKIM (DomainKeys Identified Mail): o servidor de origem assina parte da mensagem com uma chave privada. O destino verifica com a chave pública publicada no DNS do domínio.
DMARC (Domain‑based Message Authentication, Reporting and Conformance): combina os resultados de SPF e/ou DKIM e compara com o domínio do From (alinhamento). Também define a política: p=none (só observa), p=quarantine (desconfia/manda ao spam) ou p=reject (rejeita).

O que é “alinhamento” em DMARC?

DMARC só considera a mensagem “autenticada” se o domínio do From estiver alinhado com um dos dois:

SPF alinhado: o domínio do Return‑Path (também chamado de envelope sender ou 5321.MailFrom) coincide com o domínio do From (5322.From), seja em modo relaxado (aspf=r) ou estrito (aspf=s).
DKIM alinhado: o domínio no parâmetro d= da assinatura DKIM coincide com o domínio do From (modo relaxado/estrito via adkim=).

Se nenhum dos dois estiver alinhado, DMARC considera fail, e a política do domínio diz o que fazer.

Por que o e‑mail chega mesmo com falha em SPF/DKIM/DMARC

Há razões legítimas — e operacionais — para a entrega ocorrer mesmo com falhas:

Política DMARC permissiva: quando um domínio publica p=none, ele instrui os receptores a não rejeitar automaticamente, apenas a observar e, opcionalmente, marcar como spam. Alguns domínios de webmail já adotaram (ou adotam em determinados subdomínios/casos) políticas none ou quarantine para reduzir falsos positivos.
Evitar descartar e‑mails legítimos: provedores preferem entregar mensagens suspeitas na pasta Lixo/Spam, em vez de rejeitar definitivamente, para não perder comunicações válidas.
Reencaminhamento e listas de discussão: ao encaminhar, o servidor intermediário muda o IP de origem (quebrando SPF). Listas também alteram o conteúdo (quebrando DKIM). Se o domínio não tiver DMARC p=reject e/ou o intermediário não usar SRS (Sender Rewriting Scheme) ou ARC, muitas mensagens ainda chegam, porém no spam.
Heurísticas do provedor: filtros antispam usam reputação, conteúdo, histórico e sinais adicionais (ex.: ARC) e podem optar por aceitar/filtrar, mesmo com falhas pontuais de autenticação.

Tabela de problemas e soluções práticas

Problema	Esclarecimento / Solução prática
Falsificação (“spoofing”) do remetente	Acontece porque o SMTP não obriga a comprovação do From. Um invasor pode usar servidor próprio, um relay mal configurado ou ferramentas que constroem o e‑mail manualmente. O Outlook/Hotmail não permite trocar seu From por outro, mas nada impede que outra infraestrutura declare seu endereço. Solução: trate como fraude; analise cabeçalhos e denuncie como phishing.
Como funcionam SPF, DKIM e DMARC	SPF: DNS lista quem pode enviar; o destino confere o IP. DKIM: assinatura com chave privada; validação com chave pública no DNS. DMARC: combina e alinha resultados com o domínio do From e aplica a política (`none`, `quarantine` ou `reject`). Solução: para domínios próprios, publique e monitore os três.
Entrega mesmo com falha	Se o domínio do From publicar DMARC com `p=none` (observação) ou se o provedor quiser evitar falsos positivos, a mensagem pode ser aceita e ir para Lixo/Spam. Reenvios e listas também causam falsos fails. Solução: mantenha 2FA, ignore chantagem e, se for administrador, avance para `p=quarantine`/`p=reject` após fase de monitoramento.

Como ler os cabeçalhos e confirmar a fraude

Os cabeçalhos “completos” revelam de onde a mensagem realmente veio e os resultados de autenticação.

Onde encontrar os cabeçalhos

Outlook.com/Hotmail (web): abra a mensagem → Mais ações (⋮) → Exibir origem da mensagem.
Outlook (Windows): abra a mensagem → Arquivo → Propriedades → Cabeçalhos da Internet.
Gmail (web): abra a mensagem → ícone de três pontos → Mostrar original.

O que procurar

Authentication‑Results: linhas como spf=fail, dkim=fail/none, dmarc=fail e o header.from= mostram a análise do servidor de destino.
Received: cadeia de servidores que encaminharam o e‑mail. Um IP de origem estranho → suspeita.
Return‑Path (envelope sender): muitas vezes difere do From e denuncia o domínio real do envio.

Exemplo de bloco de autenticação (para estudo)

Authentication-Results: mx.exemplo.net;
  spf=fail (ip 203.0.113.10 não autorizado) smtp.mailfrom=atacante.exemplo
  dkim=none (sem assinatura)
  dmarc=fail (policy=quarantine) header.from=hotmail.com
Return-Path: &lt;bounce@atacante.exemplo&gt;
From: "Seu Nome" &lt;seu_endereco@hotmail.com&gt;

SPF, DKIM e DMARC em profundidade (com exemplos práticos)

SPF

Um registro típico SPF fica no DNS do seu domínio:

seudominio.com.  3600  IN  TXT  "v=spf1 include:_spf.seuprovedor.net ip4:198.51.100.0/24 -all"

-all = falha dura (recomendada quando terminar sua fase de testes).
~all = softfail, útil durante migrações.
Limite de 10 “lookups” por avaliação; includes demais quebram o SPF.

DKIM

Você publica no DNS uma chave pública por “selector”. O servidor de envio assina a mensagem:

selector1._domainkey.seudominio.com. 3600 IN TXT
"v=DKIM1; k=rsa; p=CHAVEPUBLICABASE64"

Boas práticas: chaves de 2048 bits, rotação periódica e um selector por sistema de envio (ex.: mkt, tx, app).

DMARC

O registro DMARC vai em _dmarc.seudominio.com:

_dmarc.seudominio.com. 3600 IN TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@seudominio.com; ruf=mailto:dmarc@seudominio.com; fo=1; pct=100; aspf=s; adkim=s"

p=none para monitorar (fase inicial com relatórios).
p=quarantine para enviar suspeitas ao spam.
p=reject para rejeitar na borda (fase final).
aspf/adkim: alinhamento estrito (s) reduz superfícies de spoofing.

Por que reenviadores e listas causam “falsos fails”

Ao encaminhar, o servidor intermediário entrega a mensagem com outro IP, que normalmente não está no SPF do remetente original, gerando spf=fail. Já listas de discussão costumam modificar o assunto ou o corpo (assinaturas, rodapés), quebrando a assinatura DKIM.

Mitigações existentes:

SRS (Sender Rewriting Scheme): reescreve o MailFrom para preservar SPF.
ARC (Authenticated Received Chain): permite ao servidor de destino confiar na autenticação feita pelo intermediário.
Alinhamento via DKIM: se o DKIM alinhado passa, DMARC passa mesmo que SPF falhe.

Golpe de extorsão: sinais típicos e o que fazer

Ameaças e urgência: pedido de pagamento imediato em criptomoeda; tom intimidatório.
Senhas antigas vazadas: o e‑mail inclui uma senha velha de algum vazamento — usado como “prova”.
Remetente idêntico ao seu: o From mostra seu endereço, mas os cabeçalhos desmentem.

Como agir: não responda, não clique, não baixe anexos. Marque como phishing no seu cliente (Outlook/Outlook.com: Lixo eletrônico → Phishing). Se configurou regras no cliente, evite “excluir permanentemente” — o treinamento do filtro ajuda outros usuários.

Checklist rápido para o usuário final

Ative autenticação de dois fatores (2FA) na sua conta de e‑mail.
Troque sua senha por uma única e forte. Considere um gerenciador de senhas.
Verifique cabeçalhos e confirme spf=fail/dmarc=fail para classificar como spoofing.
Denuncie como phishing no cliente de e‑mail.
Se o golpe cita uma senha antiga, troque senhas semelhantes em outros serviços.

Para quem administra um domínio próprio

Se você controla seudominio.com, implemente autenticação forte para proteger seus usuários e a reputação do domínio:

Mapeie todos os remetentes (sistemas e provedores que enviam por você: correio transacional, marketing, aplicativos, ERP).
Publique SPF consolidado (evite exceder 10 lookups; use flattening com cautela).
Ative DKIM em cada serviço de envio com selectors dedicados.
Comece com DMARC p=none e colete relatórios por algumas semanas; corrija fontes não alinhadas.
Evolua para p=quarantine e depois p=reject (idealmente com aspf=s e adkim=s).
Monitore dashboards/relatórios DMARC para flagrar abusos e novas fontes legítimas.

Extras que valem a pena:

MTA‑STS e TLS‑RPT para exigir TLS na entrega e receber relatórios de problemas.
BIMI (com VMC) após DMARC em p=quarantine/reject — melhora a visibilidade e confiança da marca em caixas de entrada compatíveis.

Tabela: políticas DMARC e efeito provável

Política	Significado	Comportamento comum nos provedores	Uso recomendado
`p=none`	Monitoramento; não instrui a rejeitar	Aceitam e sinalizam/relatam; muitas vezes vai ao Lixo/Spam	Fase inicial para mapear remetentes
`p=quarantine`	Mensagens suspeitas devem ser “quarentenadas”	Normalmente entregues no spam	Fase intermediária, após correções
`p=reject`	Instrução clara para rejeitar na borda	As não alinhadas costumam ser rejeitadas	Fase final para máxima proteção

Entendendo os diferentes “remetentes” do e‑mail

Header From (5322.From): é o que o usuário vê. Pode ser falsificado.
Envelope From (5321.MailFrom): aparece como Return‑Path; usado para SPF e bounces.
Reply‑To: para onde a resposta vai (muitas fraudes desviam para outro endereço).
Sender: opcional; indica quem enviou em nome de quem.

DMARC exige que o Header From esteja alinhado com SPF e/ou DKIM.

Como checar a política DMARC de um domínio (método local)

Sem depender de ferramentas externas, você pode consultar via terminal:

nslookup -type=TXT _dmarc.hotmail.com
nslookup -type=TXT _dmarc.outlook.com
dig TXT _dmarc.seudominio.com +short

O resultado mostrará algo como "v=DMARC1; p=none|quarantine|reject; ...". Use isso apenas para verificar o que está publicado no momento da sua análise (políticas podem mudar ao longo do tempo).

FAQ — dúvidas que aparecem sempre

O golpista entrou na minha conta?

Na esmagadora maioria dos casos, não. Ele apenas falsificou o From. Se ainda assim ficou inseguro, troque a senha, revise sessões/dispositivos conectados e ative 2FA.

Por que o e‑mail veio “de mim” mas partiu de um IP desconhecido?

Porque o cabeçalho From é apenas texto. O IP que entregou a mensagem (visível em Received:) pertence à infraestrutura do golpista ou a um serviço intermediário abusado.

SPF passou mas DMARC falhou. Como pode?

SPF pode ter passado para um domínio diferente do From (desalinhado). Sem alinhamento com o From, DMARC falha.

DKIM passou, mas ainda foi para o spam. Por quê?

Passar DKIM/DMARC não garante reputação. Conteúdo suspeito, reputação do IP, histórico e queixas de usuários influenciam fortemente a filtragem.

Posso bloquear todos os e‑mails “de mim para mim”?

Não é recomendável. Muitos serviços legítimos enviam notificações com seu endereço ou em seu nome (quando alinhados). Prefira regras que combinem múltiplos sinais (falha em autenticação + palavras‑chave de extorsão, por exemplo).

Recomendações finais (boas práticas)

Ignore e exclua mensagens de chantagem; não responda nem clique em links.
Verifique cabeçalhos: procure spf=fail e dmarc=fail, confirmando que se trata de spoofing.
Mantenha 2FA e senha forte para afastar invasões reais.
Se administrar domínio próprio, defina DMARC com política quarantine ou reject após a fase de monitoramento e acompanhe relatórios.
Denuncie a mensagem como phishing no cliente de e‑mail; isso treina filtros e ajuda outros usuários.

Resumo curto: o invasor não entrou na sua conta — apenas falsificou o endereço. SPF, DKIM e DMARC detectam a fraude, mas a política do domínio e a cautela dos servidores de destino permitem que a mensagem ainda seja entregue (geralmente no spam). Para se proteger, use autenticação forte e, se tiver domínio próprio, aplique políticas DMARC mais rígidas.

Modelo de resposta e de denúncia (opcional)

Se precisar responder internamente em sua organização ou abrir um chamado:

Assunto: Golpe de extorsão com spoofing do meu endereço

Recebemos uma mensagem de extorsão em que o campo From mostra meu próprio endereço.
Análise preliminar dos cabeçalhos:

- Authentication-Results: spf=fail / dkim=none / dmarc=fail (header.from=...).
- IP de envio não pertence ao nosso domínio.
  Ações realizadas:
- Marcação como phishing no cliente de e-mail.
- Nenhum link clicado, nenhum anexo aberto.
  Solicito bloqueio/reputação do IP/domínio e acompanhamento.

Roteiro de implantação para equipes técnicas

Inventariar remetentes e fluxos (transacional, marketing, aplicativos, terceiros).
Publicar SPF consolidado e validado (provisionar subdomínios dedicados, se necessário).
Ativar DKIM com chaves de 2048 bits em todos os sistemas.
Publicar DMARC p=none com rua/ruf e coletar relatórios.
Corrigir desalinhamentos; migrar gradualmente para p=quarantine e depois p=reject.
Estabelecer monitoramento contínuo (alertas, dashboards, rotação de chaves).
Treinar usuários para reconhecer e denunciar phishing.

Erros comuns que mantêm portas abertas ao spoofing

SPF com muitos includes e estouro de lookups: o destino marca como permerror; trate isso como falha.
DKIM sem rotação de chaves: aumenta risco de vazamento/comprometimento.
DMARC “esquecido” em p=none indefinidamente: permite abuso contínuo do domínio.
Uso de vários provedores sem alinhamento: cada fonte precisa assinar DKIM e estar no SPF.
Responder à chantagem: engaja o golpista e confirma que sua caixa é ativa.

Conclusão

Aparecer como remetente de si mesmo não significa invasão: é a face mais comum do spoofing. Entendendo a função de SPF, DKIM e DMARC — e como políticas e cenários de reenvio influenciam a entrega — você ganha clareza para agir. Para quem só usa @hotmail.com/@outlook.com, a melhor defesa é higiene de conta (2FA, senha forte) e denúncia sistemática de phishing. Para quem administra um domínio, o caminho é mapear fontes, ativar assinaturas e consolidar o DMARC em p=reject. Assim, você reduz a superfície de ataque e a vitrine da sua identidade de e‑mail.