Resumo

  • Um levantamento de Palisade apresentado em 1º de setembro por Internet Society Pulse encontrou DMARC válido em 58,1% dos 99.300 domínios observados.
  • Entre os domínios que publicavam DMARC, 20,7% não informavam endereço para relatórios agregados. Isso não comprova ausência de monitoramento nem revela o escopo contratado pelo cliente.

O e-mail da equipe está funcionando. Depois entra um serviço de cobrança, muda a ferramenta de marketing e outro sistema começa a enviar pelo mesmo domínio. Quem mantém a lista desses remetentes e decide os ajustes de autenticação? A resposta não vem necessariamente na contratação das caixas postais.

A pergunta ganha um contexto atual com o artigo convidado de 1º de setembro em Internet Society Pulse. Samuel Chenard, CEO e cofundador de Palisade, apresenta ali a pesquisa de sua empresa. Internet Society esclarece que a opinião de um convidado não representa necessariamente sua posição. Não se trata de uma nova determinação institucional.

O retrato não mostra o contrato

O benchmark de Palisade observou 99.300 domínios em oito minutos de varredura no dia 14 de agosto. Encontrou 57.732 publicações válidas de DMARC, equivalentes a 58,1% da amostra. Entre os publicadores, 36.938 pediam quarentena ou rejeição, ou 64%, enquanto 11.959 não indicavam endereço de relatórios agregados, ou 20,7%.

Os dois últimos percentuais usam como base os publicadores de DMARC, não todos os domínios. São resultados divulgados pelo pesquisador; não reproduzimos a varredura. A seleção parte de domínios de sites bem classificados e não constitui um censo do e-mail empresarial.

A identificação do fornecedor também tem limites. O MX mostra a infraestrutura visível de recebimento; um gateway pode encobrir a plataforma de caixas postais. Ajustar as comparações por faixas de posição no ranking não transforma uma associação em causa. Os dados não demonstram que a escolha de um provedor produziu determinada política, nem permitem avaliar o cumprimento de contratos.

Delegar é possível; pressupor o escopo é outra coisa

RFC 9989, a especificação atual de DMARC, associa a política do domínio à autenticação alinhada, à análise de retorno e à correção de falhas no envio legítimo. A definição de proprietário do domínio inclui prestadores agindo por seus clientes. Portanto, o padrão admite delegação; não cria uma obrigação legal indelegável para a equipe interna.

Um serviço gerenciado pode assumir essas tarefas e oferecer uma vantagem real. Mas é preciso distinguir operar as caixas, manter o DNS, examinar relatórios e autorizar mudanças. Essas funções podem estar juntas ou distribuídas entre contratos. A marca do fornecedor não resolve a divisão.

A política p=none tampouco é sinônimo de abandono. RFC 9989 a recomenda no início, para descobrir remetentes legítimos esquecidos e corrigir a autenticação antes de pedir tratamento mais rigoroso. O tempo de observação depende também da frequência dos envios.

A ausência de endereço para relatórios não prova que inexista qualquer monitoramento. Sua presença também não prova recebimento ou leitura: RFC 9990 prevê condições para autorizar destinos externos e entregar relatórios. O DNS oferece um retrato da configuração, não da rotina de trabalho.

O que a compra precisa deixar claro

A separação entre especificação comum mínima e decisão local proposta por Lu Heng ajuda a interpretar o caso. Trata-se de uma leitura editorial, não de exigência adicional da IETF. Um protocolo comum facilita a cooperação; não distribui automaticamente as responsabilidades comerciais.

Não é necessário concluir que tudo deve voltar para dentro da empresa. A tarefa é definir se o inventário de remetentes, a revisão dos relatórios, as alterações de DNS e a aprovação da política estão incluídos, permanecem com o cliente ou exigem outra contratação. A terceirização pode reduzir trabalho, desde que se saiba quem recebe o trabalho que continua.

Fontes