02 de dez. de 2025·8 min de leitura

Relatórios DMARC para domínios de outreach: leia relatórios RUA com segurança

Relatórios DMARC para domínios de outreach: aprenda a ler relatórios RUA, identificar spoofing e ir de p=none para quarantine ou reject sem prejudicar a entregabilidade.

Relatórios DMARC para domínios de outreach: leia relatórios RUA com segurança

O que os relatórios DMARC resolvem para domínios de outreach

DMARC é uma regra que seu domínio publica para dizer aos provedores de caixa duas coisas: quem está autorizado a enviar e-mails usando seu nome de domínio e o que fazer quando uma mensagem parece falsa. Ele aproveita SPF e DKIM, mas adiciona uma ideia extra que importa muito para outreach: alinhamento.

Alinhamento significa que o endereço From visível deve coincidir com o domínio que passou SPF ou DKIM.

Domínios de outreach são alvos atraentes porque enviam muito e frequentemente parecem novos para os filtros. Isso os torna úteis para golpistas que querem se passar pela sua marca, enviar faturas falsas ou executar phishing. Se alguém falsifica seu domínio de outreach, sua entregabilidade e reputação podem sofrer mesmo que você não tenha feito nada de errado.

Relatórios DMARC ajudam você a perceber isso cedo. Quando você adiciona um registro DMARC com um endereço rua, grandes receptores enviam relatórios agregados. Esses relatórios não incluem o conteúdo das mensagens. São resumos que mostram de onde vem o correio que afirma ser do seu domínio e se passou por SPF/DKIM e alinhamento.

Relatórios RUA normalmente informam:

  • Quais fontes de envio estão usando seu domínio (seu ESP, seu CRM, servidores desconhecidos)
  • Taxas de sucesso/erro para SPF, DKIM e alinhamento DMARC
  • Padrões de volume (por exemplo, um pico repentino de um país ou provedor que você não usa)
  • Aviso precoce de que seu domínio está sendo falsificado

Eles não mostram o corpo do e-mail, assunto ou o destinatário exato. Pense em RUA como câmeras de trânsito, não como filmagem completa de segurança.

Um medo comum é quebrar o envio depois de apertar a política. Isso geralmente aparece como campanhas legítimas indo para spam ou sendo rejeitadas porque SPF ou DKIM passam, mas não alinham com o domínio From, ou porque mensagens são encaminhadas e o SPF falha no caminho. Um exemplo real: sua ferramenta de sequência envia corretamente, mas respostas ou rastreamento são roteados por outro domínio e o alinhamento falha silenciosamente.

Se você usa uma plataforma como LeadTrain que configura SPF/DKIM/DMARC nos bastidores, os relatórios RUA ainda importam. Eles são a prova de que tudo está alinhado antes de você passar da fase de monitoramento.

O mínimo que você precisa saber: SPF, DKIM, alinhamento

Para entender relatórios DMARC, você precisa de três ideias: SPF, DKIM e alinhamento. Elas respondem: este remetente é permitido, a mensagem foi adulterada e as identidades coincidem?

SPF é uma lista de permissão. Diz quais servidores estão autorizados a enviar e-mails por um domínio.

DKIM é uma verificação contra alterações. O servidor remetente adiciona uma assinatura criptográfica que o receptor pode verificar. Se a mensagem for modificada em trânsito, o DKIM pode falhar.

DMARC é a regra e o placar. Diz aos receptores o que fazer se as checagens falharem (monitorar, colocar em quarentena, rejeitar) e para onde enviar relatórios.

O que alinhamento significa (e por que importa)

Alinhamento significa que o domínio que seu destinatário vê no From deve coincidir com o domínio que passou SPF ou DKIM. Isso impede spoofing simples. Se seu From diz outreach.example, mas o SPF passou para um domínio diferente, o DMARC ainda pode falhar porque as identidades não batem.

Uma forma simples de lembrar:

  • SPF checa o envelope sender e seus servidores autorizados.
  • DKIM checa o domínio que assinou a mensagem.
  • DMARC checa se o domínio que passou SPF ou DKIM alinha com o domínio visível no From.

Como você pode passar uma checagem e ainda falhar no DMARC

