O que é spoofing de e-mail? Como funciona e como evitar

O spoofing de e-mail é a falsificação das informações do remetente de uma mensagem, de modo que ela pareça vir de uma pessoa ou organização confiável quando não é o caso. Isso é possível porque o SMTP, protocolo original de e-mail, foi criado sem verificação de remetente. Qualquer servidor pode alegar que envia mensagens em nome de qualquer domínio, a menos que esse domínio publique registros de autenticação (SPF, DKIM e DMARC) que permitam aos servidores de destino checar essa alegação.

A falsificação de domínios de e-mail continua sendo uma das técnicas mais usadas por cibercriminosos para se passar por empresas e organizações legítimas. Ao forjar a identidade de uma instituição confiável, eles aumentam significativamente as chances de que suas mensagens sejam abertas, lidas e consideradas legítimas pelas vítimas.

Esses ataques são comumente usados em campanhas de phishing, fraudes financeiras, roubo de credenciais e distribuição de malware. As mensagens podem conter links para sites falsos, anexos maliciosos ou solicitações enganosas que levam os usuários a compartilhar informações sensíveis ou a realizar ações que comprometem a segurança de pessoas e organizações.

Com o avanço da inteligência artificial, as campanhas de phishing se tornaram ainda mais sofisticadas. Hoje, os criminosos conseguem criar mensagens altamente personalizadas, que reproduzem o estilo de comunicação, a identidade visual e até os padrões de escrita de empresas legítimas, tornando as fraudes cada vez mais difíceis de identificar.

O impacto do spoofing vai além das vítimas diretas. Organizações que têm seus domínios usados indevidamente podem sofrer prejuízos à reputação, perda de confiança de clientes e parceiros e aumento dos riscos operacionais. Em alguns casos, a ausência de medidas de proteção adequadas pode até gerar preocupações relacionadas à conformidade e à governança de segurança da informação.

Como funciona o spoofing de e-mail

Todo e-mail carrega dois endereços de remetente distintos, e é essa brecha que o spoofing explora.

O remetente do envelope (envelope sender, definido pelo comando MAIL FROM) é usado pelos servidores de e-mail para rotear a mensagem. Ao chegar ao destino, esse valor costuma ser registrado no cabeçalho Return-Path , usado para tratar devoluções (bounces). Normalmente, os destinatários nunca veem esse endereço.
O From do cabeçalho (header From) é o endereço exibido na caixa de entrada do destinatário. Ele é apenas uma linha de texto dentro da mensagem, e o servidor de envio não precisa comprovar que tem autorização para usá-lo.

Um criminoso pode, portanto, definir o From do cabeçalho como cobranca@suaempresa.com.br enquanto envia a mensagem de um servidor sem nenhuma relação com o domínio. Nada precisa ser invadido: nenhuma caixa de entrada é comprometida, nenhuma senha é roubada. A mensagem é simplesmente montada com informações falsas de remetente e entregue a um servidor de e-mail que a aceita.

É por isso que as organizações costumam descobrir o spoofing de forma indireta: por mensagens de devolução referentes a e-mails que nunca enviaram, por reclamações de clientes sobre faturas fraudulentas ou por uma queda repentina na entregabilidade, causada pelo prejuízo à reputação de envio do domínio.

Como identificar um e-mail falsificado

Uma mensagem falsificada parece legítima na caixa de entrada, então a verificação precisa ser feita nos cabeçalhos. No Gmail, abra a mensagem e selecione "Mostrar original"; no Outlook, use Arquivo › Propriedades › Cabeçalhos da Internet. Procure a linha Authentication-Results.

SPF, DKIM ou DMARC com resultado fail indicam que o servidor de envio não foi autorizado pelo domínio que aparece no endereço From.
Um Return-Path que não corresponde ao endereço From visível é um indício comum, embora serviços legítimos de disparo de e-mails também produzam essa divergência.
Cabeçalhos Received que apontam para uma infraestrutura sem relação com o remetente declarado são um sinal forte.

Se o domínio que está sendo falsificado é o seu, os relatórios agregados de DMARC são a forma mais rápida de confirmar isso e de identificar quais servidores enviam mensagens em seu nome. Configurar o DMARC em modo de monitoramento, como descrito adiante, é o primeiro passo prático.

Como proteger seu domínio de e-mail contra spoofing: SPF, DKIM, DMARC e BIMI

Embora o spoofing seja possível por causa de limitações dos protocolos originais de e-mail, existem mecanismos amplamente adotados que ajudam a autenticar mensagens e a reduzir significativamente a possibilidade de falsificação. São eles SPF, DKIM, DMARC e BIMI. Os três registros principais funcionam como uma cadeia: SPF e DKIM fornecem, cada um, um sinal, e o DMARC informa aos servidores de destino o que fazer quando esses sinais falham.

