Scan de e-mail: descubra se alguém pode se passar pela sua empresa
Descubra se alguém consegue enviar e-mail em nome da sua empresa. O scan lê SPF, DKIM, DMARC e MTA-STS do seu domínio. Resultado na tela e PDF completo.
O golpe da fatura falsa não começa invadindo nada.
Começa com um e-mail que parece vir do seu domínio. Não é uma invasão: é o protocolo funcionando como foi desenhado nos anos 80, quando ninguém precisava provar quem era. A verificação de remetente é opcional até hoje, e quem a liga é você, publicando três registros no seu DNS.
Os três fazem coisas diferentes. O SPF lista quais servidores podem enviar em nome do domínio. O DKIM assina cada mensagem com uma chave que só você tem. O DMARC é o único que diz ao destinatário o que fazer quando a verificação falha, e sem ele os outros dois viram informação sem consequência.
Configurações incompletas que o scan aponta: SPF terminado em ~all, DMARC parado em p=none desde a implantação e contagem de consultas de DNS estourada por integrações acumuladas, o que invalida o SPF inteiro em silêncio. Cada uma vem com a correção específica. Os termos estão explicados no glossário.
O que a varredura procura
SPF de verdade
DMARC e a decisão
DKIM e assinatura
TLS no transporte
Do domínio ao relatório
Informe o domínio
Apenas o domínio. Sem conta, sem cartão e sem instalação.
A varredura é executada
O mesmo scanner da plataforma é executado contra o host, em tempo real.
A nota aparece na tela
Score de 0 a 100, calculado pela fórmula do produto, com os achados mais graves abertos.
O relatório segue por e‑mail
PDF completo com evidência e instrução de correção, enviado a um e‑mail do domínio analisado.
Por que apenas e‑mail do domínio analisado. O relatório descreve fraquezas de um domínio específico. Entregá-lo a qualquer endereço permitiria que terceiros obtivessem esse levantamento sem relação com o domínio. Quem não tem e‑mail no domínio pode entrar em contato e receber o relatório após confirmar a relação com ele.
O que a varredura faz no alvo
Consultar registros DNS públicos
SPF, DKIM (seletores comuns), DMARC, MX, MTA-STS e TLS-RPT são lidos do DNS, como qualquer servidor de e-mail faz antes de entregar uma mensagem.
Resolver os includes do SPF
Cada include e redirect é seguido para contar as consultas e chegar ao conjunto real de remetentes autorizados.
Conectar aos servidores MX
Uma conexão SMTP a cada MX para registrar STARTTLS, versão de TLS e certificado. Nenhuma mensagem é enviada.
Verificar a política de recebimento
O arquivo MTA-STS publicado via HTTPS é lido e comparado ao registro DNS.
Sondar portas e serviços
Varredura de portas alcança infraestrutura que pode pertencer ao provedor, como acontece em PaaS e CDN. Esse tipo de teste exige autorização formal do responsável pelo ambiente.
Enumerar caminhos
Não há tentativa de descobrir rotas como /admin ou /.env por lista de palavras. Esse procedimento gera volume de requisições no alvo e só é executado com autorização.
Explorar vulnerabilidades
Nenhum payload é enviado e nenhuma vulnerabilidade é explorada. As sondas observam o comportamento da resposta, sem extrair dados.
Cobrir o inventário
O resultado cobre o domínio informado. Subdomínios, ambientes de homologação e serviços auxiliares ficam fora deste diagnóstico e costumam concentrar parte relevante da exposição.
Perguntas frequentes
Qualquer pessoa consegue enviar e-mail em nome da minha empresa?
Por padrão do protocolo, sim. O SMTP não verifica quem diz ser o remetente. Essa verificação é opcional e depende de três registros que você publica no seu DNS: SPF diz quais servidores podem enviar, DKIM assina as mensagens, e DMARC diz ao destinatário o que fazer quando a verificação falha. Sem DMARC em quarentena ou rejeição, o destinatário até percebe a falsificação, mas entrega a mensagem mesmo assim.
Tenho SPF configurado. Isso não basta?
Não, por dois motivos. Primeiro, SPF sozinho não instrui o destinatário: ele publica a lista de servidores autorizados, mas quem decide o que fazer com uma falha é a política DMARC. Segundo, SPF terminado em ~all (softfail) pede para o destinatário aceitar mesmo quando falha, o que é permissivo por definição. E existe um limite técnico de dez consultas de DNS: passar dele invalida o registro inteiro em silêncio, e acontece em domínios que acumularam integrações de marketing e faturamento ao longo dos anos.
O que significa DMARC com p=none?
Significa modo de observação: o destinatário verifica, relata para você e entrega a mensagem de qualquer jeito. É o ponto de partida correto, e serve para você descobrir quem envia legitimamente antes de apertar. O problema é ficar nele: a política nunca avança para quarantine ou reject. Enquanto isso, o domínio segue falsificável na prática.
Por que o scan verifica MTA-STS e TLS-RPT?
SPF, DKIM e DMARC tratam de autenticidade: quem enviou. MTA-STS e TLS-RPT tratam de confidencialidade em trânsito. A entrega de e-mail entre servidores negocia criptografia de forma oportunista: se o TLS falhar, o padrão é entregar em texto claro em vez de não entregar. MTA-STS é a política que fecha essa brecha exigindo TLS, e TLS-RPT é o canal que avisa você quando alguém tenta forçar a queda.
O scan envia e-mails de teste para o meu domínio?
Não. As verificações são consultas de DNS público (SPF, DKIM, DMARC, MTA-STS, TLS-RPT e DNSSEC são todos registros publicados), mais a negociação de STARTTLS com os servidores de entrada listados no seu MX, que é o mesmo contato que qualquer servidor de e-mail faz antes de entregar uma mensagem. Nenhuma mensagem é enviada, nenhuma caixa é tocada.
Meu e-mail é Google Workspace / Microsoft 365. Ainda preciso disso?
Precisa, e é justamente onde a falha mais aparece. O provedor cuida da infraestrutura de envio, mas os registros ficam no seu DNS e é você quem os publica. A configuração padrão de ambos entrega SPF e DKIM funcionais e deixa o DMARC por sua conta. A decisão sobre falsificação do seu domínio continua sendo sua, e por padrão ela não está tomada.
A nota desta página considera TLS e cabeçalhos HTTP?
Não. Nesta página roda apenas o scan de e-mail, e a nota reflete esse resultado. O diagnóstico completo executa TLS, cabeçalhos HTTP e e-mail no domínio informado. Golpe de fatura falsa e fraude de pagamento começam por e-mail em nome da empresa, então a segurança de e-mail costuma trazer os achados de maior impacto.