Você pode passar SPF e ainda falhar no DMARC se o SPF passar para um domínio de retorno (return-path) controlado pelo seu provedor, e não para o domínio do From. Isso acontece com frequência com encaminhamentos e alguns sistemas de rastreamento.

Você pode passar DKIM e ainda falhar no DMARC se a assinatura DKIM usar um domínio diferente, ou se um sistema modificar a mensagem e quebrar a assinatura.

Ferramentas de cold email ou enviam através da própria infraestrutura ou se conectam à sua. Em ambos os casos, você quer que elas assinem com DKIM para seu domínio de outreach e enviem de forma que mantenha SPF ou DKIM alinhados. Plataformas como LeadTrain reduzem surpresas onde “envia, mas DMARC falha” ao tratar configuração de domínio e autenticação de forma centralizada.

O que é um relatório DMARC RUA e o que procurar

Um relatório DMARC RUA é um resumo agregado que provedores de caixa enviam sobre e-mails que afirmam ser do seu domínio. Não mostra o conteúdo completo. Em vez disso, mostra o que viram em escala: quem enviou usando seu domínio, como a autenticação performou e quanto passou ou falhou.

Você também pode ver DMARC RUF mencionado. RUF são relatórios forenses mais próximos de amostras individuais. Muitos provedores não enviam RUF mais, e eles podem levantar preocupações de privacidade. Para a maioria dos domínios de outreach, RUA é a ferramenta prática. É suficiente para detectar spoofing, encontrar ferramentas mal configuradas e decidir quando passar do monitoramento para a aplicação.

A maioria dos relatórios RUA chega em XML e pode parecer confusa porque um arquivo pode incluir várias fontes de envio, vários IPs e múltiplos resultados. Se mais de uma ferramenta envia para seu domínio (CRM, calendário, helpdesk, plataforma de outreach), o relatório mistura tudo. Mesmo para um domínio de propósito único, você pode ver vários IPs porque provedores rotacionam infraestrutura.

Um relatório típico inclui:

  • O IP de origem, o provedor receptor e a janela de tempo
  • Volume de mensagens (quantas mensagens foram vistas daquele IP)
  • Resultado SPF e qual domínio passou SPF
  • Resultado DKIM e qual domínio assinou a mensagem
  • Resultado DMARC (pass ou fail) baseado no alinhamento

Comece com dois sinais: volume e alinhamento. Para um domínio de outreach de uso único, o ideal é que a maior parte do volume venha de um sistema de envio esperado, e que o DMARC passe porque SPF ou DKIM alinham (idealmente DKIM).

Exemplo: você configurou um domínio só para outreach e envia por uma plataforma. No RUA, você deve reconhecer os IPs principais, ver DKIM consistente passando com seu domínio e ver poucos (ou nenhum) IPs inesperados. Se usar uma plataforma como LeadTrain onde a infraestrutura de envio é isolada por tenant, as fontes tendem a ser estáveis, o que facilita detectar anomalias.

Como ler relatórios RUA passo a passo (sem se perder)

Um relatório RUA é basicamente um recibo diário dos provedores de caixa. Mostra quem enviou e-mails dizendo ser do seu domínio, de quais IPs e se SPF, DKIM e DMARC passaram.

1) Comece pelo volume

Procure as contagens mais altas primeiro. Uma fonte pode representar 90% do seu mail. Corrigir um problema de alto volume geralmente tem o maior impacto na entregabilidade.

Em setups de outreach, as fontes principais costumam ser sua ferramenta de cold email, um provedor de mailbox e, às vezes, um sistema de suporte ou CRM.

2) Verifique SPF e DKIM, depois o resultado DMARC

Para cada fonte de alto volume, confira:

  • SPF passou ou falhou (e qual domínio autenticou)
  • DKIM passou ou falhou (e qual domínio assinou)
  • DMARC passou ou falhou (a decisão final)

Atalho: se o DMARC falha enquanto SPF ou DKIM passam, normalmente você tem um problema de alinhamento, não uma queda de envio.

3) Confirme o alinhamento com seu domínio From