Registros SPF

O SPF (Sender Policy Framework) é um dos mecanismos fundamentais de proteção de domínios de e-mail. Trata-se de um registro publicado no DNS que especifica quais servidores estão autorizados a enviar mensagens em nome de um determinado domínio.

Quando um e-mail é recebido, o servidor de destino consulta o registro SPF do domínio remetente para verificar se o servidor que enviou a mensagem está autorizado. Se a validação for bem-sucedida, a mensagem pode seguir para etapas adicionais de análise. Caso contrário, pode ser rejeitada, colocada em quarentena ou marcada como suspeita, conforme a política configurada.

Apesar de sua importância, o SPF sozinho não é suficiente para impedir todas as formas de spoofing. Por isso, deve ser usado em conjunto com outras tecnologias de autenticação.

O SPF também tem um ponto cego específico: ele valida o remetente do envelope, não o endereço From do cabeçalho, que é o que o destinatário realmente vê. Uma mensagem pode passar no SPF e ainda assim exibir um From forjado. Fechar essa brecha é função do alinhamento do DMARC.

Os principais mecanismos usados em um registro SPF são:

ip4: autoriza servidores por endereços IPv4.
ip6: autoriza servidores por endereços IPv6.
a: autoriza os endereços IP associados ao registro A do domínio.
mx: autoriza os servidores definidos nos registros MX do domínio.
include: permite autorizar serviços externos de envio de e-mail.
all: define a política aplicada aos servidores não autorizados.

Exemplos:

v=spf1 ip4:203.0.113.10 ip4:198.51.100.20 -all

Autoriza dois servidores de envio.

v=spf1 include:spf.protection.outlook.com a:mail.example.com -all

Autoriza os servidores de envio do Microsoft 365 e o servidor cujo endereço IP está associado ao registro A de mail.example.com.

```
v=spf1 mx ~all
```

Autoriza os servidores definidos nos registros MX do domínio. As mensagens enviadas por outros servidores recebem uma indicação de falha branda (~all), o que permite ao servidor de destino decidir como tratá-las.

É importante considerar que um registro SPF mal configurado pode fazer com que e-mails legítimos deixem de ser entregues. Antes de publicar ou alterar um registro SPF, as organizações devem validar a configuração e testar seu impacto nos fluxos de entrega de e-mails.

Na prática, dois tipos de falha respondem pela maior parte dos problemas com SPF. O primeiro é o limite de consultas DNS: um registro SPF pode acionar no máximo dez consultas, e cada include: de um serviço terceirizado de envio consome pelo menos uma. Organizações que usam várias plataformas de marketing, atendimento e CRM costumam ultrapassar esse limite, o que invalida o registro inteiro. O segundo é o encaminhamento de mensagens: o SPF falha quando o e-mail é encaminhado, porque o servidor que encaminha não está na lista de autorizados. Os dois casos são motivos para tratar o SPF como um sinal entre vários, e não como proteção isolada.

DKIM (DomainKeys Identified Mail)

O DKIM (DomainKeys Identified Mail) é outro mecanismo de autenticação de e-mail, que usa criptografia assimétrica para verificar a autenticidade e a integridade das mensagens enviadas. Funciona como uma camada adicional de autenticação, complementando o SPF e reforçando a proteção contra spoofing e outros ataques relacionados à falsificação de identidade.

O funcionamento do DKIM pode ser dividido em duas etapas principais. Primeiro, a mensagem que sai é assinada: quando um e-mail é enviado de um domínio com DKIM configurado, o servidor acrescenta aos cabeçalhos uma assinatura digital, gerada com a chave privada associada ao domínio. Em seguida, o servidor de destino recupera a chave pública publicada no DNS do domínio remetente e verifica a assinatura, validando a autenticidade da mensagem e confirmando que o conteúdo assinado não foi alterado durante a transmissão.

Esse mecanismo não apenas ajuda a impedir o uso não autorizado do domínio de envio, como também reforça a confiança dos servidores de destino no remetente. E-mails de domínios com DKIM corretamente configurado têm mais chance de passar nas verificações de autenticação e podem contribuir para melhorar a reputação do domínio junto aos provedores.

A configuração do DKIM não é complexa, mas envolve várias etapas técnicas. As organizações devem seguir as orientações de seus provedores de e-mail, como Google Workspace ou Microsoft 365, que incluem a geração das chaves, a publicação do registro no DNS e a ativação da assinatura das mensagens.

A chave pública é publicada em um subdomínio específico do seletor, o que permite ao domínio manter várias chaves em paralelo, uma para cada plataforma de envio:

