Ferramenta gratuita de monitoring DMARC

Por que monitorar os relatórios DMARC?

O monitoramento DMARC revela quem envia e-mails em seu nome e quais desses envios passam na autenticação. É a única forma de saber.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) unifica SPF e DKIM para fechar seu domínio contra phishing e spoofing de e-mail. Publicar o registro é o primeiro passo. Sem relatórios, o resto fica às cegas. Você ignora quais fontes emitem em seu nome, se seus fluxos legítimos realmente se alinham com SPF e DKIM, e se um terceiro explora seu domínio para spam.

Quatro problemas aparecem em quase toda auditoria de relatórios DMARC.

Um CRM, uma plataforma de newsletter ou um sistema de faturamento envia pelo seu domínio sem alinhamento SPF nem DKIM correto. Resultado: spam ou rejeição. É o caso mais frequente.

O spoofing, em seguida. Atacantes forjam seu endereço From para phishing. Sem relatórios agregados, essas campanhas ficam invisíveis até um cliente reclamar.

Uma migração de e-mail malfeita deixa o provedor antigo emitindo correio não alinhado por semanas. Sua taxa de conformidade despenca, e ninguém entende por quê.

Por fim, a TI paralela: um serviço interno envia sem autorização. Os relatórios DMARC tiram esses remetentes desconhecidos da sombra.

Como funciona a autenticação DMARC

O DMARC valida que pelo menos SPF ou DKIM passa e se alinha com o domínio do cabeçalho From. Dois protocolos embaixo, uma única decisão em cima.

SPF (RFC 7208) e DKIM (RFC 6376) autenticam cada um um aspecto diferente da mensagem. SPF verifica o servidor de envio. DKIM verifica uma assinatura. O DMARC decide.

Tudo depende do alinhamento. SPF e DKIM passam os dois, e o DMARC ainda falha se nenhum se alinhar com o domínio do From. Estranho? Nem tanto: é exatamente esse buraco que os falsificadores exploram, e a primeira causa de falha que os relatórios revelam.

O DMARC dita também o destino do correio não autenticado: deixar passar (p=none), colocar em quarentena (p=quarantine) ou rejeitar (p=reject).

Como configurar o monitoring DMARC em 3 passos

Passo 1: Adicione seu domínio e verifique a propriedade

Faça login e registre o domínio que deseja monitorar. Adicione o registro TXT de verificação do CaptainDNS ao seu DNS. Esse sistema de verificação é compartilhado entre todos os serviços do CaptainDNS (hospedagem MTA-STS, monitoring TLS-RPT, hospedagem BIMI).

Passo 2: Configure seu registro DNS DMARC

O assistente de configuração analisa o estado DNS atual e propõe o registro exato a publicar:

• Sem registro DMARC existente: um registro completo é gerado com p=none e nosso endereço rua=
• Registro DMARC existente: sua política, configurações de alinhamento e endereços rua= existentes são preservados; nosso endereço é adicionado automaticamente
• Registro existente inválido: o problema é sinalizado e uma substituição limpa é proposta

Basta copiar o host (_dmarc.seudominio.com) e o valor, depois colá-los no seu provedor DNS.

Passo 3: Os relatórios são recebidos e analisados automaticamente

Os provedores de e-mail começam a enviar relatórios agregados em 24 a 48 horas. O CaptainDNS os recebe, descomprime o XML, analisa os resultados de autenticação e exibe os resultados no seu painel: pontuações de conformidade, IPs de origem, taxas de sucesso/falha e disposições aplicadas.

Entendendo os relatórios DMARC agregados

Um relatório DMARC agregado é um arquivo XML que resume, por IP de origem, todos os resultados de autenticação sobre seu domínio durante uma janela de tempo.

Google, Microsoft, Yahoo e Apple os enviam ao endereço da sua tag rua=, em geral a cada 24 horas. Cada relatório cobre um período, e cada linha descreve uma fonte que emitiu usando seu domínio.

RUA vs RUF: relatórios agregados vs relatórios de falha

O DMARC define dois tipos de relatórios:

O CaptainDNS foca nos relatórios agregados (RUA), que fornecem os dados necessários para acompanhamento de conformidade e identificação de fontes. Relatórios forenses raramente estão disponíveis na prática.

O que contém um relatório DMARC agregado?

Exemplo de relatório DMARC agregado

Aqui está um extrato simplificado de um relatório DMARC agregado em formato XML:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1710201600</begin>
      <end>1710288000</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>captaindns.com</domain>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.1</source_ip>
      <count>1547</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <row>
      <source_ip>198.51.100.42</source_ip>
      <count>23</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