DMARC se preocupa com o endereço From que o destinatário vê. Confirme se o identificador autenticado (domínio SPF ou domínio de assinatura DKIM) corresponde ou alinha com o domínio From. O desalinhamento é comum quando uma ferramenta envia usando seu próprio domínio ou um subdomínio inesperado.

4) Marque fontes desconhecidas e categorize-as

Procure IPs, fornecedores ou regiões que você não reconhece. É aqui que o relatório é mais valioso: revela spoofing e ferramentas esquecidas.

Mantenha simples:

  • Legítimo (remetente esperado e que passa)
  • Precisa de investigação (ferramenta conhecida mas falhando ou desalinhada)
  • Suspeito (desconhecido ou claramente falhando)

Depois de algumas revisões, o relatório fica previsível. Você não está mais lendo dados crus. Está checando uma lista curta de remetentes que realmente usa.

Como detectar spoofing e envios similares nos relatórios

Lance sua primeira sequência
Crie sequências de cold email multi-etapa com domínios, caixas e envio em um só lugar.

Relatórios DMARC são um placar: quais servidores enviaram e-mails alegando ser do seu domínio e se SPF/DKIM alinharam. Seu objetivo é separar remetentes esperados de quem está fingindo ser você.

Comece listando as fontes legítimas que espera ver: seu remetente de cold email, seu provedor de mailbox e qualquer ferramenta de suporte ou CRM que envie em seu nome (tickets, notificações, resets de senha). Se você usa LeadTrain mais um provedor de mailbox, essas fontes devem aparecer repetidamente, com volume estável e resultados majoritariamente pass.

Sinais vermelhos que normalmente indicam spoofing (ou lookalike)

  • Alta taxa de falha DMARC (especialmente quando tanto SPF quanto DKIM falham) da mesma fonte
  • Redes de hospedagem ou regiões que você nunca usa, às vezes espalhadas por muitos IPs
  • Picos repentinos de volume de uma fonte que você não reconhece
  • Muitos endereços From diferentes sob seu domínio em uma janela curta
  • Falhas persistentes mesmo sem alterações de DNS

Spoofing vs má configuração é, na maior parte, sobre consistência. Má configuração geralmente vem de um serviço conhecido e falha de maneira repetível (por exemplo, DKIM passa mas não alinha). Spoofing costuma parecer bagunçado: IPs desconhecidos, ambos os cheques falhando e nenhum padrão que corresponda a uma ferramenta real.

Quando tratar um remetente como suspeito mesmo em baixo volume

Atacantes frequentemente testam discretamente. Trate um IP como suspeito se for desconhecido e mostrar qualquer um destes:

  • Tanto SPF quanto DKIM falham
  • Header-from é seu domínio, mas os domínios autenticados são irrelevantes
  • Aparece apenas uma ou duas vezes, de uma rede aleatória, com 100% de falhas

Exemplo: se você vê um novo IP enviando três mensagens que todas falham SPF e DKIM enquanto afirmam ser seu domínio de outreach, raramente é um erro pequeno de configuração. Costuma ser uma sondagem ou um pequeno ataque de spoofing.

As razões mais comuns de falha do DMARC em e-mails legítimos

A maioria das falhas de DMARC em relatórios RUA não são ataques. São fontes legítimas perdendo um detalhe.

Desalinhamento: o From não corresponde ao que foi autenticado

Este é o motivo mais comum. Seu e-mail pode passar SPF ou DKIM e ainda falhar no DMARC se o domínio autenticado não alinhar com o domínio From que seu prospect vê.

Exemplo: você envia como [email protected], mas a ferramenta assina DKIM para vendor-mail.example ou usa um return-path SPF em outro domínio. A correção normalmente é escolher o domínio de envio correto na plataforma e garantir que o DKIM esteja configurado para o mesmo domínio mostrado no From.

Problemas de DKIM: seletor ausente, chave errada ou configuração inconsistente

Falhas de DKIM costumam vir de erros simples: nome do selector errado, registro DNS ausente ou uma conta/provedor que não foi finalizado. Se você vê uma fonte reconhecida falhando DKIM consistentemente enquanto SPF varia, isso aponta para um problema de DKIM no DNS.