selector1._domainkey.example.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Use chaves de pelo menos 2048 bits e faça a rotação periodicamente. Diferentemente do SPF, o DKIM sobrevive ao encaminhamento, porque a assinatura viaja junto com a mensagem.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Como complemento a essas duas tecnologias, foi desenvolvido o DMARC (Domain-based Message Authentication, Reporting and Conformance). O protocolo usa os resultados de validação do SPF e do DKIM, permitindo que os donos do domínio definam políticas de tratamento para e-mails que não atendem aos requisitos de autenticação.

Conforme a política DMARC publicada pelo dono do domínio, o servidor de destino pode aceitar, rejeitar ou colocar em quarentena (enviando para a caixa de spam, por exemplo) um e-mail que não cumpra os requisitos estabelecidos. Além disso, o protocolo permite o envio de relatórios periódicos ao administrador do domínio, dando visibilidade sobre falhas de autenticação e possíveis tentativas de spoofing. Essas informações ajudam as organizações a monitorar o uso do domínio e a ajustar as políticas de segurança conforme necessário.

O DMARC acrescenta o elemento que falta ao SPF e ao DKIM isoladamente: o alinhamento. Ele exige que o domínio validado pelo SPF ou pelo DKIM corresponda ao domínio do endereço From visível, e é isso que efetivamente impede um criminoso de exibir sua marca na caixa de entrada do destinatário.

O registro DMARC é publicado como um registro TXT em _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s

As principais tags:

p=: a política aplicada às mensagens que falham na validação: none, quarantine ou reject.
rua=: o endereço que recebe os relatórios agregados.
pct=: o percentual de mensagens reprovadas às quais a política é aplicada, usado para avançar gradualmente.
sp=: a política para subdomínios, alvo frequente de criminosos quando o domínio principal está protegido.
adkim= / aspf=: o rigor do alinhamento: relaxado(r), que é o padrão, ou estrito(s).

Implantar o DMARC de uma só vez é a causa mais comum de perda de e-mails por erro próprio. A sequência recomendada é:

Publique p=none com um endereço para relatórios e não altere mais nada. A entrega de mensagens não é afetada.
Leia os relatórios agregados por quatro a oito semanas, até ter um inventário completo de todos os serviços que enviam mensagens em seu nome. Plataformas de marketing, sistemas de faturamento, ferramentas de RH e helpdesks costumam passar despercebidos.
Autentique todos os remetentes legítimos com SPF e DKIM, e corrija as falhas de alinhamento.
Passe para p=quarantine, começando com um valor baixo de pct= e aumentando conforme acompanha os relatórios.
Passe para p=reject , a única política que de fato impede que mensagens falsificadas cheguem aos destinatários. Um domínio parado permanentemente em p=none está monitorado, não protegido.

A autenticação de e-mail agora é requisito de entregabilidade, não só medida de segurança

Desde 2024, os principais provedores de caixa de entrada passaram a tratar a autenticação como condição de entrega, e não como recomendação. Google e Yahoo introduziram exigências para remetentes de grande volume, em linhas gerais os que enviam cerca de 5.000 mensagens por dia aos seus usuários, cobrindo autenticação por SPF e DKIM, política DMARC publicada, descadastramento em um clique para mensagens de marketing e taxas de reclamação de spam abaixo de um limite definido. A Microsoft anunciou posteriormente exigências semelhantes para remetentes de alto volume que enviam para domínios do Outlook.com.

A consequência prática é que organizações sem esses registros passam a arcar com dois custos, e não apenas um: seu domínio fica disponível para quem quiser se passar por elas, e seus e-mails legítimos de campanhas, faturamento e notificações têm cada vez mais chance de serem filtrados ou rejeitados. Confirme os limites atuais na documentação de cada provedor antes de planejar a implantação, já que essas exigências continuam a ser endurecidas.

BIMI

Até aqui, todas as políticas discutidas neste artigo operam principalmente nos bastidores, sem interação direta com o usuário final que recebe o e-mail. Embora essas tecnologias sejam essenciais para validar a autenticidade das mensagens, também é importante oferecer aos destinatários uma forma visual de reconhecer que a comunicação pertence de fato à organização indicada.

É aí que entra o BIMI (Brand Indicators for Message Identification), um padrão de autenticação e identificação visual que permite às organizações exibir seus logotipos ao lado dos e-mails enviados de seus domínios. O logotipo pode aparecer diretamente na caixa de entrada do destinatário, por exemplo ao lado do nome do remetente, proporcionando reconhecimento visual imediato da marca e reforçando a confiança na comunicação por e-mail.

