Monitoramento de DMARC: o que acompanhar depois de publicar o registro

Publicar um registro DMARC é um trabalho único. Monitorá-lo é a parte que nunca acaba, e é onde a maioria dos domínios silenciosamente se desfaz: uma nova ferramenta de marketing começa a enviar em seu nome, um fornecedor muda a configuração de assinatura, uma edição de DNS derruba o endereço rua=, e ninguém percebe por meses. Este guia trata da rotina contínua depois que o registro está no ar: o que acompanhar, com que frequência, quem deve ser o responsável, quais limiares merecem um alerta e o que os dados agregados não conseguem dizer.

A resposta curta#

Monitoramento de DMARC é coletar os relatórios agregados diários que os provedores de caixa postal enviam ao seu endereço rua=, transformá-los em uma visão por fonte e revisar essa visão em intervalos regulares. Você observa quatro coisas: uma nova fonte de envio que você não autorizou, uma fonte conhecida cuja taxa de aprovação cai, uma queda no volume de relatórios (muitas vezes um endereço rua= quebrado) e desvio de política no próprio registro. Uma revisão semanal de dez minutos mais um alerta para falhas súbitas cobre a maioria dos domínios. Para ler um único arquivo de relatório, o analisador de relatórios DMARC gratuito basta. Para continuar acompanhando sem abrir XML, você precisa de algo que receba os relatórios por você. Os dados têm sempre um ou dois dias de atraso e cobrem apenas os provedores que enviam relatórios, então trate-os como um detector de fumaça, não como uma transmissão ao vivo.

Ler relatórios versus monitorá-los#

Como ler relatórios DMARC explica o que há dentro de um arquivo XML: o IP de origem, a contagem de mensagens e os resultados de SPF e DKIM. Essa habilidade importa, mas responde a uma pergunta pontual: o que este receptor viu neste dia?

O monitoramento responde a perguntas diferentes ao longo do tempo:

• Uma fonte que passava no mês passado começou a falhar esta semana?
• Apareceu uma fonte que nunca tinha enviado em nosso nome?
• O total de mensagens reportadas caiu pela metade?
• O registro ainda é o que nós publicamos?

Você não consegue responder a isso com uma pasta de anexos fechados. Um domínio movimentado recebe dezenas de relatórios por dia de receptores diferentes, cada um com sua lista de IPs. Alguém, ou alguma coisa, precisa juntá-los em uma tabela por domínio e comparar hoje com o passado. Se você ainda não publicou um registro com relatórios ativados, comece por como configurar o DMARC e volte quando chegarem os primeiros relatórios, o que costuma levar de 24 a 48 horas.

O que acompanhar, em ordem de prioridade#

Nem todo número merece atenção. Estes são os sinais que mudaram o resultado em domínios reais, mais ou menos do mais urgente ao menos urgente.

Uma palavra sobre a segunda linha, porque é a que as pessoas leem errado. O DMARC passa quando o SPF ou o DKIM passa e se alinha com o domínio visível do From. Uma fonte pode falhar no alinhamento do SPF todos os dias e ainda assim mostrar 100% de aprovação no DMARC porque o DKIM a sustenta. Isso é aceitável até que a chave DKIM seja rotacionada ou removida, e aí a fonte despenca. Ao revisar uma fonte, olhe as duas colunas, não apenas o resultado combinado.

Uma rotina semanal que leva dez minutos#

A revisão diária é exagero para a maioria das equipes, e a mensal é lenta demais. Uma passada semanal é um meio-termo razoável. Eis uma rotina que você pode adaptar:

1. Abra os últimos 7 dias de cada domínio que você possui, incluindo domínios estacionados ou que nunca enviam e-mail.
2. Ordene as fontes por volume. Confirme que as cinco maiores são as que você espera.
3. Procure IPs ou nomes novos que não estavam na lista da semana passada. Anote cada um com a data em que o viu pela primeira vez.
4. Confira qualquer fonte abaixo de 100% de aprovação no DMARC. Decida para cada uma: corrigir, ou aceitar como ruído de encaminhamento.
5. Compare o volume total com o da semana anterior. Uma queda brusca merece um olhar no registro antes de qualquer outra coisa.
6. Anote a política (p= e sp=) e confirme que é a que você definiu por último.

Mantenha uma planilha simples de inventário com uma linha por fonte legítima: nome do serviço, responsável dentro da empresa, que e-mail ela envia e como se autentica (DKIM com domínio próprio, include no SPF, ou ambos). Os relatórios dizem o que está enviando. Só a sua planilha diz se deveria estar.

Source           Owner         Mail type           Authenticates via
Google Workspace IT            Staff mail          DKIM d=example.com
Newsletter tool  Marketing     Campaigns           DKIM d=example.com, include in SPF
Billing system   Finance       Invoices            DKIM d=example.com

Quem deve ser o responsável#