Problemas de SPF: muitos lookups e remetentes ocultos

SPF pode falhar porque um remetente está faltando, ou porque excede o limite de lookups DNS (10). Muitos lookups geralmente significam que o registro SPF tem muitos include e redirecionamentos, então os receptores deixam de avaliar e tratam como fail.

Encaminhamentos e listas que geram falsos positivos

Encaminhamentos e listas de discussão muitas vezes quebram o SPF porque o forwarder vira o novo IP remetente. DKIM pode sobreviver ao encaminhamento, mas algumas listas reescrevem mensagens, o que também pode quebrar o DKIM.

Muitas ferramentas e sem um dono claro

Se múltiplas ferramentas enviam de um mesmo domínio, os relatórios ficam confusos rápido. Mantenha um inventário simples e atribua um responsável para cada remetente. Se seus SDRs usam LeadTrain para outreach mas marketing envia do mesmo domínio em outra ferramenta, você pode ver múltiplos domínios DKIM. Isso não é necessariamente errado, mas precisa alinhar com o From visível.

Passando de monitoramento para aplicação com segurança

O objetivo é simples: bloquear spoofing sem bloquear envios legítimos.

Comece com p=none e trate como um período base, não a linha de chegada. Dê tempo suficiente para capturar padrões normais (dias úteis vs finais de semana, novas sequências, e-mails de fornecedores). Se o volume de outreach estiver subindo rápido, estenda o período base até estabilizar.

Antes de apertar a política, corrija fontes legítimas primeiro. Para cold email, isso normalmente significa garantir que sua ferramenta de envio assine com DKIM no mesmo domínio usado no From, e que o SPF não esteja falhando porque o e-mail é roteado por um serviço diferente. Se SPF ou DKIM passam e alinham, o DMARC pode passar.

Um rollout seguro costuma ser assim:

  • Mantenha p=none até que as únicas falhas sejam claramente fontes indesejadas
  • Defina p=quarantine com um pct pequeno (como 10–25)
  • Aumente pct passo a passo enquanto observa bounces, respostas e reclamações
  • Passe para p=reject apenas quando você estiver confiante de que as falhas restantes são spoofing

Quarantine é um passo intermediário útil para domínios de outreach porque pressiona scammers mas ainda dá tempo para capturar surpresas.

Tenha um plano de rollback pronto. O primeiro sinal de problema costuma ser silencioso: menos respostas, não uma mensagem de erro alta. Se o volume cair após uma mudança de política, reverta nesta ordem:

  • Diminua pct para o nível anterior
  • Troque de p=quarantine de volta para p=none temporariamente
  • Reverifique o selector DKIM e o alinhamento do seu remetente de outreach
  • Verifique se o SPF inclui o serviço de envio real (e se não está falhando por muitos lookups)

Mesmo que uma plataforma como LeadTrain configure SPF/DKIM/DMARC e aqueça caixas, a aplicação ainda se beneficia de uma subida cuidadosa. Use relatórios para confirmar que apenas tráfego ruim está sendo afetado.

Erros que causam problemas de entregabilidade durante a aplicação

Classifique automaticamente cada resposta
IA rotula respostas para você focar em leads interessados, não em organizar a caixa.

A aplicação é onde boas intenções podem quebrar envios reais. O reporting é mais útil aqui porque mostra quais remetentes serão afetados antes da mudança de política.

Ativar p=reject cedo demais é o maior erro. Se mesmo um remetente legítimo estiver falhando no alinhamento, você pode bloquear resets de senha, faturas, convites de calendário ou sequências de outreach da noite para o dia.

Outro erro comum é presumir que SPF sozinho é suficiente. SPF pode passar enquanto DMARC falha, especialmente com encaminhamentos ou From desalinhado. Para outreach, DKIM alinhado costuma ser a base mais estável.

Subdomínios também podem causar problemas. Você pode aplicar no domínio raiz enquanto o outreach vem de um subdomínio, ou um fornecedor usa um subdomínio que você não notou. Defina o escopo da política de propósito.

Fontes pequenas também importam. Algumas mensagens falhando por dia de uma ferramenta de helpdesk ou plugin de formulário podem virar milhares depois. Corrija enquanto ainda é pequeno.

