Os seus primeiros relatórios DMARC quase sempre trazem uma surpresa: um endereço IP que você não reconhece, enviando milhares de mensagens com o seu domínio no campo From. Às vezes é uma ferramenta que o time de vendas contratou na primavera passada. Às vezes é um serviço de encaminhamento. Ocasionalmente é alguém se passando por você. Este guia dá um método repetível para identificar cada origem desconhecida, classificá-la em uma categoria e decidir o que fazer, sem adivinhar e sem quebrar e-mails legítimos.
A resposta curta#
Para identificar um remetente desconhecido em um relatório DMARC, pegue o IP de origem e passe por quatro verificações, nesta ordem: o nome de DNS reverso (PTR) do IP, se o IP é coberto por um include de SPF que você ou um fornecedor publica, o domínio da assinatura DKIM (d=) no relatório bruto e o dono do bloco de IPs em uma consulta ao registro. Depois, classifique a origem como serviço esquecido, servidor ou script seu, encaminhador, provedor de caixa postal da sua equipe ou falsificador. Autentique os legítimos, ignore a maioria dos encaminhadores e deixe o p=reject cuidar do falsificador. Nunca bloqueie nem "conserte" uma origem antes de saber a qual grupo ela pertence. A consulta de DNS reverso gratuita cobre a primeira etapa, e o analisador de relatórios DMARC gratuito permite inspecionar os campos brutos de um único relatório.
Comece pelo que o relatório já diz#
Antes de consultar qualquer coisa, reúna tudo o que a linha informa. Para cada IP desconhecido, anote:
- O endereço IP e quantas mensagens ele enviou.
- Os resultados de SPF e DKIM, e se cada um estava alinhado com o seu domínio de From.
- A disposição, isto é, o que o receptor fez: none, quarantine ou reject.
- Os domínios usados nas verificações brutas de SPF e DKIM, se você consegue ver o XML bruto.
Esse último ponto é mais útil do que parece. Uma linha em que o DKIM passou com d=example.com significa que o remetente assina com uma chave publicada sob o seu domínio, ou seja, você ou um fornecedor que você configurou a instalou. Uma linha em que o DKIM passou com d=vendor.example.net e o SPF passou para o domínio de retorno do fornecedor significa que o fornecedor está enviando e-mail autenticado para si mesmo, com o seu domínio apenas no From. Esse é o clássico remetente terceiro sem alinhamento. Uma linha em que SPF e DKIM falharam ou não existem aponta muito mais para falsificação ou para um relay não configurado.
Se a sua ferramenta de monitoramento já mostra um nome amigável para a origem, trate-o como pista, não como prova. Os nomes são derivados de padrões de DNS reverso, e você ainda deve confirmar com os passos abaixo.
Passo 1: consulte o nome de DNS reverso#
A maioria dos remetentes legítimos publica um registro PTR para seus IPs de envio. Faça uma consulta reversa:
dig -x 203.0.113.42 +short
mail-42.sendingplatform.example.net.
O nome do host muitas vezes indica o serviço diretamente. Dois cuidados:
- Confirme no sentido direto. Consulte o registro A desse hostname e verifique se ele retorna o mesmo IP. Um registro PTR é controlado por quem é dono do IP, então qualquer pessoa pode declarar qualquer nome. Só vale confiar em um nome que resolve de volta para o mesmo IP.
- Um PTR ausente ou genérico já é informação. Hostnames como
static-203-0-113-42.hosting.examplecostumam indicar um servidor alugado ou uma linha residencial, não uma plataforma de e-mail. Isso combina mais com um falsificador ou um script hospedado por conta própria do que com um fornecedor respeitável.
Você pode fazer a consulta com um clique na ferramenta de DNS reverso se não tiver um terminal à mão.
Passo 2: verifique se o IP está no escopo do seu SPF#
Olhe o seu próprio registro SPF e veja se esse IP é coberto, diretamente ou por um include:
example.com. TXT "v=spf1 include:_spf.google.com include:sendingplatform.example.net ~all"
Se o nome do fornecedor do passo 1 já aparece em um include:, alguém o autorizou em algum momento. A origem é sua, e a pergunta em aberto é por que ela falha no alinhamento. Em geral é porque o SPF do fornecedor passa para o domínio de retorno dele, que não se alinha com o seu domínio de From, e nunca se configurou uma assinatura DKIM para o seu domínio. A correção está do lado do DKIM, tratada em falhas de alinhamento do DMARC.
Se o IP não é coberto e o PTR aponta para um fornecedor de que você nunca ouviu falar, você tem um serviço esquecido ou um desconhecido. Continue. Você também pode passar o domínio pelo verificador de SPF, DKIM e DMARC para ver o que o seu registro SPF contém hoje.
Passo 3: leia o domínio de assinatura do DKIM#
Quando o relatório bruto lista um resultado de DKIM, ele informa o domínio de assinatura e o seletor. Três desfechos são comuns:
d=é o seu domínio. Um sistema interno ou um fornecedor que você configurou está assinando com a sua chave. Encontre o seletor no seu DNS para ver qual chave é. Se você não reconhece o seletor, veja como encontrar um seletor DKIM.d=é o domínio do fornecedor. Autenticado para o fornecedor, não para você. Dá para corrigir assim que você identificar o fornecedor.- Nenhum resultado de DKIM. O remetente não assina. Scripts pequenos, impressoras, plugins antigos de CMS e falsificadores têm todos essa aparência.
Se você só tem o cabeçalho de uma mensagem recebida, e não um relatório, o analisador de cabeçalhos de e-mail mostra o veredito da DKIM e se há uma assinatura, e você lê o domínio d= na linha DKIM-Signature.
Passo 4: descubra quem é o dono do bloco de IPs#
Se o PTR está ausente ou não ajuda, consulte o registro regional de internet para o endereço (uma consulta WHOIS ou RDAP). O resultado informa a organização que detém o bloco, muitas vezes uma empresa de hospedagem ou um provedor de nuvem. Isso diz de onde o tráfego se origina, não quem é responsável por ele, então use-o para restringir a busca, não para acusar ninguém. Um bloco de uma plataforma de e-mail conhecida reforça a hipótese do "fornecedor esquecido". Um bloco de uma hospedagem barata sem DNS reverso aponta no sentido oposto.
Classifique a origem e então aja#
Depois das quatro verificações, a maioria das origens cai em um de cinco grupos.
| Classe | Como aparece nos relatórios | O que fazer |
|---|---|---|
| Serviço esquecido ou não aprovado | O PTR indica uma plataforma conhecida; SPF ou DKIM passa para o domínio do fornecedor, não para o seu | Pergunte ao responsável. Se o e-mail é desejado, adicione a assinatura DKIM para o seu domínio. Se não, encerre a conta |
| Seu próprio servidor ou script | O IP corresponde à sua hospedagem; muitas vezes sem DKIM; volume baixo em horários estranhos | Encaminhe-o pelo seu sistema de e-mail de verdade ou assine-o com a sua chave |
| Encaminhador ou lista de e-mail | A origem é um provedor de caixa postal ou um host de listas; o SPF falha, o DKIM pode passar ou quebrar se a mensagem for alterada | Em geral, ignore; confie no alinhamento do DKIM e não persiga cada encaminhador |
| Provedor de caixa postal repassando o e-mail da sua equipe | Corresponde ao provedor que você usa para o e-mail da equipe | Confirme que esse provedor está no SPF e assina com a sua chave DKIM |
| Falsificador | Sem relação com você; sem PTR ou com um genérico; falha em SPF e DKIM; volume repentino | Deixe falhando; é para isso que existe uma política reject |
O risco a evitar é tratar tudo o que é desconhecido como falsificador. Endurecer a política enquanto uma ferramenta de faturamento esquecida ainda falha no alinhamento é como uma empresa acaba rejeitando as próprias faturas. Classifique primeiro. A ordem segura de endurecimento está em como passar de p=none para p=reject.
Facilite a identificação da próxima vez#
A primeira passada é lenta. Depois disso, não deveria ser. Alguns hábitos ajudam:
- Mantenha um inventário. Uma linha por origem legítima, com o responsável, o tipo de e-mail e como ela se autentica. O monitoramento de DMARC mostra uma planilha simples.
- Exija o pedido de novas ferramentas antes do lançamento. Uma etapa curta de triagem ("esta ferramenta envia em nome do nosso domínio?") evita a maioria das origens desconhecidas.
- Reverifique contas antigas. Testes gratuitos e ferramentas de agências deixadas ativas são uma fonte frequente de remetentes surpresa.
- Registre as decisões. Quando você decidir que uma origem é ruído de encaminhamento, anote isso para que o próximo revisor não repita a investigação.
Os Relatórios DMARC ajudam na parte de dar nomes. Eles resolvem o DNS reverso do IP de cada origem e reconhecem cerca de 25 remetentes comuns, como Google, Microsoft 365, Amazon SES, SendGrid e Mailchimp. O que não reconhecem aparece como o hostname bruto ou como "Remetente desconhecido". Eles não permitem marcar, rotular nem incluir uma origem em uma lista de permissão, então a sua planilha de inventário continua sendo o sistema de registro. Também não mostram o domínio nem o seletor de assinatura DKIM de uma origem, então o passo 3 exige um relatório bruto ou o cabeçalho de uma mensagem recebida; se você quer os arquivos brutos, mantenha também um endereço de caixa postal na sua lista de rua=.
E se a origem for um falsificador?#
Se as evidências dizem que a origem não tem nada a ver com você, há pouco a consertar. Seu trabalho é garantir que a falha tenha consequências. Com uma política reject e e-mail legítimo autenticado, os receptores que respeitam o DMARC vão rejeitar ou mandar para o spam as mensagens falsificadas. Você não consegue impedir um falsificador de enviar. Só consegue fazer o e-mail dele falhar onde os receptores aplicam a sua política.
Alguns passos extras são razoáveis:
- Anote o volume e as datas para poder comparar com as semanas seguintes.
- Verifique o IP de envio em listas de bloqueio públicas com o verificador de blacklist.
- Se a campanha for grande e tiver seus clientes como alvo, avise o seu time de suporte sobre a aparência das mensagens.
Relatórios de receptores pequenos que não enviam dados agregados nunca vão mostrar a dimensão completa, então não leia uma semana tranquila como o fim de uma campanha de abuso.
Perguntas frequentes
01Como descubro quem é o dono de um endereço IP em um relatório DMARC?
Comece com uma consulta de DNS reverso (PTR) e confirme no sentido direto que o hostname resolve de volta para o mesmo IP. Depois verifique se esse IP é coberto por um include de SPF no seu registro e leia o domínio de assinatura DKIM no relatório bruto. Se isso não ajudar, uma consulta WHOIS ou RDAP informa a organização que detém o bloco de IPs, o que restringe a busca sem provar responsabilidade.
02Uma origem desconhecida no meu relatório DMARC é sempre um falsificador?
Não. Muitas das origens desconhecidas em um primeiro relatório são legítimas: uma ferramenta de marketing ou de faturamento que alguém contratou, um serviço de encaminhamento ou o seu próprio servidor executando um script. Tratar todo IP desconhecido como um atacante corre o risco de rejeitar o seu próprio e-mail quando você endurecer a política. Classifique a origem primeiro e só a trate como falsificador quando ela não tiver relação nenhuma com você.
03Por que um encaminhador falha no DMARC nos relatórios?
Quando uma mensagem é encaminhada, o IP do servidor de encaminhamento não está no seu registro SPF, então o SPF falha ou não se alinha. O DKIM ainda pode passar se a mensagem não foi alterada, e é por isso que o alinhamento do DKIM é o caminho mais confiável. O ruído de encaminhamento costuma ser seguro de deixar de lado, em vez de ser perseguido origem por origem.
04Posso bloquear um remetente desconhecido adicionando-o a uma lista de bloqueio?
O DMARC não tem lista de bloqueio. Você controla os resultados pela política: os remetentes legítimos se autenticam com alinhamento, e todo o resto falha. Com uma política reject, os receptores que respeitam o DMARC rejeitam ou mandam para o spam o e-mail que falha. Você não consegue impedir alguém de enviar como o seu domínio, só fazer esse e-mail falhar nos receptores que aplicam a sua política.
Identificar quem envia em nome do seu domínio é metade da higiene de e-mail; a outra metade é a lista para a qual você envia. O plano gratuito na página de preços dá 100 créditos para rodar a verificação completa em uma lista, e o verificador de e-mail gratuito cobre endereços avulsos. Um quadro de autenticação limpo ainda precisa de uma lista saudável por trás.
