Relatório DMARC e protocolo DMARC: o que os dados mostram

Você configurou o DMARC e começou a receber anexos XML do Google, Microsoft ou Yahoo. Agora é importante distinguir um relatório DMARC do próprio protocolo.

DMARC é um protocolo de autenticação, políticas e relatórios; seu registro DNS configura a política solicitada. O relatório contém observações de alguns destinatários após avaliar mensagens com seu domínio. A configuração expressa uma solicitação; o relatório fornece dados parciais.

Para configurar o e-mail, consulte como criar e-mail com seu domínio. Se o encaminhamento afeta a autenticação, leia como encaminhar e-mails do domínio para o Gmail. Aqui vamos interpretar os relatórios após a configuração.

Relatórios podem chegar após a publicação, sem prazo garantido nem participação de todos os destinatários. Confundir registro, política, endereço de relatórios e resultados pode levar a alterar um DNS que não causou o problema.

Veremos o conteúdo do relatório, a diferença em relação ao registro e os campos relevantes, sem atribuir automaticamente uma falha a abuso ou encaminhamento.

O que é um relatório DMARC?

Um relatório agregado resume dados de um destinatário participante: SPF, DKIM, alinhamento a From, política encontrada e tratamento informado para as mensagens observadas.

O relatório não é a política. Destinatários que oferecem relatórios podem consultar o DNS, avaliar mensagens com seu domínio em From e enviar resumos ao destino rua. A RFC 7489 define relatórios agregados para ajudar a entender autenticação, correções e efeitos das políticas. O envio é opcional.

Relatório DMARC e registro DMARC

O registro DNS configura o DMARC; o relatório fornece telemetria dos destinatários participantes. Nenhum representa um inventário completo de todos os seus envios.

A correção depende do problema. Um registro inválido pode impedir a aplicação da política; um registro válido com falhas exige investigar serviços autorizados, encaminhamento, alinhamento e possíveis fontes não autorizadas. O relatório não decide isso sozinho.

O que um relatório DMARC contém?

Os relatórios agrupam mensagens por IP e resultados. Confira origem, volume, SPF, DKIM, alinhamento e disposição. No XML, auth_results contém autenticação bruta e policy_evaluated traz os resultados SPF e DKIM considerando o alinhamento; não confunda os dois.

O XML pode incluir política publicada, disposição, identificadores SPF e DKIM e resultados. O DMARC passa quando SPF ou DKIM passa com alinhamento. Uma disposição none não comprova que o DMARC passou nem necessariamente uma política de monitoramento; quarantine ou reject informa uma ação, não a legitimidade ou segurança do conteúdo.

Uma falha SPF não significa que todos os e-mails falham. Se o DKIM passa com alinhamento, o DMARC passa; SPF válido e alinhado também pode bastar.

Leia o relatório nesta ordem:

1. Confira o IP de origem e a organização que enviou o relatório.
2. Avalie o volume. Uma mensagem e 20,000 mensagens têm impactos diferentes; um envio isolado também pode ser crítico.
3. Confira a disposição none, quarantine ou reject sem confundi-la com o resultado DMARC.
4. Compare SPF e DKIM e diferencie resultados brutos de avaliações com alinhamento.
5. Verifique o alinhamento ao domínio real de From.

Relatórios agregados e relatórios de falha

Relatório DMARC geralmente significa o agregado solicitado por rua. Relatórios de falha ou forenses usam ruf, podem fornecer dados de mensagens específicas e têm suporte mais limitado. Não exigem sempre mensagens completas e podem conter dados sensíveis.

Para um único destino, começar por rua costuma ser útil, com monitoramento, controle de acesso e autorização DNS no domínio destinatário externo quando necessária. As diretrizes de envio do Google explicam que a autenticação pode influenciar o tratamento conforme os requisitos aplicáveis. Os relatórios fornecem dados operacionais, não garantia de entrega.

Publicar um registro que solicite relatórios DMARC

Publique o TXT em _dmarc com política e destino válido. O monitoramento permite solicitar dados antes das restrições, embora filtros locais continuem ativos.

Este exemplo usa alinhamento estrito: não é uma configuração inicial universalmente segura. Adapte-a depois de conferir os fluxos e seus domínios:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

Como substituição posterior, após inventário e testes de fluxos legítimos, você pode avaliar esta política restritiva:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

O modo estrito exige domínio exato; o relaxado compara o domínio organizacional. A amostragem depende do destinatário e não impõe restrições com monitoramento. Considere rejeição após testes, revisão de fluxos raros e plano de reversão, não apenas relatórios aparentemente limpos.

Confira a publicação com uma consulta:

dig TXT _dmarc.example.com +short

No TrekMail, o assistente e as verificações DNS disponíveis podem encontrar ausências ou conflitos. Compare consultas externas e mensagens reais: o painel não comprova todos os fluxos. Consulte como adicionar um domínio e e-mails que chegam ao spam.

Ler um relatório sem conclusões precipitadas

Investigue separadamente falhas esperadas e fontes potencialmente abusivas. Um encaminhamento pode explicar SPF com falha; um IP desconhecido não comprova falsificação.

