Monitoring DMARC: 1 domínio grátis, monitorização contínua a partir de 5 €/mês

Porque monitorizar os relatórios DMARC?

A monitorização 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 o seu domínio contra phishing e spoofing de e-mail. Publicar o registo é o primeiro passo. Sem relatórios, o resto fica às cegas. Ignora quais fontes emitem em seu nome, se os seus fluxos legítimos realmente se alinham com SPF e DKIM, e se um terceiro explora o seu domínio para spam.

Quatro problemas aparecem em quase todas as auditorias de relatórios DMARC.

Um CRM, uma plataforma de newsletter ou um sistema de faturação 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 o 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 fornecedor antigo a emitir correio não alinhado durante semanas. A sua taxa de conformidade despenca, e ninguém entende porquê.

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 por baixo, uma única decisão por cima.

SPF (RFC 7208) e DKIM (RFC 6376) autenticam cada um um aspeto 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 o seu domínio e verifique a propriedade

Faça login e registe o domínio que deseja monitorizar. Adicione o registo TXT de verificação do CaptainDNS ao seu DNS. Esse sistema de verificação é partilhado entre todos os serviços do CaptainDNS (alojamento MTA-STS, monitoring TLS-RPT, alojamento BIMI).

Passo 2: Configure o seu registo DNS DMARC

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

• Sem registo DMARC existente: um registo completo é gerado com p=none e o nosso endereço rua=
• Registo DMARC existente: a sua política, configurações de alinhamento e endereços rua= existentes são preservados; o nosso endereço é adicionado automaticamente
• Registo 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 fornecedor de DNS.

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

Os fornecedores de e-mail começam a enviar relatórios agregados em 24 a 48 horas. O CaptainDNS recebe-os, 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 ficheiro XML que resume, por IP de origem, todos os resultados de autenticação sobre o seu domínio durante uma janela de tempo.

Google, Microsoft, Yahoo e Apple enviam-nos 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 o 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 controlos. A segunda linha revela 23 mensagens de um IP desconhecido a falhar tanto em SPF como em DKIM, uma potencial tentativa de falsificação. O CaptainDNS analisa esses relatórios automaticamente e apresenta os dados no seu painel. Para descodificar pontualmente um relatório XML que recebeu, o nosso leitor de relatórios DMARC exibe o conteúdo de forma legível.

Referência das tags do registo DMARC

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

Use o nosso Gerador DMARC para criar um registo 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. Saltar diretamente para reject sem relatórios é jogar na roleta: os seus remetentes legítimos mal alinhados caem junto, e o correio deles desaparece.

Progressão recomendada:

1. p=none (apenas monitoring): recolha 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. Publique primeiro t=y, que pede aos destinatários para ainda não aplicarem a política, e retire a tag ao fim de 2 a 4 semanas. Monitorize se e-mails legítimos estão a ser colocados em quarentena.

3. p=reject (aplicação total): mensagens com falha são descartadas. A falsificação de domínio é totalmente bloqueada. Passe primeiro uma a duas semanas em p=reject; t=y, depois retire t=y.

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 logótipo 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 aplicam-se a esses grandes volumes. É preciso um registo 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 alinhar-se com um dos dois. E os e-mails de marketing precisam de carregar o cancelamento de inscrição com um clique da RFC 8058.

Sem monitorização dos relatórios, é impossível provar que as suas fontes passam nesses controlos nem sustentar a taxa de conformidade ao longo do tempo. Os remetentes não conformes veem o 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 deve-se 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, reencaminhamento 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% numa semana.

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

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

Caso 2: A detetar 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. A sua política p=none permite que essas mensagens passem.

Ação: Passe progressivamente a 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 a ser rejeitadas.

Caso 3: Cumprir os requisitos de remetentes em massa do Google

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

Diagnóstico: O monitoring DMARC mostra que a 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 o 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 fornecedores de e-mail. Esses relatórios mostram quais fontes enviam e-mails em nome do seu domínio e se passam nos controlos 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 fornecedores 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 baseia-se 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 monitorizar sem afetar a entrega de e-mails. Quando a 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 o seu domínio no CaptainDNS, verifique a propriedade pelo registo TXT e depois siga o assistente de configuração que deteta o seu registo 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: A primeira ferramenta da conta é gratuita. Cada domínio DMARC conta como uma ferramenta: depois, 5 €/mês sem IVA. Sem custos ocultos, sem período experimental.

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 registo DMARC. O monitoring ajuda-o a cumprir e a manter esses requisitos acompanhando a conformidade de autenticação.

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

R: Com p=reject, os servidores recetores descartam mensagens que falham tanto no alinhamento SPF como no 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. Monitorize sempre primeiro com p=none.

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

R: A maioria dos fornecedores de e-mail envia relatórios agregados a cada 24 horas. Após publicar o 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 registo DMARC?

R: O registo DMARC define a 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á a usar o seu domínio e se a autenticação está a funcionar 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