A primeira linha mostra 1.547 mensagens de uma fonte legítima passando em ambos os controles. A segunda linha revela 23 mensagens de um IP desconhecido falhando tanto em SPF quanto em DKIM, uma potencial tentativa de falsificação. O CaptainDNS analisa esses relatórios automaticamente e apresenta os dados no seu painel. Para decodificar pontualmente um relatório XML que você recebeu, nosso leitor de relatórios DMARC exibe o conteúdo de forma legível.

Referência das tags do registro DMARC

Um registro DMARC TXT é publicado em _dmarc.seudominio.com. Aqui estão as tags disponíveis:

Use nosso Gerador DMARC para criar um registro válido, ou o Verificador de sintaxe DMARC para validar um existente.

Do monitoring à aplicação: o caminho até p=reject

O DMARC só bloqueia o spoofing de vez com p=reject. Toda mensagem forjada é então rejeitada na porta. Pular direto para reject sem relatórios é jogar na roleta: seus remetentes legítimos mal alinhados caem junto, e o correio deles desaparece.

Progressão recomendada:

1. p=none (apenas monitoring): colete relatórios por 2 a 4 semanas. Identifique todas as fontes legítimas e corrija qualquer problema de alinhamento SPF/DKIM. Meta: taxa de conformidade acima de 95%.

2. p=quarantine (aplicação parcial): mensagens com falha são enviadas para spam em vez da caixa de entrada. Use pct=25 inicialmente, depois aumente para 50% e 100% ao longo de 2 a 4 semanas. Monitore se e-mails legítimos estão sendo colocados em quarentena.

3. p=reject (aplicação total): mensagens com falha são descartadas. A falsificação de domínio é totalmente bloqueada. Comece com pct=25, depois aumente até 100%.

Cronograma: A maioria das organizações completa essa jornada em 4 a 8 semanas. Não tenha pressa. Cada etapa deve confirmar que nenhum fluxo legítimo de e-mail é impactado.

Atingir p=reject também desbloqueia o BIMI (Brand Indicators for Message Identification), que exibe o logotipo da sua marca ao lado dos seus e-mails em caixas de entrada compatíveis.

Requisitos DMARC do Google e Yahoo

Desde fevereiro de 2024, o Google e o Yahoo recusam o correio dos remetentes em massa que não têm DMARC publicado. O limite: 5.000 mensagens por dia para o Gmail ou o Yahoo.

Quatro obrigações se aplicam a esses grandes volumes. É preciso um registro DMARC com pelo menos p=none. SPF e DKIM devem ser configurados os dois, não um ou outro. O domínio do From deve se alinhar com um dos dois. E os e-mails de marketing precisam carregar o cancelamento de inscrição com um clique da RFC 8058.

Sem monitoramento dos relatórios, é impossível provar que suas fontes passam nesses controles nem sustentar a taxa de conformidade ao longo do tempo. Os remetentes não conformes veem seu correio adiado por erros 4xx, depois rejeitado. Isso já aconteceu em grande escala na primavera de 2024.

Falhas DMARC comuns e como corrigi-las

A maioria das falhas DMARC se deve a seis causas: alinhamento SPF quebrado, alinhamento DKIM quebrado, SPF além de 10 consultas DNS, terceiro sem nenhuma autenticação, subdomínio não coberto, encaminhamento que quebra o SPF. Cada uma tem uma correção precisa.

Casos de uso reais

Caso 1: Identificando um serviço terceirizado mal configurado

Sintoma: A taxa de conformidade DMARC cai de 98% para 72% em uma semana.

Diagnóstico: O painel mostra um novo IP de origem enviando volume significativo sem alinhamento DKIM. Trata-se do novo CRM de marketing, configurado sem assinatura DKIM para seu domínio.

Ação: Configure a assinatura DKIM no CRM. A taxa de conformidade se recupera nos relatórios seguintes.

Caso 2: Detectando falsificação de domínio

Sintoma: IPs de origem desconhecidos aparecem nos relatórios, enviando e-mails em nome do seu domínio com falha total em SPF e DKIM.

Diagnóstico: Os relatórios DMARC revelam tentativas de phishing a partir de servidores em jurisdições suspeitas. Sua política p=none permite que essas mensagens passem.

Ação: Passe progressivamente sua política de p=none para p=quarantine e depois para p=reject. Os relatórios seguintes confirmam que as mensagens fraudulentas estão sendo rejeitadas.