O relatório ajuda a medir resultados das fontes observadas e conhecer o tratamento informado. Ele não comprova a entrega nem a segurança do conteúdo.

Por que o encaminhamento complica os relatórios

Após encaminhamento, o destinatário seguinte avalia SPF para o IP do relay e o domínio real de MAIL FROM. Isso pode gerar falhas mesmo com uma mensagem original legítima.

Não adicione automaticamente ao SPF IPs de caixas pessoais ou relays antigos. O DKIM pode preservar um resultado alinhado se a assinatura continuar válida e os dados assinados forem mantidos após a canonicalização; dizer que a mensagem mudou pouco não basta.

O SRS pode alterar o remetente do envelope para SPF sem restaurar o alinhamento ao From original. O ARC pode orientar exceções locais, não transformar falha em autenticação DMARC válida. Consulte a configuração e correção de problemas de encaminhamento.

Quando um relatório justifica alterar DNS

Altere o DNS quando a investigação identifica um remetente autorizado cuja configuração precisa mudar. Confirme primeiro o serviço real e o mecanismo que falha.

Avalie alterações nestes casos:

1. O domínio real do envelope precisa autorizar por SPF o provedor que usa o IP observado.
2. O fornecedor assina com outro domínio e não resta mecanismo válido e alinhado; configure e ative DKIM próprio ou Return-Path adequado, não apenas rastreamento de links.
3. Um aplicativo usa uma rota SMTP antiga: confirme a mudança necessária e teste a nova configuração.
4. O registro não tem destino rua, contém sintaxe inválida ou política inadequada à etapa verificada.

Não altere o SPF apenas porque um relatório mostra um IP de encaminhamento do Gmail ou Outlook que falha.

O TrekMail pode centralizar domínios, verificações DNS, caixas, migração e SMTP conforme o plano, em vez de coordenar registradores, XML e cinco fornecedores sem inventário. Continue verificando o envio real e o limite SPF de mecanismos e modificadores que provocam consultas DNS, incluindo avaliações aninhadas, sem duplicar registros. Consulte configurações IMAP e SMTP ou hospedagem de e-mail multidomínio.

É preciso ler cada relatório manualmente?

Em um domínio pequeno, a leitura manual inicial pode funcionar. Com mais dados, um analisador ou uma caixa dedicada ajuda a organizar XML e controlar o acesso.

Com um domínio e poucos remetentes, ler os relatórios disponíveis durante a implantação pode ser viável. Com dez domínios, leva mais tempo; com cinquenta, planeje a análise e padronize a configuração sem presumir relatórios diários de todos os destinatários.

Relatórios sem falhas de fontes conhecidas podem ser um bom sinal, mas não comprovam inventário completo. Teste também mensagens raras ou críticas; uma disposição restritiva não demonstra sozinha falsificação.

Processo recomendado para relatórios DMARC

Publique, observe, compare o inventário, corrija autenticação e alinhamento e depois avalie restrições. Os relatórios são uma fonte parcial, não uma autorização automática para endurecer a política.

1. Publique DMARC com p=none e uma caixa dedicada e monitorada.
2. Reúna relatórios durante vários dias como observação inicial, sem garantir que cada destinatário envie nem que isso cubra todos os fluxos.
3. Investigue três categorias possíveis: remetente autorizado, efeito do encaminhamento ou falsificação; mantenha fontes não identificadas sem classificação.
4. Corrija remetentes autorizados e confira encaminhamento com DKIM válido e alinhado, sem ignorá-lo indiscriminadamente.
5. Avalie quarantine e depois reject após comparar relatórios, logs e testes de fluxos críticos raros, com um plano de reversão.

Cada ferramenta nova exige conferir SPF, DKIM e o Return-Path realmente usado. Mudar o serviço pode alterar o alinhamento sem mudar o TXT DMARC.

TrekMail e a coordenação do DNS

O TrekMail não substitui o DMARC. Conforme o plano, pode centralizar parte da gestão, mas você ainda precisa publicar e verificar registros e remetentes.

Domínios personalizados, caixas IMAP, catch-all, encaminhamento, cópia IMAP e SMTP próprio ou gerenciado dependem da oferta e do plano. Para agências e MSPs, gestão multidomínio e armazenamento compartilhado podem ajudar na organização. A cópia não substitui a alteração de MX nem migra todos os aplicativos.

Cobrança por usuário também não implica ausência de inventário ou ferramentas. Compare processos, limites e custos: a oferta descrita apresenta planos a partir de $3.50 por mês, Nano sem custo nem cartão conforme suas condições e teste gratuito de 14 dias para planos pagos sujeito aos requisitos aplicáveis. Consulte a página de preços do TrekMail; economia e ausência de incidentes não são garantidas.

Conclusão sobre relatórios DMARC

O relatório fornece observações sobre a política e o envio real. Não substitui o DNS nem comprova que toda a configuração e todos os fluxos correspondam.

Lembre-se da diferença: DMARC é o protocolo, o DNS configura sua política e os relatórios parciais ajudam a investigar remetentes, possíveis falsificações e quando avaliar quarentena ou rejeição. Combine-os com inventário, logs e testes para decidir, sem garantias de entrega.