Email ferramentas
Como a autenticação de e-mail funciona de verdade: os dois endereços de remetente, o que SPF, DKIM e DMARC provam cada um, como ler uma cadeia Received e qual ferramenta usar em cabeçalhos ou em .eml.
3 ferramentas
Os dois endereços de remetente
Quase toda pergunta sobre falsificação de e-mail se resume a confundir duas
identidades de remetente. O remetente do envelope é o endereço fornecido no
comando SMTP MAIL FROM: as devoluções vão para lá, e os receptores o registram
como Return-Path: ou como smtp.mailfrom= dentro de Received-SPF:. O
remetente do cabeçalho é o campo From: dentro da mensagem — o único que um
humano vê. Nada no SMTP exige que os dois coincidam.
O SPF autoriza o envelope: o IP que conectou tinha permissão para enviar pelo
domínio do MAIL FROM? O DKIM autoriza o conteúdo: o remetente assina uma lista
escolhida de campos de cabeçalho (h=) mais um hash do corpo (bh=) e publica
a chave pública no DNS. Nenhum dos dois diz nada sobre o endereço que o
destinatário lê. O DMARC fecha essa lacuna exigindo alinhamento — o domínio
do From: visível precisa coincidir com o domínio do SPF ou com o domínio d=
do DKIM. Um spf=pass em uma mensagem que se diz do seu banco é perfeitamente
normal em um phishing; um dmarc=pass não é.
A terceira coisa a internalizar: não é você que está verificando nada disso. O
MTA receptor executa as checagens no momento da entrega e escreve o veredito em
um cabeçalho Authentication-Results:. Depois disso, o resultado é uma
afirmação em um arquivo de texto — confiável só se o salto que a escreveu
pertencer à sua própria infraestrutura. Um cabeçalho escrito pelo servidor de um
estranho pode ter sido inventado por esse estranho. Leia de dentro para fora, a
partir do seu MTA de fronteira, e trate tudo além dele como entrada não
confiável.
O que cada mecanismo prova
| Mecanismo | Publicado em | Autentica | Sobrevive ao encaminhamento | Impede falsificação do From: visível |
|---|---|---|---|---|
| SPF | TXT no domínio do envelope, v=spf1 … | O IP que conecta, para o MAIL FROM | Não — o IP do relay não está listado | Não |
| DKIM | TXT em <seletor>._domainkey.<d=> | Cabeçalhos em h= + hash do corpo bh= | Sim, a menos que o corpo ou o Subject sejam alterados | Só se estiver alinhado |
| DMARC | TXT em _dmarc.<domínio> | Alinhamento do From: com SPF ou DKIM, mais a política | Sim, através do DKIM que sobreviveu | Sim — esse é o propósito inteiro dele |
| ARC | Cabeçalhos ARC-Seal / ARC-Message-Signature | Preserva os resultados de origem através de um relay | Feito exatamente para isso | Não — e só seladores confiáveis contam |
| MTA-STS / DANE | TXT em _mta-sts.<domínio> / TLSA | Transporte: que o TLS era obrigatório | não se aplica | Não |
Os tokens de resultado são vocabulário comum às três checagens, e cada um aponta para uma correção diferente:
| Token | Significado | Causa usual |
|---|---|---|
pass | Checagem bem-sucedida | — |
fail | Não autorizado, de forma dura (-all) | Falsificação, ou um relay de envio ausente do registro |
softfail | Não autorizado, apenas marcar (~all) | Registro deixado permissivo no meio de um rollout |
neutral | Explicitamente sem opinião (?all) | A política não declara nada útil |
none | Nenhum registro publicado | O domínio nunca configurou SPF ou DMARC |
temperror | Falha de DNS, pode ser repetida | Resolvedor ou servidor autoritativo instável |
permerror | O registro não pode ser avaliado | >10 consultas DNS, v=spf1 duplicado, erro de sintaxe |
Qual ferramenta para qual trabalho
Se você tem o bloco de cabeçalhos bruto — «Mostrar original» no Gmail, «Ver
código-fonte» em outros lugares — comece pelo
Analisador de Cabeçalhos de E-mail. Ele desdobra linhas
de continuação, inverte a pilha Received: para que o salto 1 seja o servidor de
origem e o último salto seja o seu provedor, e mostra os segundos entre saltos
adjacentes, de modo que Delay: 1800s nomeia o relay que ficou meia hora
sentado sobre a mensagem. Abaixo do caminho ele imprime
Authentication-Results, Received-SPF, DKIM-Signature e
ARC-Authentication-Results literalmente — o veredito do DMARC vive dentro do
primeiro deles, como dmarc=pass (p=REJECT …). A análise fica no navegador, e
esse é justamente o ponto: esses cabeçalhos carregam IPs de remetentes e nomes
de host internos.
Com um arquivo .eml inteiro em vez disso — uma devolução, um anexo salvo, a
saída de um formulário que envia e-mail — use o
Visualizador EML. Ele separa cabeçalhos do corpo, decodifica
as encoded-words da RFC 2047 (=?UTF-8?B?…?=) para que assuntos não ASCII sejam
lidos como texto, e destaca From, To, Cc, Subject, Date, Reply-To e
Message-ID. Um Reply-To em um domínio diferente do From: é um sinal
clássico de fraude de e-mail corporativo. O corpo é exibido em bruto, então as
fronteiras MIME continuam visíveis; passe partes em base64 pelo
Base64 para ler uma delas.
Com apenas um domínio e nenhuma mensagem, vá para o DNS. O
DNS Lookup resolve TXT (a sua string v=spf1), MX
(roteamento, com prioridade) e mais, junto com o TTL que governa quanto tempo
uma correção leva para valer — o hub de dns cobre cache em
profundidade. É uma ferramenta de servidor: o nome do domínio vai para
api.sitekits.dev para ser resolvido e não é armazenado. Ela aceita apenas
rótulos de hostname, então nomes com sublinhado como _dmarc.example.com e
selector._domainkey.example.com são rejeitados — leia esses com
dig TXT _dmarc.example.com.
Para links dentro de uma mensagem suspeita, o
Parseador de URL quebra uma URL em host, caminho e
parâmetros de consulta decodificados sem nunca requisitá-la, e o
Conversor IDN expõe domínios homográficos mostrando a
forma xn-- que é realmente resolvida. Os dois rodam no navegador, e os dois
estão selecionados na seleção para segurança ao lado do
analisador de cabeçalhos e do visualizador de .eml. Carimbos de tempo dos
saltos em fusos estrangeiros se alinham mais rápido com o
Conversor de Fuso Horário — também local ao
navegador, mas reunido na seleção para SRE e não na página de
segurança. Antes de anexar evidências a um ticket, oculte os dados à mão — o
Sanitizador HAR cobre exportações HAR, não cabeçalhos de
e-mail.
Onde isso normalmente dá errado
p=none não protege nada
p=none apenas pede relatórios. Publicá-lo é o primeiro passo correto, mas até
você chegar a p=quarantine ou p=reject, os receptores não aplicam política
nenhuma em caso de falha. Confira o pct= também — um rollout parcial só aplica
sobre aquela fração do e-mail.
Estourar o orçamento de dez consultas
include:, a, mx, ptr e redirect= custam consultas DNS cada um, e
cadeias aninhadas de include: de remetentes SaaS somam as delas
recursivamente. Passe de dez e o registro se torna permerror, que os
receptores leem como nenhum SPF. Achate o registro ou remova fornecedores que
não são usados.
Ler toda falha como um ataque
Encaminhamento e listas de discussão quebram a autenticação legitimamente: o IP
do relay falha no SPF, e um prefixo [lista] no assunto ou um rodapé anexado
invalida o hash do corpo do DKIM. Julgue pelo alinhamento e pelo relay que
selou, não por um único fail.
Confiar em saltos que não são seus
Só linhas Received: e Authentication-Results: adicionadas no seu MTA de
fronteira ou depois dele significam algo; saltos anteriores são texto controlado
pelo atacante. Atrasos que saem negativos ou como — são desvio de relógio ou
carimbo de tempo ausente, não evidência.
Deixar domínios que não enviam abertos
Domínios estacionados e subdomínios que nunca enviam e-mail ainda precisam de
v=spf1 -all, de um registro DMARC em _dmarc.<domínio> com p=reject e, de
preferência, de um MX nulo (MX 0 .). O p= é a tag de política obrigatória:
um registro que carrega apenas sp=reject é inválido, então os receptores não
aplicam nada e o próprio domínio estacionado fica desprotegido. Acrescente
sp=reject ao lado de p= quando você quiser declarar a política de subdomínio
explicitamente — com sp= ausente, os subdomínios herdam p= de qualquer
forma. Deixado aberto, o domínio é material de falsificação gratuito carregando
a sua marca.