Caso 3: Atendendo aos requisitos de remetentes em massa do Google

Sintoma: O Gmail começa a adiar seus e-mails de marketing com erros temporários 4xx. As taxas de entrega caem.

Diagnóstico: O monitoring DMARC mostra que sua plataforma de newsletter envia e-mails sem alinhamento DKIM ao domínio do cabeçalho From. A política de remetentes em massa do Google exige conformidade de autenticação.

Ação: Configure a assinatura DKIM para seu domínio na plataforma de newsletter e verifique o alinhamento através dos relatórios DMARC. As taxas de entrega voltam ao normal em poucos dias.

FAQ - Perguntas frequentes

P: O que é monitoring DMARC?

R: Monitoring DMARC significa receber e analisar os relatórios agregados (rua) enviados pelos provedores de e-mail. Esses relatórios mostram quais fontes enviam e-mails em nome do seu domínio e se passam nos controles SPF e DKIM com o alinhamento correto.

P: Qual é a diferença entre relatórios DMARC agregados (RUA) e relatórios de falha (RUF)?

R: Os relatórios agregados (rua) são enviados diariamente e contêm dados de autenticação resumidos por IP de origem. Os relatórios de falha (ruf) são enviados para falhas individuais de mensagens e contêm mais detalhes, incluindo cabeçalhos de mensagens. A maioria dos provedores envia apenas relatórios agregados. O CaptainDNS foca na análise de relatórios agregados.

P: Como o DMARC funciona com SPF e DKIM?

R: O DMARC se baseia no SPF e DKIM adicionando o alinhamento de identificadores. O SPF valida o IP do remetente do envelope, o DKIM valida uma assinatura criptográfica e o DMARC verifica se pelo menos um passa com alinhamento ao domínio do cabeçalho From. O monitoring revela quando o alinhamento falha.

P: Com qual política DMARC devo começar?

R: Comece com p=none para monitorar sem afetar a entrega de e-mails. Quando sua taxa de conformidade DMARC estiver consistentemente acima de 95%, passe para p=quarantine. Após confirmar que nenhum e-mail legítimo é impactado, defina p=reject para proteção total contra falsificação.

P: Como configuro o monitoring DMARC?

R: Adicione seu domínio no CaptainDNS, verifique a propriedade pelo registro TXT e depois siga o assistente de configuração que detecta seu registro DMARC atual e propõe a atualização exata necessária. Os relatórios começam a chegar em 24 a 48 horas.

P: O monitoring DMARC é gratuito com o CaptainDNS?

R: Sim, completamente gratuito para 1 domínio (passe ao Starter para 25). Sem taxas ocultas, sem período de teste. Todo domínio deveria poder monitorar seus relatórios DMARC agregados independentemente do orçamento.

P: O Google e o Yahoo exigem DMARC?

R: Sim. Desde fevereiro de 2024, o Google e o Yahoo exigem que remetentes em massa (5.000+ mensagens por dia) publiquem um registro DMARC. O monitoring ajuda você a atender e manter esses requisitos acompanhando a conformidade de autenticação.

P: O que acontece se eu definir minha política DMARC como reject?

R: Com p=reject, os servidores receptores descartam mensagens que falham tanto no alinhamento SPF quanto DKIM. Isso previne completamente a falsificação de domínio, mas pode bloquear e-mails legítimos se os remetentes terceirizados não estiverem configurados corretamente. Sempre monitore primeiro com p=none.

P: Quanto tempo leva para receber relatórios DMARC?

R: A maioria dos provedores de e-mail envia relatórios agregados a cada 24 horas. Após publicar seu endereço rua=, espere os primeiros relatórios em 24 a 48 horas, dependendo do seu volume de e-mails.

P: Qual é a relação entre monitoring DMARC e registro DMARC?

R: O registro DMARC define sua política de autenticação (none, quarantine, reject) e a tag rua= especifica onde enviar os relatórios. O monitoring DMARC analisa esses relatórios para mostrar quem está usando seu domínio e se a autenticação está funcionando corretamente.

Ferramentas complementares

Recursos úteis

• RFC 7489: DMARC, especificação oficial DMARC
• RFC 7208: SPF, Sender Policy Framework
• RFC 6376: DKIM, DomainKeys Identified Mail
• Google: Email sender guidelines, requisitos para remetentes em massa
• Yahoo: Sender best practices, requisitos de autenticação do Yahoo
• M3AAWG Best Practices, recomendações do Messaging Anti-Abuse Working Group