A implementação do BIMI exige algumas etapas comuns à maioria dos provedores. Primeiro, é preciso preparar um logotipo compatível, geralmente em formato SVG, com requisitos específicos de segurança e padronização, garantindo que a imagem esteja corretamente associada ao domínio de envio. Além disso, o DMARC precisa estar configurado com política de imposição (p=quarantine ou p=reject), o que exige SPF e DKIM devidamente implementados e alinhados. Dependendo do provedor e do nível de validação exigido, também pode ser necessário um VMC (Verified Mark Certificate) ou outro certificado aceito pelo ecossistema BIMI. Esse certificado precisa ser emitido por uma autoridade certificadora reconhecida, como a DigiCert, para comprovar a titularidade e a autenticidade do logotipo utilizado.

O BIMI é a última etapa, não a primeira. Como depende de o DMARC já estar em imposição, só vale a pena buscá-lo quando a cadeia SPF, DKIM e DMARC estiver completa e estável.

Como proteger sua organização de e-mails falsificados que chegam às caixas de entrada

SPF, DKIM, DMARC e BIMI protegem seu domínio de ser usado contra terceiros. Eles não fazem nada em relação às mensagens falsificadas que chegam às caixas de entrada dos seus funcionários a partir de domínios que você não controla, incluindo domínios de parceiros e fornecedores com autenticação fraca ou inexistente, e domínios sósias registrados justamente para escapar dela.

A proteção de entrada é uma camada à parte, e precisa cobrir:

Filtragem de e-mails no servidor ou em nuvem, que valida os resultados de SPF, DKIM e DMARC na chegada e coloca em quarentena as mensagens reprovadas, inclusive as vindas de domínios cuja política está apenas em modo de monitoramento.
Detecção de domínios sósias e de falsificação do nome de exibição, casos em que o domínio de envio está corretamente autenticado, mas foi registrado para se parecer com um domínio confiável.
Análise de anexos e URLs, já que as informações falsas de remetente costumam ser o meio de entrega de um link ou documento malicioso, e não o ataque em si.

O ESET Mail Security e o ESET Cloud Office Security aplicam essas verificações às mensagens que chegam a servidores locais e a ambientes do Microsoft 365 e do Google Workspace, combinando validação de autenticação com antiphishing, antispam e verificação de anexos.

Tecnologia e educação: uma dupla necessária

Essas tecnologias, embora complementares, têm papel fundamental na construção de um ambiente de comunicação por e-mail mais seguro e confiável. Ao permitir a validação do domínio remetente, a verificação da integridade das mensagens e a aplicação de políticas contra tentativas de spoofing, elas reduzem as oportunidades de os cibercriminosos usarem domínios legítimos de forma indevida e conduzirem campanhas fraudulentas.

Na prática, a sequência importa mais do que os registros isolados: publique o SPF, assine com DKIM, implante o DMARC em modo de monitoramento, trabalhe os relatórios até que todos os remetentes legítimos estejam autenticados e só então mude a política para imposição. A proteção oferecida por esses mecanismos vai além da própria organização, pois ajuda usuários e clientes a desenvolver mais confiança nas mensagens que recebem.

Ainda assim, só a tecnologia não basta. A educação em cibersegurança segue sendo um componente essencial para reforçar a proteção de empresas, funcionários e clientes. À medida que as ameaças de falsificação de identidade e engenharia social continuam evoluindo, todos precisam estar preparados para identificar sinais de e-mails fraudulentos, compreender os riscos da comunicação eletrônica e adotar comportamentos seguros no ambiente digital.

Perguntas frequentes

É possível impedir que meu e-mail seja falsificado?

Não dá para impedir que um criminoso escreva seu endereço em uma mensagem, mas é possível fazer com que os servidores de destino rejeitem o resultado. Publicar registros SPF e DKIM e aplicar uma política DMARC de p=reject significa que mensagens que alegam vir do seu domínio, mas falham na autenticação, são recusadas antes de chegar ao destinatário.

Como saber se alguém está falsificando meu e-mail?

A evidência mais clara são os relatórios agregados do DMARC, que listam todos os servidores enviando mensagens em nome do seu domínio. Mensagens de devolução referentes a e-mails que você nunca enviou e relatos de clientes sobre faturas ou redefinições de senha inesperadas são os sinais de alerta mais comuns.

O que acontece quando um e-mail é falsificado?

O destinatário vê uma mensagem que parece vir de um remetente confiável. Nada do seu lado é comprometido, nenhuma conta é acessada e nenhum dado é retirado dos seus sistemas, mas o destinatário pode agir com base em uma solicitação fraudulenta, e o abuso repetido prejudica a reputação de envio e a entregabilidade do seu domínio.

A falsificação de e-mail é ilegal?

Forjar informações de remetente para cometer fraude, roubar credenciais ou distribuir malware é crime na maioria dos países, e passar-se pelo domínio de uma empresa também pode configurar violação de marca. A falsificação de remetente em si, por exemplo em testes de segurança autorizados, não é inerentemente ilícita.