Se puder evitar, não aplique DMARC no domínio principal da marca como primeiro passo. Separe domínios de outreach do domínio da marca principal para que um erro não impacte e-mails críticos.

Checagem rápida de RUA antes de mudar a política

Antes de sair do monitoramento, use relatórios RUA para confirmar que o envio real está limpo e previsível. Revise os últimos 7 a 14 dias e compare com o período anterior para capturar tendências, não ruído isolado.

  • Confirme que todo sistema legítimo esteja assinando DKIM de forma que alinhe com seu From
  • Para cada fonte legítima, verifique ao menos um caminho alinhado: SPF alinha ou DKIM alinha
  • Escaneie por IPs ou serviços desconhecidos com volume significativo
  • Procure picos semana a semana em falhas
  • Use uma rampa de segurança com pct antes de mudar p

Uma regra prática: se fontes legítimas passam com alinhamento e as falhas são na maior parte pequenas e aleatórias, você provavelmente está pronto para testar p=quarantine com pct baixo. Se um remetente legítimo falha repetidamente, corrija primeiro.

Se você usa uma plataforma tudo-em-um como LeadTrain para comprar domínios, configurar autenticação, aquecer caixas e rodar sequências, a lista de remetentes legítimos costuma ser menor, o que torna a revisão mais rápida.

Exemplo: um domínio de outreach que escala sem quebrar envios

Traga prospects rapidamente
Importe prospects via API de provedores como Apollo e comece sua sequência.

Uma equipe lança um domínio de outreach novo para cold email. Eles têm duas caixas (alex@ e sam@) e enviam por um provedor (por exemplo, AWS SES via uma plataforma como LeadTrain). Começam com DMARC em p=none para que nada seja bloqueado enquanto observam os dados.

Na primeira semana, os relatórios geralmente mostram alguns grupos claros:

  • IPs reais de envio passando SPF e DKIM
  • Algum mail encaminhado (frequentemente SPF falha, DKIM ainda passa)
  • Ruído de fundo aleatório: fontes tentando enviar como o domínio

No dia 3, a equipe nota um pequeno pico: 15 mensagens de um range de IP que não reconhecem, alegando ser do domínio. SPF falha, DKIM está ausente e o alinhamento falha. Eles confirmam que não é a ferramenta conferindo timestamps com os envios da campanha e verificando que o tráfego legítimo vem apenas das fontes esperadas.

Também encontram um problema legítimo: DKIM passa, mas o alinhamento falha porque o d= está definido para um subdomínio que não bate com o From usado no outreach. Corrigem assinando com o mesmo domínio mostrado no From (ou ajustando o From para bater com o domínio de assinatura), e aguardam 48 horas para novos relatórios.

Quando os relatórios mostram passes estáveis, eles sobem a aplicação lentamente usando pct. Passam para p=quarantine com pct=25 por alguns dias, depois 50, depois 100. Só depois de uma execução limpa consideram p=reject.

Sucesso parece chato: e-mails legítimos passam via DKIM alinhado ou SPF alinhado, fontes de spoofing continuam falhando e são colocadas em quarentena ou rejeitadas, e o grupo de IPs desconhecidos encolhe para quase zero.

Próximos passos: crie uma rotina, depois simplifique sua configuração de domínios

A forma mais rápida de obter valor dos relatórios DMARC é torná-los rotina. Escolha um domínio de outreach para padronizar primeiro e escreva todas as ferramentas autorizadas a enviar por ele (plataforma de cold email, provedor de mailbox, CRM, help desk, ferramenta de calendário). Isso mantém os relatórios legíveis e evita que fontes misteriosas entrem sem controle.

Estabeleça um ritmo de revisão que você realmente mantenha. Semanal é um bom começo. Ao revisar, você basicamente checa por novos remetentes desconhecidos, picos repentinos de volume e qualquer fonte legítima falhando no alinhamento.

Mantenha uma lista de remetentes aprovados simples, sem exagerar. Para a maioria das equipes, três campos bastam: nome da ferramenta, o que ela envia e se você espera SPF alinhado ou DKIM alinhado.