O monitoramento de DMARC falha com mais frequência porque não pertence a ninguém. O DNS fica com a TI, as ferramentas de envio ficam com marketing, produto, suporte e financeiro, e os relatórios caem numa caixa compartilhada que uma pessoa criou e depois saiu.

Escolha um responsável nomeado por domínio e dê a ele dois poderes: ver todos os relatórios e ter autoridade para perguntar a outras equipes o que é uma fonte. Um novo remetente deve ser um pedido que chega a esse responsável antes do lançamento, não uma surpresa descoberta num relatório três semanas depois. Se a sua empresa tem muitos domínios, atribua o responsável por domínio, não por empresa, porque as pessoas que sabem quais ferramentas enviam como shop.example.com raramente são as que sabem sobre example.com.

Limiares de alerta que valem a pena#

Os alertas devem ser raros o bastante para que as pessoas ainda os leiam. Estes limiares são conselhos, não padrões, então ajuste-os ao seu volume:

• Qualquer fonte nova enviando e-mails que falham, depois de passar um piso pequeno (por exemplo, 5 mensagens com falha em um dia) para que um único encaminhamento isolado não acione ninguém.
• Um total de falhas acima de um nível fixo no dia (por exemplo, 10 mensagens) em domínios de volume modesto. Em domínios grandes, use uma porcentagem do volume.
• Uma fonte conhecida que fica abaixo da taxa de aprovação habitual por dois dias seguidos, o que filtra o ruído de um dia só.
• O volume de relatórios caindo pela metade de uma semana para outra.

O que não alertar: um único receptor reportando um pequeno número de falhas, oscilações de um ou dois pontos na taxa de aprovação e qualquer coisa que seja apenas ruído de p=none enquanto você ainda descobre remetentes.

Os relatórios DMARC da Qualisend cobrem a versão básica disso. Todo dia o serviço examina o dia UTC anterior e envia um e-mail quando um domínio tem 10 ou mais mensagens que falharam tanto no SPF quanto no DKIM, ou quando uma fonte que ele não via para aquele domínio nos últimos 30 dias envia 5 ou mais mensagens com falha. Ele não alerta sobre quedas na taxa de aprovação que ficam abaixo desses números, sobre mudanças de política, nem sobre falsificação que nenhum provedor reportou, então mantenha também a sua revisão semanal.

Limites dos dados agregados#

Os relatórios agregados são úteis e incompletos. Conheça as bordas antes de confiar neles para uma decisão:

• Eles chegam atrasados. Os provedores costumam enviar uma vez por dia, então você vê ontem ou anteontem. Não é uma visão em tempo real.
• Só vêm dos receptores que os enviam. Os grandes provedores de caixa postal enviam. Muitos receptores menores não. Os seus números descrevem a fatia que reporta, não todo o seu e-mail.
• Não têm o conteúdo das mensagens. Você recebe contagens e resultados de autenticação por fonte, nunca assuntos nem destinatários. Isso é deliberado e protege a privacidade, e também significa que você não vê exatamente qual mensagem falhou.
• Não mostram falsificação que ninguém reportou. Se um receptor não envia relatórios, o e-mail falsificado enviado a ele é invisível para você.
• Relatórios forenses (de falha) raramente estão disponíveis. A tag ruf= pede relatórios de falha por mensagem, mas muitos grandes provedores não os enviam, então planeje apenas com dados agregados. Os relatórios DMARC da Qualisend não recebem relatórios de falha.
• O volume por fonte é uma contagem de mensagens, não de destinatários. Uma fonte com 3 mensagens e 3 falhas é um problema diferente de uma com 30.000 mensagens e 3 falhas.

Nada disso torna os dados menos valiosos. Significa que um painel limpo diz "nada de errado no que foi reportado", não "nada de errado".

Onde o monitoramento se encaixa no ciclo completo de segurança#

O monitoramento de DMARC é uma camada. O registro pode estar perfeito e ainda ser desfeito por um problema de DNS diferente, como um registro SPF que passa do limite de consultas ou uma chave DKIM que foi apagada. A rotina mais ampla está descrita no guia de monitoramento de saúde do domínio, que cobre os registros dos quais o DMARC depende. Quando os seus relatórios estiverem limpos e estáveis, o passo natural seguinte é endurecer a política, tratado em passar de p=none para p=reject. Se você está comparando ferramentas para fazer a coleta, como escolher uma ferramenta de monitoramento de DMARC apresenta os critérios e compara preços reais.

Para as regras que fazem tudo isso importar na prática, veja os requisitos de remetente do Google e do Yahoo e, para o panorama maior de por que e-mails autenticados ainda caem no spam, o guia de entregabilidade de e-mail.

O monitoramento diz quem está enviando em nome do seu domínio; ele não diz se a lista por trás desses e-mails é saudável. Comece no plano gratuito (preços) e gaste os 100 créditos em uma lista real para ver o risco de devolução dela. Um domínio bem monitorado ainda precisa de uma lista limpa para conquistar a caixa de entrada.