Se quiser menos partes móveis, reduza os lugares que podem enviar como aquele domínio. Uma configuração unificada como LeadTrain pode ajudar comprando e configurando domínios, cuidando de SPF/DKIM/DMARC, aquecendo caixas e executando sequências em um só lugar, de modo que seus relatórios reflitam um conjunto menor de fontes legítimas.

O objetivo permanece: menos remetentes, menos surpresas e uma política que você possa apertar sem quebrar envios reais.

Perguntas Frequentes

Que problema os relatórios DMARC realmente resolvem para um domínio de outreach?

DMARC reporting mostra quem está enviando e-mails que afirmam ser do seu domínio e se passaram por SPF, DKIM e alinhamento. É usado principalmente para detectar spoofing cedo e encontrar ferramentas legítimas mal configuradas antes de aplicar políticas DMARC mais rígidas.

O que é um relatório DMARC RUA, e ele inclui o conteúdo do e-mail?

RUA (relatórios agregados) são dados resumidos enviados pelos provedores de caixa sobre os resultados de autenticação do seu domínio em um período de tempo. Eles não incluem corpo do e-mail, assunto ou o destinatário exato, então você pode usá-los para diagnóstico sem expor conteúdo de mensagens.

O que significa “alinhamento” e por que isso importa tanto para cold email?

Alinhamento significa que o domínio visível no campo From: bate com o domínio que passou SPF ou DKIM. Em setups de outreach, isso é crítico porque uma ferramenta pode passar SPF ou DKIM usando seu próprio domínio enquanto você mostra seu domínio no From, fazendo o DMARC falhar embora o envio “funcione”.

Como eu leio um relatório RUA sem me perder?

Comece pelo volume para focar no remetente que representa a maior parte do tráfego. Depois verifique se o DMARC passa e, se falhar, veja se SPF ou DKIM passaram mas não alinharam com o domínio From — isso normalmente aponta para um problema de configuração em vez de uma queda do serviço.

SPF pode passar mas DMARC ainda falhar—como isso é possível?

Sim. É comum. SPF pode passar para um domínio de return-path controlado pelo provedor ou outro envelope sender, enquanto seu domínio no From é diferente; o DMARC então falha por desalinhamento. Por isso, DKIM alinhado costuma ser a opção mais segura para domínios de outreach.

Quais são os sinais mais claros de spoofing nos relatórios DMARC?

Procure IPs ou fontes desconhecidas com altas taxas de falha DMARC, principalmente quando tanto SPF quanto DKIM falham. Picos repentinos de volume vindos de locais que você não usa também são um forte sinal; misconfigurações geralmente vêm de um serviço conhecido e falham de forma consistente.

Por que e-mails legítimos de outreach falhariam no DMARC?

A causa mais comum é desalinhamento: a ferramenta assina DKIM para um domínio diferente ou usa um domínio SPF que não bate com o From. Outros problemas frequentes são registros DKIM faltando ou errados no DNS, limite de lookups do SPF e encaminhamentos/listas de e-mail que quebram o SPF (e às vezes o DKIM).

Quando devo mover de `p=none` para quarantine ou reject?

Mantenha p=none até que todos os remetentes legítimos passem consistentemente com alinhamento. Então passe para p=quarantine com um pct baixo e aumente gradualmente enquanto monitora respostas, bounces e reclamações; só vá para p=reject quando as falhas restantes forem claramente spoofing.

O que devo fazer se a entregabilidade cair depois de apertar o DMARC?

Os primeiros sinais costumam ser sutis, como menos respostas ou rejeições inesperadas após uma mudança de política. Reverta reduzindo pct ou retornando temporariamente para p=none, corrija o alinhamento do remetente real (normalmente DKIM vs From) e verifique a complexidade do SPF e se há remetentes faltando.

Se o LeadTrain configurar SPF/DKIM/DMARC para mim, ainda preciso monitorar RUA?

Sim. Você ainda deve verificar se os identificadores autenticados da plataforma alinham com o domínio From que você está usando e se não há ferramentas extras enviando como o mesmo domínio. Relatórios RUA provam que SPF/DKIM/DMARC estão se comportando como esperado antes de aplicar políticas mais rígidas.